> * 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
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?
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.
> If you're saving a token in the database to delete, you're doing it wrong anyways.
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.
The top "disadvantage" discussion in that thread is about somebody messing up their links because they rolled their own base64 encoding with period characters in it ... or something like that. I'm not even sure what they were thinking, but there's nothing about keeping reset tokens in the database that would prevent their problem.
Strong disagree. You are much better off saving tokens than you are in using HMAC or any other cryptography to try to extend your security boundary to email. There is more that goes wrong even with simple HMAC tokens than there is with opaque random tokens.
Can you shed some light about what could go wrong?
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.
If you have to validate, you're doing something wrong (but this is a something wrong people do sometimes do). You should send email only to the string you saved in the database record for the user.
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?