Code Spatter: A New, Simple Way to Salt your Hashes
http://www.mybloglog.com/buzz/
· 1 year ago
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.
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.
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.
Greg Allard
· 1 year ago
I was thinking that if someone were to get ahold of the user table, they would know the salt used and with a lot of time and horsepower try many words with the salt. Hiding the salt in any way would create some kind of pattern, but I wouldn't know how much weaker that would make it. Guessing that this tactic might be used would probably be easier than getting ahold of a random salt.
Nick Hoffman
· 1 year ago
Don't do this. The whole point of a salt is that it's a completely unknown, as-close-to-random string of characters as possible.
As sh1mmer said, introducing patterns or predictability into a crypto system compromises the system's security.
There are many easy ways to easily generate a "secure" salt. Eg: -Use a seeded PRNG in your language. -Read from /dev/random . -Use the ID of an object in your program/script.
Cheers, Nick
me
· 1 year ago
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...
Lennon
· 1 year ago
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.
Matt H
· 1 year ago
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..
Justin Van Winkle
· 1 year ago
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.
Kyle Lahnakoski
· 1 year ago
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.
All Comments
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.
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.
As sh1mmer said, introducing patterns or predictability into a crypto system compromises the system's security.
There are many easy ways to easily generate a "secure" salt. Eg:
-Use a seeded PRNG in your language.
-Read from /dev/random .
-Use the ID of an object in your program/script.
Cheers,
Nick
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.
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.