Password reset by email without a database table

Question

The normal flow for resetting a user's password by mail is this:

1. Generate a random string and store it in a database table
2. Email string to user
3. User clicks on link containing string
4. String is validated against database; if it matches, user's pw is reset

However, maintaining a table and expiring old strings etc seems like a bit of an unnecessary hassle. Are there any obvious flaws in this alternative approach?

1. Generate a MD5 hash of the user's existing password
2. Email hash string to user
3. User clicks on link containing string
4. String is validated by hashing existing pw again; if it matches, user's pw is reset

Note that the user's password is already stored in a hashed and salted form, and I'm just hashing it once more to get a unique but repeatable string.

And yes, there is one obvious "flaw": the reset link thus generated will not expire until the user changes their password (clicks the link). I don't really see why this would be a problem though -- if the mailbox is compromised, the user is screwed anyway.

Answer 1

To remedy the obvious flaw, add the current date (and more time-related info representing current fraction of a day if even a day is too long) to what you're hashing to generate the mystery string and check it -- this makes the string "expire" (you may check the previous as well as current date or fraction if you want longer "expiry"). So it seems to me that your scheme is quite viable.

Answer 2

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

Answer 3

Actually after thinking about this again, your method is potentially less secure than "The normal flow".

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

Scenario 1:

1. Jim registers on your site as [email protected].
2. Jim requests a password reset, but doesn't use it. The reset email is left sitting in his inbox for eternity.
3. Jim changes his email address on your site.
4. [email protected] is compromised by Bob.
5. Bob now runs a bruteforce attack via his distributed GPGPU farm and recovers Jim's password.

Scenario 2:

1. Jim uses a the password jimjonesupinthisma! for his banking account.
2. Jim registers on your site as [email protected]. [email protected] is not in any way associated with Jims bank account.
3. [email protected] is compromised by Bob.
4. Bob now requests a reset, he now has HASH(HASH(jim's password)).
5. Bob now runs a bruteforce attack via his distributed GPGPU farm and recovers Jim's password, which he then uses to access Jims bank account.

Scenario 3:

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

1. Jim registers on your site as [email protected].
2. Bob requests a password reset on Jims account.
3. Bob works for NSA at Room 641A.
4. Bob uses his global internet sniffer and obtains HASH(HASH(jim's password)) as it's emailed in plaintext to [email protected].
5. Bob now runs a bruteforce attack via his distributed GPGPU farm and recovers Jim's password.

Variants of scenarios 1 and 2 happen all the time (depending on how strong the hash and password are), I'm not so sure about 3. The point is, your method leeks unnecessary information, which can indeed leverage an attacker against your user.

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