A New, Simple Way to Salt your Hashes

Don't do this. This is no better than using a single fixed salt for an entire site: An attacker who has access to your password file can iterate through possible passwords and for each password perform <i>one</i> computation to check if that password matches <i>any</i> of your users.<p>The whole point of salting is to reduce an attacker to checking one possible user/password pair at once. You don't get this benefit if you use the method described in this article.<p>The <i>only</i> attacker I can see this defending against is an attacker who has a precomputed table of password MD5s and doesn't have (hasn't bothered to create) a precomputed table of password-repeated-twice MD5s. So technically the method described is slightly more secure than simply storing (user, MD5(password)) pairs, since it avoids the "google to reverse MD5 hashes" pseudo-attack. But if you're going that low, you're pretty much lost already.<p>Don't do this.

Can anyone take a stab at explaining the fetish webdevs have for password salt schemes? I don't get it. Colin will probably agree with me: people who build authentication systems don't spend a lot of time thinking about salts. Of course, most of them wouldn't waste their time redesigning a password storage system; they'd use Mazieres/Provos "bcrypt" and be done with it.<p>If an article like this makes even a couple of neurons in your head light up, you have better things to do than reinvent the password storage wheel. Use somebody else's good system. This is almost security 101.

I've seen the misconception that a salt is a fixed string before, I don't know where people get that from. You don't pick a salt and use it site-wide, you pick a different salt for each thing you're encrypting, so the standard salting mechanism is more secure than this

To repeat the comment I made on the site:<p>The problem with this is you have created a pattern which could (and probably does) introduce a cryptographic weakness. If someone knew or could guess you were using this tactic then they might be able to exploit it.<p>While I don’t have an example of a specific weakness to MD5 to hand one of the basic rules of exploiting algorithms is knowing some of the source material or knowing about patterns within it.<p>The point of using a salt is to use a piece of unknown material which is unique in each string. It’s common to generate random junk to use rather than anything meaningful.<p>Personally I always take "new insight" into security tactics with a pinch of salt until they have been hammered on by a few people.

This for some reason struck me as a Homer Simpson moment - where he suggests every car come with one of those ribbons on the antenna so you can find it easier!

I use a unique random salt when hashing passwords in a db.<p>This is combined with another salt I keep in my codebase.<p>If the data in the db gets out, they still do not have salt stored in my codebase (unless the entire server has been compromised).<p>Right or wrong? Any thoughts?

a real attack might be like this<p>find rainbow table with a char space of<p>abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQURSTUVWXYZ0123456789!@#$%^&#38;*()_+=-';:"`<p>you now have a working hash map of 27-80gb of data.<p>upon looking through the user/pass table you see that the user/pass table has a salt key for each record. at this point you know that some portion of the passwords will be reversible with the salt being a confirmation of finding the correct password.<p>i know some of the rainbow tables out there are really fast at looking up a reverse md5 or sha1.<p>pass look up in rainbow table you will at least find a collision, and if you are lucky, you will find the pass concatenated to the salt entry in the table.<p>so if a hacker has your user/pass table, yikes.... ;-/ you are better off restricting read/write privileges to separate services. i would hate for a hacker to connect to your DB and to write their own salt and pass.<p>we were working on this for one of the defcon games last year.<p>NEVER REPLACE OBFUSCATION FOR REAL SECURITY.<p>fighting rainbow tables requires larger hash functions that generate larger hashspaces that are less likely to fit on a single machine. i still wonder how long it will take for a proper cluster of GPUs to virtualize the hash space of a rainbow table into computational power.

Thought exercise:<p>Then why not salt your hashes using some kind of lookup table on the password? With a bigger lookup table, you have a better chance of having a unique salt for most of your users. In fact, the bigger the table the better. But that takes up space, so why not use a function? But what kind of function? It should be cryptographically secure. Wait, I know, a <i>hash function</i> would be perfect!<p>Basically, this is just adding another gimpy home-grown round to your hash function. It will make the attacker's job slightly harder, but as others have pointed out, you can still match any password from the file.<p>I conclude that the best thing to do is to use a hash of the username as the password's salt.

Here's what I do:<p>$password = hash_hmac(sha256,$_POST['password'],"pound_on_your_keyboard_here");<p>256 bits of hashed goodness. Goodluck breaking that with a rainbow table.

While on the topic of password best practices, are there any characters which should not be allowed in passwords?<p>I've always assumed anything is safe since it's getting hashed anyway before hitting the db, but this got me wondering.