5 ms·

How is this for a "decently secure" password reset method ? - User enters email address to reset password - A reset link (uniquely hashed,salted etc.) is gene

How is this for a "decently secure" password reset method ? - User enters email address to reset password - A reset link (uniquely hashed,salted etc.) is generated server side tied to that specific email address. This link can only be used once and also has a expiry date if un-used by that time. - If this reset link is accessed (hopefully by the intended user), A form is presented to the user where it asks to enter the email address, new password. If entered email address does not match the original email, user gets an error. Immediately, all sessions are invalidated/reset if any. If entered email address matches, then reset the user's password. Again, invalidate/reset any existing sessions. - After resetting password, never login the user directly. Ask them to login manually again.

mixedbit 14y ago
I think the large source of problems for password resets is not how the flow is designed from the user perspective, but how it is implemented to handle corner cases that normally rarely occur. Such corner cases are likely to be not well though-out and poorly tested. For example: A user with a valid session cookie for one account, follows a password reset link for some other account. Or a user generates a password reset link, logs in with an old password, changes the password and follows the reset link. There are many such tricky cases and the challenge is to explicitly design how they should be handled and cover them with tests.
- tptacek 14y ago
  It is this kind of thing --- the password reset code not expecting ever to be hit from a logged-in session, because it's used in the real world exclusively by people who can't log in --- that create 1/2 the bugs in the real world with password resets. You will find blatant bugs that nobody in the world could possibly miss, except that everyone on the dev team missed them because who tests a password reset from a logged-in account? "What? Every page gets 'current user' from a common header included in every file that it pulls out of the session, and this page also takes 'email address' from a parameter passed in by the user? OOPS."
skymt 14y ago
> After resetting password, never login the user directly. Ask them to login manually again. What vulnerability could this close? In order to finish the reset procedure in the previous step, any attacker would need to know the user's email address, and the attacker would obviously know the new password that was just set. I'm probably missing something, but I don't see this extra step adding any security.
tptacek 14y ago
The only way this fiddly scheme could be secure is if the randomizing information (that prevents an attacker from brute forcing the hash against all possible email addresses) is different for every token and thus stored somewhere serverside. It is no more secure than simply sending the user a random token, but has all the logistical challenges of storing a token. So just use the token.
- codegeek 14y ago
  "stored somewhere serverside" So you are a strong advocate of generating the token and storing it in the db.
  - tptacek 14y ago
    That is the simplest possible answer and so it's the one you should use.

mixedbit 14y ago

I think the large source of problems for password resets is not how the flow is designed from the user perspective, but how it is implemented to handle corner cases that normally rarely occur. Such corner cases are likely to be not well though-out and poorly tested. For example: A user with a valid session cookie for one account, follows a password reset link for some other account. Or a user generates a password reset link, logs in with an old password, changes the password and follows the reset link. There are many such tricky cases and the challenge is to explicitly design how they should be handled and cover them with tests.

tptacek 14y ago
It is this kind of thing --- the password reset code not expecting ever to be hit from a logged-in session, because it's used in the real world exclusively by people who can't log in --- that create 1/2 the bugs in the real world with password resets. You will find blatant bugs that nobody in the world could possibly miss, except that everyone on the dev team missed them because who tests a password reset from a logged-in account? "What? Every page gets 'current user' from a common header included in every file that it pulls out of the session, and this page also takes 'email address' from a parameter passed in by the user? OOPS."

skymt 14y ago

> After resetting password, never login the user directly. Ask them to login manually again. What vulnerability could this close? In order to finish the reset procedure in the previous step, any attacker would need to know the user's email address, and the attacker would obviously know the new password that was just set. I'm probably missing something, but I don't see this extra step adding any security.

tptacek 14y ago

The only way this fiddly scheme could be secure is if the randomizing information (that prevents an attacker from brute forcing the hash against all possible email addresses) is different for every token and thus stored somewhere serverside. It is no more secure than simply sending the user a random token, but has all the logistical challenges of storing a token. So just use the token.

codegeek 14y ago
"stored somewhere serverside" So you are a strong advocate of generating the token and storing it in the db.
- tptacek 14y ago
  That is the simplest possible answer and so it's the one you should use.