ansaurus

Question

Answer 1

+3 A:

Are you storing the salt with the hashed password? You need to use the same salt when checking the hash - each user should have their email address, salt and hash stored.

Greg 2009-10-18 13:05:53

Greg is correct. You will either need to store the salt in a separate db field or include the salt in the hash with a delimiter like this:$hash = $salt . '$' . sha1($salt . $password . $email);

Mark 2009-10-18 14:13:10

Answer 2

A:

You want a constant string for your salt, eg

$salt = "iodized sea salt"

EDIT: The commenters and downvoters here seem not to understand the concept of a salt. Using a constant salt certainly would not defeat the purpose of the salt, which is to make your choice of hashing algorithm ("SHA1 with such-and-such a salt") private. This salt can be long and its choice has more entropy than, say, uniqid(mt_rand()). You can't brute force a long salt any time this side of never. A per-user salt might make you feel better if you're not clear on computer security, but doesn't provide any other benefit.

Grumdrig 2009-10-18 13:07:06

You realize this removes the whole point of a salt?

Yacoby 2009-10-18 13:10:07

Not completely - it's still better than no salt. It just means an attacker would have to generate their own rainbow table rather than using an existing one.

Greg 2009-10-18 13:29:06

It's not much better than using no salt at all. Using a constant salt will allow an adversary to do a brute force search against the whole set of acquired password hashes all at once, instead of only a single one.

Inshallah 2009-10-18 13:32:58

Oh _ I see where you guys are being tripped up. Yes, hash($constant_salt, $password) would be less secure than hash(user_salt($username), $password). But user_salt($username) is $constant_salt . $username which is no more knowable to an attacker than one generated some other way. $constant_salt is secret information.

Grumdrig 2009-10-19 17:48:30

@Grumdrig, salts are not supposed to be private information. That's why we're using password hashing algorithms, so that we don't have to store secrets anywhere. Storing an additional secret in your codebase can only be considered obfuscation, not real security. (Both, the database and the codebase must be readable by many people, and an adversary who can gain access to one, may well gain access to the other).

Inshallah 2009-10-20 14:50:41

Let's look at it another way. Let's say that using the SHA-256 crypt algorithm makes brute forcing a single password 10000 times more difficult than using a plain hash. However, if an adversary has gained access to 10000 password hashes computed with a constant salt, and he only needs to break a single one to be successful, then his task has become about 9999 times easier, and that would void any benefit gained from the more costly crypt algorithm.

Inshallah 2009-10-20 14:55:48

Also, don't sweat the downvotes. The fact that there have been several comments makes this answer a good reference for the constant salt issue.

Inshallah 2009-10-20 15:09:16

Thanks for the words of encouragement, @Inshallah. :)We should probably have been more careful about defining our threat model; yours as I read it is an attacker with full access to code it's a per-user salt.

Grumdrig 2009-10-20 19:29:00

And to clarify, we probably agree that keeping a constant salt secret has equal utility to keeping per-user salts secret. At least I hope we do.

Grumdrig 2009-10-20 19:32:35

@Grumdrig, ah, I get what you mean; rather than computing the salt from a RNG generated value, or the current time, or some other external factors, you suggest that the salt be computed from *constant* information about the user; that way the OP's original problem about salt storage would be solved. I don't really see a problem with that, though I should note that you probably want to run the salt through a hashing function once; I don't really know why, but it would make me feel safer about using this approach :-).

Inshallah 2009-10-20 20:28:25

I *do* think that hashing-in a secret value would be ideal, whether that value is per-user or global. In fact, having a global secret is probably a better idea, since it only needs to be generated once and can then be stashed away somewhere; if it's easier to handle, it's easier to keep secret.

Inshallah 2009-10-20 20:39:30

Answer 3

A:

Yes, sha1 is a better hash than md5. Much of the time tho, md5 is good enough... Really, how "insecure" your site is is determined much more by other factors.

dicroce 2009-10-18 16:23:57

I suppose it depends a bit on how determined an adversary is to break you security. Finding MD5 collisions _is_ practical with a certain amount of computing power, and computing power is not that difficult to come by.

Inshallah 2009-10-18 16:39:04

just because some other part is insecure is not an excuse for using an algorithm that is cryptographically broken and unsuitable for further use.

Jacco 2009-10-18 20:42:33

I was referring to non primarily security focused uses of MD5... Sure, use sha1 for your password hashes... But there are plenty of uses for hashes (for example, file modification detection) that work perfectly well with md5... I'm not trying to argue that someone should use an insecure hash, just that I bet his site securing energy would be better spent on form validation or protecting against xss than the security difference between sha1 and md5...

dicroce 2009-10-18 22:10:26

ansaurus

tags:

views:

answers:

changing from md5 to sha1,salting

related questions