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

[thomasptacek]

Even if they're just the isprint characters, that's still 74MM variants on every hash. Stop thinking about rainbow tables. Nobody is going to rainbow table your weak salted password scheme. They don't have to, because you're using native SHA1 as your hash!

[brlewis]

Even worse, I'm using md5 as my hash, just because it was built into postgresql. I should do more to protect users who choose weak passwords, as I feel they should be allowed to do so for my site. (They also have the option of never choosing a password and always logging in with a one-time link.) What tends to bother me more is the idea of someone choosing a reasonably strong password, one that isn't vulnerable to reasonably-expected brute-force attacks, and having some new dictionary attack crack it just because I was stingy with my salt. The other reason I worry about the cracking of strong passwords more is that it's more likely that a strong password would be shared with banks, etc.