3 ms·

>HMAC256("userId=johnnysmith&expirationTime=1356156000&oldBcryptHash=$oldBcryptHash&clientIpAddress=$clientIpAddress", $mySuperSecretKey) Maybe I'm wrong but h

by Kenji 12y ago

>HMAC256("userId=johnnysmith&expirationTime=1356156000&oldBcryptHash=$oldBcryptHash&clientIpAddress=$clientIpAddress", $mySuperSecretKey) Maybe I'm wrong but he can still use this password reset if he remembered his login and logged in. ID stays, it might not be expired, BcryptHash stays, Ip stays. That, of course, is suboptimal.

maxerickson 12y ago
It will be checked against the current hash. The reset creates a new hash, so the token won't work a second time.
- pests 12y ago
  Hes saying the user logs in with their normal password and takes no other action on the reset. The reset is still valid until the expiration.
sk5t 12y ago
I don't understand what problem you are describing. A user who remembers his momentarily-forgotten password can of course change or reset it regardless. The article quite sensibly describes using the old password hash as a nonce without pestering the database with extraneous records.
- Kenji 12y ago
  It would be nice to stop all reset tokens if the user has logged in after the reset tokens were made. But you're right, it's not really a problem unless one chooses make it one ;)
  - sk5t 12y ago
    One could overcome this by tracking the user's last password-driven login date and rolling it into the MAC; alternately, just use a short expiration time on the reset token and don't sweat it.
    - morgante 12y ago
      But that's just introducing additional state (last login date), so if you're starting to do that there's not much point in the HMAC approach.
      - yeukhon 12y ago
        I think it all comes down to what benefit your user's security. If you want to expose to user his or her account's activity, like history of recent password reset, recent login activity, things that a typical FB user would see in the user's activity page, that can be a really nice security feature. So maybe after all the HMAC approach works just fine with extra state added. But I think the point the author is bringing is that the application can simply just do HMAC(.....) easily and verify in a few lines of just if and else branch, whereas the traditional password reset code would probably take more lines and more conditions. I had written code that did exactly what the author didn't like and trust me that code wasn't pretty and I had spent many hours to optimize the code. Edge cases and test cases shitted my codebase.

by Kenji 12y ago

maxerickson 12y ago

It will be checked against the current hash. The reset creates a new hash, so the token won't work a second time.

pests 12y ago
Hes saying the user logs in with their normal password and takes no other action on the reset. The reset is still valid until the expiration.

sk5t 12y ago

I don't understand what problem you are describing. A user who remembers his momentarily-forgotten password can of course change or reset it regardless. The article quite sensibly describes using the old password hash as a nonce without pestering the database with extraneous records.

Kenji 12y ago
It would be nice to stop all reset tokens if the user has logged in after the reset tokens were made. But you're right, it's not really a problem unless one chooses make it one ;)
- sk5t 12y ago
  One could overcome this by tracking the user's last password-driven login date and rolling it into the MAC; alternately, just use a short expiration time on the reset token and don't sweat it.
  - morgante 12y ago
    But that's just introducing additional state (last login date), so if you're starting to do that there's not much point in the HMAC approach.
    - yeukhon 12y ago
      I think it all comes down to what benefit your user's security. If you want to expose to user his or her account's activity, like history of recent password reset, recent login activity, things that a typical FB user would see in the user's activity page, that can be a really nice security feature. So maybe after all the HMAC approach works just fine with extra state added. But I think the point the author is bringing is that the application can simply just do HMAC(.....) easily and verify in a few lines of just if and else branch, whereas the traditional password reset code would probably take more lines and more conditions. I had written code that did exactly what the author didn't like and trust me that code wasn't pretty and I had spent many hours to optimize the code. Edge cases and test cases shitted my codebase.