Password reset by email without a database table

Question

The usual thread to reset a user's password in the mail:

• Create a random row and save it in the database table
• Email string for user
• User clicks a link containing a string
• The string is checked against the database; if it matches, user pw reset

However, saving the table and expiring old rows, etc. seems a bit unnecessary. Are there any obvious flaws in this alternative approach?

• Generate MD5 Hash of Existing User Password
• Email string for user
• User clicks a link containing a string
• The string is checked by hashing the existing pw; if it matches, user pw reset

Please note that the user password has already been saved in a hashed and salty form, and I just want to delete it again to get a unique but repeatable string.

And yes, there is one obvious “flaw”: the reset link generated in this way will not expire until the user changes his password (clicks the link). I really don’t understand why this will be a problem, although if the mailbox is hacked, the user will still be screwed. And there is no risk of reuse, because after changing the user password, the reset link will no longer match.

Answer 1

To fix the obvious flaw , add the current date (and more detailed time information representing the current fraction of the day, even if the day is too long), to the fact that you haveh it to generate a string of secrets and check it - this does the string "expire" (you can check the previous as well as the current date or fraction if you want to expire longer). Therefore, it seems to me that your scheme is quite viable.

Answer 2

If someone accessed your database using password hashes, they would not know the real passwords. If you implement this system, they can generate reset links and reset the passwords themselves. With random strings and compromise knowledge, you can nullify all random strings, and only users in the password reset process will be compromised even without access knowledge. Not a likely scenario, but perhaps worth considering, given the nominal overhead of random strings.

Answer 3

Actually, thinking about this, your method is potentially less secure than Normal Stream.

If you just send back HASH(HASH(user original password)) , I can see scenarios where this could give an attacker leverage:

Scenario 1:

• Jim registered on your site as [e-mail] .
• Jim asks for the reset password, but does not use it. reset email stays in his inbox for ages.
• Jim changes his email address on your site.
• [e-mail] compromised by Bob .
• Bob now launches brute force attack through his distributed GPGPU farm and recovers Jim password.

Scenario 2:

• Jim uses the password jimjonesupinthisma! for your bank account.
• Jim registered on your site as [e-mail] . [e-mail] in no way associated with Jim bank account.
• [e-mail] compromised by Bob .
• Bob now asks for reset, now it has HASH(HASH(jim password)) .
• Bob now launches brute-force attack through his distributed GPGPU farm and recovers the Jim password, which he then uses to access Jim bank account.

Scenario 3:

(Your site uses TLS, users register through TLS.)

• Jim registered on your site as [e-mail] .
• Bob asks for the reset password in the Jim account.
• Bob works for the NSA on Room 641A .
• Bob uses his global internet sniffer and receives HASH(HASH(jim password)) , as he is sent via email in text to [e-mail] .
• Bob now launches brute force attack through his distributed GPGPU farm and recovers Jim password.

Variants of scenarios 1 and 2 occur all the time (depending on how strong the hash and password are), I am not sure about 3. The fact is that your method uses unnecessary information that can really use an attacker against your user.

I suggest you use randomly generated tokens that have nothing to do with the user's password.

Answer 4

say, in a very rare case, two of your users had the same hashed password even after concatenating a random salt with it; would the problem be right? I think this will not hurt if you add the email address or Hashid user_id to the reset password link.

Answer 5

This problem just passed and there is an idea:

1) Run a JWT (Json Web Token) with user account information. The token has an expiration of, say, 1 hour.

2) Send the token to the user via email / link

3) The user clicks on the link, the token is sent to the endpoint of the server, the token is checked. If this is true, you unpack the token and renew the user account

Any flaws in this approach? No database is affected (except for new user passwords, if necessary)