Hash Buster
Xena Donovan
This is typically used to add words to spam e-mails, to bypass hash filters. As the e-mail's hash sum is different from the sum of e-mails previously defined as spam, the e-mail is not considered spam and therefore delivered as if it were a normal message.
Hash busters can also be used to randomly add content to any kind of file until the hash sum becomes a certain sum. In e-mail context, this could be used to bypass a filter which only accepts e-mails with a certain sum.
In the event the hash was disclosed or the database was compromised, the attacker will already have one of the two values (i.e. the salt), used to construct the hash. All the attacker needs to do now is figure out the password entered into the hash formula and the order in which it was used. Order being:
What is the solution? Right now the solution is moving away from sha-512 w/ per user salts to something like bcrypt but with a twist. The twist is adding in a layer of defense plus adding some controls over who can unlock the password equation. In pseudo code, this is what I mean:
The system_shared_password (aka nonce) is not stored within the database. Instead this data is stored on the operating system within a protected file. Using this configuration a SQL injection vulnerability that provides access to the password hash data would not provide access to the system_shared_password. Only under the scenario of a full system compromise would both secrets (password hashes, system_shared_password) be compromised.
Why use per user salts at all? Two reasons, first per user salts ensure that two users with the same password will not have the same hash. Second, the use of salts prevents an attacker from using a precomputed rainbow table against the hashes.
More to come on this subject, as our goal is to increase security and the time in which it would take in order to brute or dictionary the hash. Our goal is and always to provide better protection around authentication systems.
Interesting. Probably also worth mentioning that using the PKCS#5 PBKDF2 mechanism is better than just hash(salt+pw). Basically the same, but the looping imposes an unavoidable time-penalty on someone attempting to brute force it.
As mentioned by others, the only purpose of the salt is to defeat rainbow tables, the defense against avoiding access to the salt in case of SQL injection can be achieved by simply having another (very random and big) salt on the web application side.
What I found interesting about something like this is that it appears, to me, to protect against the case where the attacker knows the salt values. This design forces the attacker to additionally know the length of the password.
SHA-256 is a hash function that uses the Merkel-Daamgard construction, just like SHA-1. That means that hash(password salt) and hash(salt password) actually are quite different from a cryptanalytic viewpoint, due to the internal block chaining of input blocks into the compression function.
Hello there,
I have been coding WordPress themes for the last years and now I am building my first website with Kirby CMS. Looks very promising and I am looking forward to doing a lot more Kirby projects in the future. I have added the yarn/webpack pipeline from the Sage WP theme ( ), which has integrated cachebusting. Now I am facing the question how I can get the generated hashed versions of JS or CSS files to the website code.
In Kirby we tend to do the cache busting for CSS/JS in a tooling agnostic manner via plugins who automate this for your via PHP. Then you can safely remove the cache busting part from your development pipeline.
It works, but for sure it can be improved. It checks, if an json-manifest file exists + simply compares the filenames. If there is a hashed version the filename is adjusted. I appreciate your suggestions or feedback. Thanks!
I've got Smidge creating minified CSS/JS bundles, with the CacheBuster set to "AppDomain". But the Smidge configs only seem to vary the cachebuster value based on the "Version" value, which I'm not using.
The lack of a changing version number in the URL makes the cache buster useless, as browsers will cache the file based on the filename alone - they don't care what goes on behind the scenes. a request for a cached "style.css" will always return a cache hit as (by design) that happens before the file is requested from the server (to allow any Smidge invalidation to happen).
The only way around this seem to be to set the generated files to nocache, but then there's just extra processing overhead on every page load to check if the file needs to be rebuilt (when the browser caching would do that for you).
I trawled the source code and found an undocumented Umbraco.Cms.Web.Common.RuntimeMinification.SmidgeRuntimeMinifier which re-implements CreateCssBundle and CreateJsBundle for the back office - if I inject this into my view and use those functions, the files are generated with the correct AppDomain cachebuster.
Hi all,
looking for an elegant solution for forcing cache buster.
Right now,I get troubles when bundled files (main.js, vendor.js & co) get an upates.
One simple solution may be be to enable:
ok, good to know, I am not used with gulp, I assume we can achieve the same with webpack which is used with ionic.
Wondering why the ionic team did not address this out of the box in the buidling process, I assume they surely encountered this issue ?
At some point, the hashing stopped working, and I found that the ionic_webpack was no longer being read from package.json
So to fix that, you can just add the parameter directly to the build command:
Buster Is Destructive. Buster does not make backups of your files. Buster performs its operations directly on the files that operational directives indicate. See "A Typical Buster Workflow" below.
Versions prior to v1.1.0 generated hashes based solely on the content of the files targeted by its operational directives. This opened up the opportunity for clashes on files that had no content. To address this issue, beginning with v1.1.0, Buster will generates unique hashes for all files by including the path of the file targeted by operational directives as well as its content.
"site relative file paths" pertain strictly to your project's file structure. They are used to declare the input in operational directives when declaring the file paths to assets in your project that you want targeted by Buster for cache busting.
"Site relative URLs" pertain strictly to your website's runtime environment and are used to reference assets throughout your site (e.g. the src attribute of an img tag, the href attribute of a link tag, the URL() CSS function declared inside of a CSS stylesheet).
The important thing here is to understand that in order for Buster to perform its cache busting you, the developer, must insure that your site employs site relative URLs when referencing its assets. This is because Buster converts your site relative file paths to site relative URLs which it then uses to search the content of your site's files for site relative URLs that need to be updated to point to the assets it has fingerprinted with unique hashes.
Your development build tool generates your production ready site (as opposed to development) into your project's release folder. When configuring Buster to cache bust your site, you would target your project files in the release folder by using site relative file paths in your Buster configuration's operational directives. Then from the root of your project you can use the command line to run Buster to cache bust your site in the release folder. You can then run your site from the release folder to insure that it is functioning as expected and once it is determined that it is functioning as expected you can then deploy your site directly from the release folder to its server using a command line utility such as rsync.
the site relative file path used in an operational directive to target housecat.jpg would be release/media/housecat.jpg and the site relative URL used to identify the image file in the browser would be media/housecat.jpg.
Buster employs a concept called an Operational Directive, abbreviated od, which you declare in your .buster.json configuration file and which Buster uses to direct the operations it performs on your project's files. Each od is comprised of 2 parts, an input, and an operation.
Important Buster implements its glob support using node package glob. Please refer to node package glob should you need additional information on using globs with Buster.
Indicates the actions that Buster is to perform on the od's input file(s). It is a number preceded by a colon which separates the number from the input (e.g. ":1"). The following 3 operations are currently supported:
The format of each unique MD5 hash-based file name will be [original file's base name].[unique hash].[original file's extension] (e.g. cat.[unique hash].jpg). Should the original file's base name contain 1 or more periods (e.g. main.js.map) the format of the MD5 hash-based file name will, as an example, be main.[unique hash].js.map.
Apply this operation only to those files whose contents are to be searched for site relative URLs that point to assets whose file names have been fingerprinted and therefor need to be updated and whose own file names are not to be fingerprinted for cache busting purposes (e.g. .html).
Apply this operation only to those files whose own file names are to be fingerprinted for cache busting purposes and whose contents are to be searched for site relative URLs that point to assets whose file names have been fingerprinted and therefor need to be updated (e.g. .css).
64591212e2