4 ms·
I would expect that you'd just compare the hash, effectively performing half of the log in process to check if the password's okay. I imagine it'd be pretty cos
by Fletch137 14y ago
I would expect that you'd just compare the hash, effectively performing half of the log in process to check if the password's okay. I imagine it'd be pretty costly in terms of performance if every time you wanted to create a new user you had to hash the password, then check against a (potentially huge) table to see if that password had been used >X times.
Hopefully I'm being short-sighted or missing something that'd mean this could be done simply and quickly, because in theory it sounds like quite a good idea.
- omh 14y agoIf you're using per-user salting (and you should be) then you have to do n hash calculations, not just one calculation and n comparisons. Might be feasible for a small number of users on an internal app, but unlikely to work on a big or public site. I'd also be worried about information leakage. If you tell me that I can't use my password then I now know that it's used by someone else. If I work out who that is (which could be quite easy) then I can impersonate them.
- Fletch137 14y agoEven more performance-intensive than I thought - possibly why it's not been implemented. Assuming you know that a given password can be used 10 times and there's a database of 100,000 users in your scenario above, how would you work out who that is?