Comments on: A New, Simple Way to Salt your Hashes

By: max191

max191 — Mon, 05 Oct 2009 08:40:17 +0000

I have discovered and learned much from your blog. Your blog is really good.
regards
charcoal grill

By: Kyle Lahnakoski

Kyle Lahnakoski — Tue, 05 Aug 2008 18:23:47 +0000

There is no advantage to doubling the password. Knowing that all salted passwords are just doubles effectivly adds zero bits of entropy: The hash for two identical passwords is still identical, and subject to the same rainbow table attack.

By: Kyle Lahnakoski

Kyle Lahnakoski — Tue, 05 Aug 2008 17:23:47 +0000

By: Justin Van Winkle

Justin Van Winkle — Mon, 04 Aug 2008 23:11:38 +0000

This doesn't do anything to thwart rainbow tables, other than increase the length of the password. The point (one of) of the salt is to make the hash of an obvious password unrecognizable. Another point is to thwart rainbow tables. For the first, any salt that doesn't happen to turn the password into a merely longer common value is fine (you don't want a salt of 'able', because if the password chosen is 'guess' the password + salt is 'guessable'). Also, you want the salt to have some non-printable values, so that an attacker would have to have a much larger set of computed rainbow tables to attempt to brute force passwords. Finally, you should have a different salt for every user, so that the attacker has to compute rainbow tables for each user vs precomputing for whatever set of salts you are using.

So, a salt should: Have non-printable and characters, characters with ord() > 128 and be unique per user. That way, every password is drawn (potentially) from the full space of available byte values, making lots of attacks harder.

By: Justin Van Winkle

Justin Van Winkle — Mon, 04 Aug 2008 22:11:38 +0000

This doesn’t do anything to thwart rainbow tables, other than increase the length of the password. The point (one of) of the salt is to make the hash of an obvious password unrecognizable. Another point is to thwart rainbow tables. For the first, any salt that doesn’t happen to turn the password into a merely longer common value is fine (you don’t want a salt of ‘able’, because if the password chosen is ‘guess’ the password + salt is ‘guessable’). Also, you want the salt to have some non-printable values, so that an attacker would have to have a much larger set of computed rainbow tables to attempt to brute force passwords. Finally, you should have a different salt for every user, so that the attacker has to compute rainbow tables for each user vs precomputing for whatever set of salts you are using.

So, a salt should: Have non-printable and characters, characters with ord() > 128 and be unique per user. That way, every password is drawn (potentially) from the full space of available byte values, making lots of attacks harder.

By: Matt H

Matt H — Mon, 04 Aug 2008 17:49:08 +0000

IMO, the best salt is randomly picked for each hash. That way, if someone steals you user table, they can't tell if two users share the same password..

By: Lennon

Lennon — Mon, 04 Aug 2008 17:01:22 +0000

Actually, the comments claiming that this adds *no* security are wrong. Doubling the username and hashing it does prevent one class of attack that a non-salted (or single-salted site) password database is vulnerable to: rainbow tables. If there's no variability in the inputs to your hashing function (and re-using the same salt for all inputs is basically just defining a new, site-specific hashing function) an attacker can pre-generate hashed versions of easily-guessed passwords, and try an offline attack against your database to see if any of their guesses match an entry in the DB.

However, there is certainly some value to generating a unique nonce for each hashed password, and storing it alongside the password. It doesn't have to be truly *random* though; since it's sitting right there in the record, it's not of the class of value like a private key where both entropy and secrecy matter. You can use the username, or the timestamp for when the password was reset, or any other easily-retrievable datum.

By: Matt H

Matt H — Mon, 04 Aug 2008 16:49:08 +0000

IMO, the best salt is randomly picked for each hash. That way, if someone steals you user table, they can’t tell if two users share the same password..

By: Lennon

Lennon — Mon, 04 Aug 2008 16:01:22 +0000

Actually, the comments claiming that this adds *no* security are wrong. Doubling the username and hashing it does prevent one class of attack that a non-salted (or single-salted site) password database is vulnerable to: rainbow tables. If there’s no variability in the inputs to your hashing function (and re-using the same salt for all inputs is basically just defining a new, site-specific hashing function) an attacker can pre-generate hashed versions of easily-guessed passwords, and try an offline attack against your database to see if any of their guesses match an entry in the DB.

However, there is certainly some value to generating a unique nonce for each hashed password, and storing it alongside the password. It doesn’t have to be truly *random* though; since it’s sitting right there in the record, it’s not of the class of value like a private key where both entropy and secrecy matter. You can use the username, or the timestamp for when the password was reset, or any other easily-retrievable datum.

By: me

me — Mon, 04 Aug 2008 15:52:14 +0000

The problem with this is you are not really salting your hashes. You are just making the passphrase longer. You could add '1234' at the end of everything you hash and don't tell anyone about this. Maybe read http://en.wikipedia.org/wiki/Salt_%28cryptograp...