1

I had this idea, that instead of generating a password reset token and emailing it to the user, I simply email the user's hashed password to them. Then upon reset, the user would submit the old hashed password and the new password in plain text. The server would compare the submitted hashed password and the stored hashed password, and if they match, reset.

This could have some benefits including no expiration time on the reset email and no need to store/expire reset tokens.

What sort of negative security implications would this have?

5

There's a couple of disadvantages with this scheme:

  1. As other responses have pointed out, this leaks the user's password hash. This is a problem not because the legitimate user gets it or because anyone with access to the email could own the account (this is true of reset tokens as well) but because it allows an attacker who can read the email to perform a dictionary attack on the hash. It's likely the user will set their new password to something very similar or have reused the same password on multiple sites. Leaking hashes is undesirable, even if properly salted & hashed. Consequently, if the email is ever compromised by an attacker, it has value to the attacker.
  2. Also, as pointed out, this makes it hard to regenerate the token or have it expire. Password reset tokens should not be good indefinitely in case someone gets access to an old copy of email (e.g., a backup) or has pulled it off the wire but does not use it in a timely fashion. Your "benefit" of no expiration of the token is actually a drawback from a security point of view. (And marginally useful from a usability point of view.)
  3. In the reset email, the token is often (always?) placed as a query string parameter. This means the token (and the users password hash) will be stored in their browser history, and likely in any webserver logs.
  • 1
    (and point 1. is especially important because it allows anyone with a registered account to gain info on your hashing) – Marcus Müller Aug 28 '17 at 18:46
  • I actually disagree: there's no need to keep the hashing function you're using a secret, unless you're embarrassed of it. If you use an industry-standard hash (scrypt, bcrypt, etc.) an attacker gains essentially nothing by knowing that. (Look at all the open source auth frameworks that leak their hashing algorithm.) – David Aug 28 '17 at 20:58
  • ah sorry, I was ambiguous: Not the hashing function as it, but the salt might be compromised, given sufficient hash(unknown salt+known-plaintext) (and that might be happening sooner than you might forget that you're using a hash function that was believed to be secure at the time you designed your application). Also, another aspect that I just realized: if the salt is static, all users with the same password would have the same reset token. So, if I just set my password to "password", then ask for a reset token, I can try to reset all user's passwords; some will use that bad password. – Marcus Müller Aug 28 '17 at 21:04
0

sigh don't invent new password/hash/token schemes.

Your scheme would have the disadvantage of allowing an attacker to get info about the salt you use to hash the passwords. It's basically an enabler for known-plaintext attacks.

That basically weakens the advantage of storing hashes instead of passwords.

Also, this would allow someone only able to read your emails to always figure out when you change your password.

Also, this means that the password reset token never expires. there's no mechanism to simply invalidate a token if it has been leaked. It also means that a malicious party can wait until you go on vacation to change your password, at a time where you can't notice (and won't notice, because since the token stays the same as long as you don't change your password, so no need for a new reset email).

Also, this has marginal advantage of only saving you one lifetime-limited entry per password reset request in a table. I fail to see the benefit of doing that.

Don't try to be smarter than the millions of people building state-of-the-art auth.

  • While I understand your "don't reinvent the wheel" message, most of your other points are equally "exploitable" on token-based systems. – Chris Smith Aug 27 '17 at 23:36
  • 1
    No. You don't give out the stored hash. – Marcus Müller Aug 28 '17 at 6:00
1

The purpose of using a password reset token is not just create an indirection or a shared secret for resetting passwords. You can build additional security features such as token expiration or limit use.

It is also insecure to send user's password hashes. Usually any unauthenticated user is allowed to do password reset on an account. By requesting password reset on an account an adversary would be able to do dictionary/rainbow-table attack on the obtained password hash. Essentially the security of the password and the system is weakened significantly.

Using the stored password hash for password reset may work functionally for password reset, since it is in fact a shared secret between server and user. It's not a durable solution.

  • An adversary would need to have access to the email account associated with the user that owns the account they're trying to reset. Dictionary attacking this would have little benefit. – Chris Smith Aug 28 '17 at 1:05
  • Email addresses are much easier to obtain. The entropy is much lower and easily obtained from different channels, such as social networks, GitHub and etc. – Kaiyi Li Aug 28 '17 at 1:09
  • The password "hash" is emailed to the user (like a normal password reset token would). Knowing somebody's email would not allow them to dictionary/rainbow-table attack it. – Chris Smith Aug 28 '17 at 1:11
1

Consider a situation in which an attacker obtains a copy of your hashed password database (sadly a very common occurrence). Such an attacker would then be able to used these hashed passwords to reset the password for all of your users.

Systems which use password reset tokens and store hashed tokens in their database such an attack would not be possible.

2

This is a really bad idea.

You are assuming that nobody except the user has access to their emails. In that case, why not just send them their plaintext password?

In reality, we should assume that others might have access to mails.

If we assume that, there are several issues with your approach. An attacker can crack the hash and gain the password. Now they can:

  • Log in without resetting the password. This means that the user will not be aware of the fact that their account was taken over.
  • Try the password - and variations of it - at other services (users reuse passwords).

This could have some benefits including no expiration time on the reset email

That's actually not a feature, it's a bug.

  • +1 "not a feature, it's a bug". There's nothing convenient about being able to reset a password two weeks after you noticed you need a new one. – Marcus Müller Aug 28 '17 at 18:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.