Hacker News Reader

Comment by dekz | Hacker News Reader

Aren't the salts stored within the hash $type$salt$hash

Yes. $1$salt$ciphered-text

The $1 is for MD5, the salt includes that $1 and the last $, so to crypt the text in php you do crypt($password, '$1$salt$'). Use single quotes to prevent $ from turning into variables. $password in this case (according to mtgox) was md5('password string').

What is the point of storing the salt with the hashed value?

Attempting to hide it somewhere else doesn't really help when your whole system is compromised. Salting+hashing isn't the answer to 'how to store passwords so no hacker can ever get them', it's the answer to 'how to store passwords so it would take a very very long time and a lot of resources for a hacker to ever get them'. It's designed like this to also allow easy authentication of users by simply performing the same process used originally. So the only real thing storing the salt somewhere else would accomplish is greater latency for authentication.

Sorry I should have rephrased that, I really meant "isn't using any kind of salt at all deprecated"? Honest... :-)

http://codahale.com/how-to-safely-store-a-password/

[Edit: I meant your typical web application mucking about with salts, not their use within properly thought out things like bcrypt]

Bcrypt uses salts. But your link is correct, attempting to roll your own crypto is getting all these companies caught out and bad crypto use is causing their users to suffer. I for one would now not feel safe using a password for more than one website.

I believe the standard library for bcrypt in ruby also uses salts, it just stores the salt with the hashed password data.

Salts will prevent the typical rainbow table attack where you have precomputed hashes for a large number of attempts. Salts won't prevent brute force, but bcrypt will make it so that brute force takes too long for a single given user.

Reply on news.ycombinator.com