Comments on: Let’s talk about your password model

By: Clark

Clark — Wed, 17 Feb 2010 05:30:50 +0000

I will edit some new details into the article soon, but for now this part is important.

If you use a static salt, you’re doing yourself a disservice; using a static salt is just as bad as using no salt at all. Once they break the salt, it’s just a matter of generating one new table and the database is just as compromised. Using a salt based on other user data (username, etc) is a step in the right direction, but dangerous if that data can ever change (as it will destroy your ability to check the password).

When using a random salt, leaving it in the generated string is just fine, because it will still require the cracker to generate a new table/attack vector for each individual password in the table, which is the goal of using the salt. You, however, will need to be able to retrieve that salt on a whim, so prepending it to the generated hash (as crypt automatically does) is a logical way of doing it.

One again, using a static salt is as bad as no salt at all. Check out that paper from M.I.T. linked near the beginning for info on why (long story short, once someone knows your never-changing salt they are in control, and they will find out). And, storing the generated salt right there with the password is a recognized A-OK technique. Generating a salt yourself every time couldn’t be easier:

crypt($password, '$2a$07$' . md5(microtime()));

Finally, if you wanted to store the salt string separately (or just want to be able to separate them), the hash is only the last 32 chars, e.g.

$hash_without_salt = substr($hash_with_salt, -32);

By: Confused man

Confused man — Tue, 16 Feb 2010 23:18:53 +0000

gah, i misread it “/” and “+” are the alphabet characters you can use. I’d add that somewhere in your article so that those of us who are confused can be helped a bit better. Sorry about all of these comments but since you can’t edit any post you say without actually being approved i had no other way of editing things as i realized hwo foolish i was.

By: Confused man

Confused man — Tue, 16 Feb 2010 23:17:14 +0000

nevermind, i tried it for myself, after trying around with a static salt set by myself, and it seems to be working just fine. i’m just going to have to remove said salt from the string itself or else the hacker once getting into the database will be able to get it all. I’m probably just going to use some sort of explode type thing and use the “.” character as the point of explosion, since that’s what the crypt seems that it’s set to put that before the actual encrypted string. Thanks for explaining this in greater detail for me. Now i can finally use this thing. If you wish to delete the other comment so be it, i just was posting without understand how it all worked since i was planning on using a sha256 encryption, but now realizing how easy it’s going to be to use(allbeit i can’t use any special character for the salt even a “-”,”+”).

By: Confused man

Confused man — Tue, 16 Feb 2010 23:02:50 +0000

Ok, this is one thing i don’t understand. Maybe you can clarify this for me. If you’re telling it to make it’s own salt on the fly for the bcrypt, wouldn’t this make password validation impossible?

Since each salt makes the end encryption different? Wouldn’t this render this type of hashing completely and utterly pointless?