A New, Simple Way to Salt your Hashes

Posted on August 4th, 2008 by Greg Allard in Programming |

Maybe I’m not the first to think of this, but it just came to me. Instead of using a single string to season a whole site or saving each new salt with the salted hash, try using this method for simplicity. Take the string and concatenate itself after it. This way, both the value being encrypted and the salt are never known and it’s still simple to validate input. Might be helpful if you actually fear someone building new dictionaries for each salt… or quantum computers.

And Why I Love Comments

Smart people keep you from doing something you didn’t think through. So, don’t use this.

Viewing 8 Comments

http://www.mybloglog.com/buzz/ 3 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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.

reply edit reblog flag

Greg Allard 3 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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.

reply edit reblog flag

http://codespatter.com

Nick Hoffman 3 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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

reply edit reblog flag

me 3 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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...

reply edit reblog flag

Lennon 3 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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.

reply edit reblog flag

http://rcoder.net/

Matt H 3 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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..

reply edit reblog flag

Justin Van Winkle 3 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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.

reply edit reblog flag

Kyle Lahnakoski 3 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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.

reply edit reblog flag

Trackbacks

(Trackback URL)

Code Spatter