[brlewis]

Are you saying that nobody uses hash dictionaries anymore and one need only worry about brute-forcing of individual passwords?

I'm not ready to stop thinking about hash dictionaries, and the 4-character salt I prepend to passwords before hashing is too short. A 4-character salt plus a 7-character password is a value that could be vulnerable to dictionaries roughly the size of the Rainbow tables.

But if you can cite a paper demonstrating that brute-force cracks of individual passwords are the only thing one need be concerned about, I'll look at it and see if it changes my mind.

[thomasptacek]

Nobody is saying you don't need to use salted passwords. What we're saying is, if your password scheme is (user, nonce, SHA1(nonce, password)), don't bother; just store your passwords in plaintext. Your users passwords are so weak (dictionary word + number) that a 200 line incremental cracker is going to blaze through it in hours.

The answer to this is to use someone else's (good) password scheme. If you're shipping on Unix, your system undoubtedly comes with one. Use it.

[brlewis]

If you mean to say that users should be forced to choose strong passwords, that's a different thing from saying longer salts don't make a set of passwords less crackable.

[thomasptacek]

I don't understand why people are hyper-focusing on this one attack. Attackers have been cracking passwords, quite effectively, long before tools like Ophcrack were available. Any decent salt scheme beats Ophcrack; it doesn't take much to make hash chain storage infeasible. But you can make your salts longer than JSESSIONID's and they still won't be a speed bump to a "conventional" password cracker.

I'm not arguing that users should be forced to choose secure passwords. They should, of course, but we're talking about how you store them. If you store them using a single-iteration SHA1 hash, then no matter how you structure your nonces, your scheme is insecure and you should be embarassed.

[brlewis]

When you say, "Increasing the length of your nonces doesn't make your passwords less crackable," you can expect that people will talk about the type of attack that a longer nonce helps deter. That isn't hyper-focusing; it's polite conversation. The impolite alternative would be to say you should be embarrassed for making a statement like that.

[thomasptacek]

I'm not saying you should be embarassed for conversing about this subject. I'm saying that if you store real people's passwords in a publically accessible web application using a single-iteration SHA1 hash scheme, you're insecure, and should be embarassed that you were outdone by password schemes that came with your operating system and were largely refined during the 1970s.

I ask, what type of attack do you think lengthening the nonce deters? The attacker who is going to construct 4 billion rainbow tables?

[brlewis]

I use a 4-character salt, which is prepended to the user's password before computing the hash. For users that choose a password of only 7 characters, that's only 11 characters hashed. The rainbow table covered a significant chunk of all 14-character strings. Even if I switch to a hash function that runs slower and produces longer values, I still think that 4 characters is too short a salt given the way things are going.

If I move to, say, a 16-character salt, after that I'll agree that making it longer is pointless.