3 ms·

I don't understand how this can be an issue. This is usually what happens: > User enters password > PW gets hashed > Hash gets compared to the DB I don't kno

I don't understand how this can be an issue. This is usually what happens: > User enters password > PW gets hashed > Hash gets compared to the DB I don't know of any same system that would allow you to compare a hash to a hash? Unless you have access to something you shouldn't, in which case it doesn't matter anyway, because you can probably just read the hashes.

stordoff 9y ago
If the user knows exactly how the hashes are generated (I believe a random salt would prevent this), it could still be used to better target an online bruteforce, though other defences such as rate-limiting should still kick in. If, say, you submit a password with a hash that starts "b94", if the database doesn't use a constant time comparison, you can use the timing to figure out that the stored hash also starts with "b94" (statistically, given network etc. delays involved), meaning you can pre-filter your submitted guesses (i.e. bruteforce offline and only submit guesses that start "b94"). It's definitely a edge-case thought (and probably not worth worrying about unless you don't salt/rate-limit requests). I also don't know if the number of requests needed to determine the timing would actually be less than just making random guesses outright (intuitively it seems so because even if it takes a lot of requests it shrinks the search space at each step).