After requesting a password reset, the sent token may be used multiple times (even with different passwords) and is not consumed after use
Intercepting the reset token could therefore be used to define a new password for a foreign user (since no further authorization is needed)
This is true. A reset token is a time limited authorization that allows a password change without knowing the existing password. For each token requested, there’s a 1 hour window from the time of request that the token is good for. We could add additional machinery to disable tokens after use, but I’m not sure if that’s going to make things any more secure. If someone has access to your email, then they basically can take over your account.
There is an additional threat vector which comes from these tokens being sent via email - now it stands to reason that if someone were to gain access to our transactional email provider’s system and then began monitoring it for emails that looked like password reset emails they could intercept tokens and use them for up to one hour from the time they were issued. Locking down the token could potentially make this more difficult, but not impossible if you were using the intercepted tokens quickly enough.
Because any exploit I can think of requires someone gaining access to our transactional email host, or a customer’s email - and these targets contain much more tempting things than our password reset tokens, I’m not inclined to prioritize a change to make password reset tokens expire on use. I could definitely make the token expiration user configurable.
Do not forget the way how email is often read these days: using web clients.
I do not want to discuss, how dangerous a token re-use could be (I’m not a security expert) - it just surprised me that a token granted for a single operation could be reused
I’m not sure why reading email with a web client would be any different than reading it in a dedicated client in this day and age. If you have a way to break out of the tab sandbox, then I would report that to Google, Apple, or Firefox - you’re likely to get a reward. If you’re suggesting problems with a public computer and reading your email on it - then yes, that could be an issue - but again, a threat actor would likely be looking for bank information long information for our service.
In this case the token isn’t granted for a single operation - you can think of it more as granting you limited access to perform one action (update a password) for the next hour. From an engineering perspective this simplifies things greatly. However, given your concerns I will log an issue to create more infrastructure to make sure that these tokens are single use. I can’t promise when it will be implemented, but given the godlike access you would require to actually exploit this, I don’t believe it’ll be a high priority. I hope you understand.
Of course, I understand - and I do not worry too much, indeed.
It just surprised me that a token (which I expected to be a one-time token) could be used multiple times…