4 ms·

Doing it every time a user login failed is probably infeasible if you have even a moderate number of users, but you can presumably do it on an ad hoc basis unle

Doing it every time a user login failed is probably infeasible if you have even a moderate number of users, but you can presumably do it on an ad hoc basis unless you have a ton of users. Or am I missing something?

interfixus 9y ago
Yes you are. If you have done your security right, users' passwords are not stored in a form that lets you determine whether one is equal to another.
- alangpierce 9y ago
  It's a little different from determining if one salted hashed password is the same as another salted hashed password. Whether it's account signup ("the password is already in use") or login ("you typed in someone else's password"), you have the plaintext of the password, and can just loop through the user table and attempt a login for every user with that password. It's slow when you have a lot of users, as mnarayan01 mentioned, but certainly reasonable as an ad-hoc thing. (Not that any of this is good practice.)
  - interfixus 9y ago
    That's so horrible it never entered my mind. But you're right, of course, one could do that.
  - mark-r 9y ago
    You might be able to do it for all user names within a certain Levenshtein distance of the current user. That would handle mistyping, but it wouldn't handle the case where you have numerous emails and forgot which you signed up with on this site.
  - gregoriol 9y ago
    If you are able to do that, then I insist: you probably have failed at best practices. Most likely on this part: a good password hashing (ie. security hashing) should be fast so that you can log-in but slow enough to prevent brute force (ie. what you are implying). Hashings like md5/shaX don't have that: you can compute of lot them very quickly, which is their purpose. Bcrypt/Argon2/... will have a cost/time that will allow only a few computation per second, which is their purpose. So if you did best practices well, and try to loop through your users database, (I assume you have more than a few hundreds users) it might take some time, some long time. Anyway, you'll then fail at another best practice because the initial user trying to log in will get bored and be gone somewhere else ;-)

interfixus 9y ago

Yes you are. If you have done your security right, users' passwords are not stored in a form that lets you determine whether one is equal to another.

alangpierce 9y ago
It's a little different from determining if one salted hashed password is the same as another salted hashed password. Whether it's account signup ("the password is already in use") or login ("you typed in someone else's password"), you have the plaintext of the password, and can just loop through the user table and attempt a login for every user with that password. It's slow when you have a lot of users, as mnarayan01 mentioned, but certainly reasonable as an ad-hoc thing. (Not that any of this is good practice.)
- interfixus 9y ago
  That's so horrible it never entered my mind. But you're right, of course, one could do that.
- mark-r 9y ago
  You might be able to do it for all user names within a certain Levenshtein distance of the current user. That would handle mistyping, but it wouldn't handle the case where you have numerous emails and forgot which you signed up with on this site.
- gregoriol 9y ago
  If you are able to do that, then I insist: you probably have failed at best practices. Most likely on this part: a good password hashing (ie. security hashing) should be fast so that you can log-in but slow enough to prevent brute force (ie. what you are implying). Hashings like md5/shaX don't have that: you can compute of lot them very quickly, which is their purpose. Bcrypt/Argon2/... will have a cost/time that will allow only a few computation per second, which is their purpose. So if you did best practices well, and try to loop through your users database, (I assume you have more than a few hundreds users) it might take some time, some long time. Anyway, you'll then fail at another best practice because the initial user trying to log in will get bored and be gone somewhere else ;-)