Take a few minutes and re-evaluate your password reset scheme. They are treacherously difficult to get right. Every pentest we did, we made a beeline for the password reset functionality; it was often a cheap, quick gameover bug.
1. An anonymous person sends a message via Google Chat to the support Gmail address.
2. A staff member would ask the anonymous person for the username of the account for which to reset the password.
3. The anonymous person would present the username.
4. The staff member would reset the password and create a temporary password and would then give that anonymous person the password. The staff member would then explain how to change the password once the anonymous person had logged in with the temporary password.
I spent too long trying to explain to the staff and the CEO why it was a problem that any person could gain access to any account...
One employer some time ago would only do password reset if you turned up in person with photo ID. That organisation had quite a lot of students spread over a number of sites so it was labour intensive - the library staff used to be able to reset passwords and they had access to the student and staff badge photos. IT staff at a University I taught at for a year would only reset password if you went on a conference call with a manager level staff member who could confirm recognising your voice.
For a general access Web site available nationally and not tied to an institution I imagine you would have to fall back to the usual email reset code with challenge question type systems.
* Encrypting tokens and expecting users to feed back the same encrypted token, and failing to authenticate.
* Simple parse errors and SQL injection on the tokens themselves.
* Exploitable generation (for instance, non-cryptographic RNGs) for the tokens themselves.
* Having multi-page flows starting from the receipt and validation of a reset token, and then having standard web flaws somewhere in that flow (for instance: userid is validated only at the start of the flow).
* Mishandling of cases where users have multiple outstanding reset requests.
* Accepting the email address to send token to from web user, validating the address, and then using the user input directly as the email address to send the token to; as in: systems that will send token to user@real.com;attacker@evil.com.
One bug everyone has in their password resets: they don't cancel outstanding tokens when users change their passwords, so that long after a user has reset their password, their email boxes still contain password-equivalent tokens. That's not a high-severity bug, but it's a meaningful one.
* Accepting the email address to send token to from web user,
validating the address, and then using the user input directly
as the email address to send the token to; as in: systems that
will send token to user@real.com;attacker@evil.com.
Sigh adds to wunderlist
user@real.com\nCc:attacker@evil.com
If you do a "is this even a valid email?" check and a "exists user by email" check with that input (assuming no SQLi, of course), would this even be possible? I'm failing to see what the vulnerable code would look like in that scenario.
> One bug everyone has in their password resets: they don't cancel outstanding tokens when users change their passwords, so that long after a user has reset their password, their email boxes still contain password-equivalent tokens. That's not a high-severity bug, but it's a meaningful one.
This is solved by simply deleting the tokens after reset, correct?
They should also time out after a day or two and either invalidate or delete.
The right way to do that is to HMAC a string... see this blog post https://neosmart.net/blog/2015/using-hmac-signatures-to-avoi...
You can get expiration and many other nice things without having to worry about a whole class of other issues.
To make a password reset all previous reset tokens, simply include an autincrementing number for "passwordVersion" and stick that sucker in the HMAC as well.
Some other disadvantages were pointed out in the previous discussion[1].
I think the strength of your statement here is not warranted – in the context of security, there's no flaw from doing that. Likewise, saying "HMAC" is "the right way"... well, I wouldn't agree with that.
If you do HMAC, you only have time-based expiry. Thomas was talking about tokens sitting in email inboxes that are still valid and are effective passwords... you can't make your HMAC tokens expire as soon as they're used, so that's still a concern.
I remember reading about this HMAC/"no database" technique and thinking it was pretty cool.
Is it because you may want to encode more fields than just expirationTime, but also (say) lastLoginTime and such, so the GET URL would get awkwardly long (and possibly break in some email client), or is it something more fundamental than that?
Cause I thought that using the HMAC as a primitive was the right way to get hash-based authentication right, as opposed to messing around with actual cryptographic hashes.
* Not requiring any additional authentication once you have the reset link from the e-mail
even reddit is vulnerable to this:
https://np.reddit.com/r/funny/comments/3egphk/icets_seen_som...
It's fairly common to see reset tokens going in to the database verbatim, instead of treating them as passwords and stashing away a hash (single SHA is fine if your tokens are long and random).
example.com/password_reset?username=<username>
You could basically type that in and replace <username> with any username you wished and reset their password.
The sad part was how obscenely long it took them to close those holes (couple of weeks).