[nothrabannosir]

this is not about rainbow tables, just about brute forcing. The only theoretical protection would be a site salt, but that has to be stored somewhere as accessible as the database, so it's fruitless to assume somebody who can get their hands on your db can't get the site salt.

"It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database."

- http://codahale.com/how-to-safely-store-a-password/#

tptacek 1708 days ago

That salt is a public value. The security of salted password schemes is meant not to depend on the secrecy of the salt.

Every time this topic comes up, 15 people chime in with various schemes in which some of the "salt" is derived from the hostname and some of it is stored in an encrypted vault and some of it is inferred from the color of the user's eyes. This is why Coda is making fun of "Himalayan pink salt".

- https://news.ycombinator.com/item?id=2004833

[xxs]

Adding the salt increases (albeit linearly) complexity of hashing w/ regard to brute forcing. So using a very long salt reduces hash speeds.

[dagw]

There are much better ways of reducing hash speed. Like hashing N times.

[xxs]

I am not discussing it, however:

>>It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database<<

simply, it's a false statement. Multiple hashes while adding the same (huge) salt each time decreases the speed even further. Just adding 8MB (larger than L2 cache or any reasonable amount of SRAM to mount) of salt might be better than multiple hashings as well, plus it increases difficulty of mass-parallel processing. Multiple hashes are very L1 cache friendly when the input is tiny.