4 ms·
If you include the current password hash when calculating the hash for the reset link and you also include a random salt in your password hash, the reset link w
by mschwaig 12y ago
If you include the current password hash when calculating the hash for the reset link and you also include a random salt in your password hash, the reset link will become automatically invalidated because the password hash will change when a successful reset is performed.
- raziel2p 12y agoI think the point was, if I request a password reset X times for the same email within the duration of the expiration time, there'll be X amount of valid password reset URLs that can potentially be bruteforced. It doesn't matter if the other links are invalidated as long as one of them works. This is solved by rate limiting, I suppose. Feels like something that should've been included in the article.
- aptwebapps 12y ago> I think the point was, if I request a password reset X times for the same email within the duration of the expiration time, there'll be X amount of valid password reset URLs that can potentially be bruteforced. What does this have to do with whether you're storing tokens or using a hash?
- raziel2p 12y agoSorry for the late reply. In the apps I have, I delete any existing tokens for the given e-mail address when a new one is requested, so only one is valid at any given time.
- mschwaig 12y agoI think this problem can also be mitigated by the additional parameters in the reset link like the expration time. If these parametes differ you actually dont get to hash one thing and test it against all currently valid reset URLs to make brute force easier. You could even salt your reset URL deliberately. Of corse, I'm not arguing against rate limiting.