[timo_h]

At least, testing passwords against multiple hashes (at the price of one) is impossible. And it is not possible to see if different entries shares a same password (or to see if they have a different password). Also, it (probably unintentionally) mitigates timing attacks when comparing if the entered password matches.

[phaemon]

>testing passwords against multiple hashes (at the price of one) is impossible

That's defending against a newly generated rainbow table.

> And it is not possible to see if different entries shares a same password (or to see if they have a different password).

That's repeating the first point with different words! It's defending against a pre-generated table. i.e. a rainbow table.

Timing attacks are not mitigated by salts; they're mitigated by the design of the encryption. You should not rely on salts for this. In fact, if your hash is exposed you should assume your salt is also exposed.

What do salts guard against other than rainbow tables?

[timo_h]

> That's defending against a newly generated rainbow table.

You lost me here. Anyway, the attacker does not need a rainbow table at all to attack against multiple hashes at the price of one.

> That's repeating the first point with different words! It's defending against a pre-generated table. i.e. a rainbow table.

Again, no rainbow tables at all are needed to see if different entries shares a password or not.

About timing attacks, see my earlier comment in this comment chain.

> You should not rely on salts for this. In fact, if your hash is exposed you should assume your salt is also exposed.

I see and agree with your point about "relying on salts", but salts just happens to (as a side-effect probably) mitigate the attack. Remember, your salts are not exposed "as-is" if the attacker manages to fetch the password hash using timing.

[Dylan16807]

As long as the salts are relatively unique, the first two aren't an issue. I don't understand how salts could help against timing attacks, though.

[timo_h]

> I don't understand how salts could help against timing attacks, though.

The salt which is unknown/unpredictable (and contains enough entropy) to the attacker makes his offline attack against the hash unfeasible (after he has managed to fetch the password hash from the server using timing leaks). I'm not sure if it is possible to fetch the (whole) hash using timing, because it is not a direct comparison. But anyway, if the attacker managed to do that, now because of "a proper salt" he would have to crack a hash that was composed of, say, 128 bits of salt and 20 bits of the actual password. It is unfeasible because of that 128 bits of salt alone.