Then the rainbow table can only be used with this specific site. This makes it no more efficient than brute forcing. You can store the hashes yes, but you can also include the cracked passwords in the dictionary and it takes only slightly more time to compute them even with unique salts.

Site-wide salting has almost the same security as per-user salt, as long as the salt is not leaked or cracked before the database is leaked for pre-computation.

A database-wide salt makes cracking the database as hard as forcing one password. You only need to do the computation once and then you have a super-quick lookup for all the other hashes. Per-entry salts totally bust that.

>This makes it no more efficient than brute forcing.

Jesus, no. It absolutely does make it more efficient than brute forcing each password.

I compute one rainbow table that I can run against 10,000 users. Or I brute force 10,000 users' passwords because they have unique salts.

>_< God, I need to just accept the fact that people are going to talk out their ass about this and stop trying to get people to spread bad, insecure information.

oh sweet jesus of irony, you're the guy that was wrapped up in Bitcoinica.

Oh, I got it. My brain wasn't working then.

Don't worry, I use per-user salts for all my web projects following all security best practices that I know.

Out of curousity - is it a salt if you do something like this:

salty = md5(md5(pw) . pw . 'poniesaremagical' . md5(username));?

It is per-user... how is it different than using a timestamp which will be as unique as username?

Technically yes, but don't use md5 for anything security-related ever. It's broken. http://www.mscs.dal.ca/~selinger/md5collision/ is just one example. (I also remember reading some years ago that md5s within md5s can make the resulting hash more vulnerable to certain attacks but I don't have any formal knowledge in cryptology to say for sure.) Use bcrypt/scrypt and you're automatically protected from both rainbow tables and brute force.

H(Salt . H(Password)) is a lot like an hmac (minus the secret part and the padding). I'm not sure about the pre-image vulnerability mentioned on wikipedia's md5 page, but as for collision vulnerabilities, according to wikipedia's hmac page, "HMACs are substantially less affected by collisions than their underlying hashing algorithms alone. Therefore, HMAC-MD5 does not suffer from the same weaknesses that have been found in MD5."

It's not salty enough for my taste. What you've done is no different than:

  H(H(Password) + Salt)

If I steal your db and have another db that contains your user's unsalted password hashed with the same hash function, I can easily test if the same password is used in both places, simply by replacing H(Password) with the other hash. This leaks information and provides incentive to continue trying to crack the easiest target, if I really want what you have.

A simple change makes this comparison impossible:

  salty = H(H(Password + Salt)

Now there's no place to plug in the other hash, so I can't tell if the accounts share passwords until I successfully crack one and try it on the other. I might not bother and focus on lower hanging fruit.

Always assume your salting method is public, even if you make attempts to keep it secret. And remember that your site isn't in isolation; your user and every site they interact with are also potentially weak links in the chain.

Note that the examples above are oversimplified. You should look to a better authority on how to properly store passwords. In a future leak, we'll be surprised that the sites involved only salted their passwords.

Yes, as long as you use some salt data that is unique per user (timestamp, random number/guid/whatever) (you have to store that obviously), then it's fine. The problem is acting as if a site-wide salt is an ok-thing. It's not.

Incidentally, as the guy who started this whole thing, I'd just like to note that I actuslly agree with this. When I said they were "OK" or whatever, I meant it in the sense of "I guess it's good they're doing something," not like I'd recommend it. Please nobody get that idea.