10

If a website emails a password in cleartext when you use the "forgot password" function, is there any possibility that the password is hashed? It does generate a different password if you reset it again, but it always gets emailed in cleartext.

Is it possible to reset a user's password, proceed to email it in cleartext and then hash it? If yes, is this considered to be within good security practice?

The website does NOT require you to set a new password after you login with the newly created password.

17

"If a website emails a password in cleartext when you use the "forgot password" function, is there any possibility that the password is hashed?"

Yes, of course. The site might (it actually ought to) store the password in hashed form, and send it to you when it is generated in plain text, then erase it from its memory. The latter is good security practice; sending the actual password in clear text... not so much.

Is it possible to reset a users password, proceed to email it in cleartext and then hash it? If yes, is this considered to be within good security practice?

Yes, indeed this is the beginning of a good security practice. But now we have a security token that has been sent to who knows how many systems, that might subsist in uncountable cleartext backups, and even might remain available to anyone with your email password; crack the mailbox, and get access to all the sites.

So, we...

One more thing i forgot to add....The website does NOT require you to set a new password after you login with the newly created password.

...exactly. So the good security practice is to send a random token (or an URL, which is the same concept), valid only for a short time, not an actual password, in clear text; and use that to create a new password chosen by the user.

Not changing the password once it's been sent and received and confirmed is definitely a VERY BAD security practice, for it leaves a good password lying around.

If a new password is chosen by the user, it can be kept hashed on the site and only ever travel from the user's memory to their computer, and to the server through HTTPS - as secure a circuit as feasible.

some issues (not related to the question itself)

Token storage

Someone might be concerned about how to recognize that a token is valid. You needn't necessarily store the token anywhere; you can have the token be self descriptive. Of course, this requires it contains enough information that typing it in might be awkward.

Example generation:

date = toBase62(timestamp/60); // 32 bits of timestamp, divided by 60, are about 26 bits, and become five characters. You can use a timestamp starting 2021-01-01 to get smaller numbers that fit in even less bits.
hash = md5(concat(secret,':',date,':',user); // 32 hex digits

token = concat(user,':',date,':',substr(hash, 8))

The token might now be lserni:a7XzQ:baadf00d. Upon receipt, I can check whether the date lies within the last X hours (otherwise it's invalid), and before that I check that the MD5 of my secret plus date and user does end with 'baadf00d'. Bruteforcing that requires 2^32 attempts, so it's not exactly feasible.

Denial of service or harassment

If I know someone's account, I can trigger repeated password resets. They won't go through but the user will receive a lot of emails from the server, which inconveniences both. Also, if I want to prevent them from resetting their password, this works - because they'll receive hundreds of emails, and only one is the one they requested.

To discourage repeated sending, do not just put a rate limit on outgoing email, because that would allow someone to lock users out of the password reset process. Or if you do, then you must accept any valid token, not just the last one (if you don't do storage, this is an automatic benefit). And even then, you risk that someone who knows the user's password might:

  • send a password reset request, that the user will ignore
  • log in as the user and change the password manually
  • now the user can't reset the password for 24 hours!

In this case, the trick is to reset the "no-email" safety lockdown time every time someone logs in with the correct password. This could be a time flag associated with the user account. Also, after X email-less password changes, further password changes must be denied unless performed from an email link.

(All this assumes that the attacker can't change the email address associated to the account, otherwise they can just log in, change the email address, change the password and lock the legitimate owner out. Users could opt-in to a safety measure that will only allow to change the email by sending a secondary token to the current email, which exposes them to some hassle if they lose access to the email - which is why some services provide for a secondary "recovery" email).

1
  • Regarding your token storage section, a good way of doing that without reinventing the wheel is to use a JWT token. It does exactly what you describe, but without the risk of introducing some kind of security flaw with a custom implementation. – PLPeeters Jun 9 at 7:38
2

Absolutely. This is quite common for initial passwords. You set up a new account, the system generates a password, emails it to the user, but it is properly hashed and stored server-side. Microsoft 365 does this, for example. It usually means that the emailed password triggers a reset once you use it.

It might be better if the password is set by the user, but that's not always possible.

Allowing the emailed password to persist after use is not "best practice".

2
  • 1
    Password reset should not delete the original password first (nor change the password at all without further acknowledgement from the emailed token). Otherwise it becomes a denial-of-service attack where someone else can keep changing your password and you can never actually log in, even if they do not have access to your email. – Miral Jun 4 at 4:53
  • @Miral you are correct, I was not careful with my wording. – schroeder Jun 4 at 6:43
0

A good practice would be redirecting user to page, where one can set up new password. Link to password reset page can be emailed.

Sending password in plaintext is not secure. If it happens, then page should require to change it after initial login.

There are sites sending you your password in plaintext - it means it is not kept hashed in DB: https://plaintextoffenders.com/

1
  • 1
    This is incorrect...ish. Nothing is stopping the site from sending a new/reset password to you plaintext, then immediately hashing it and saving it on their DB. There's only a "plaintext offense" if you do a password reset and get a password you set. That said, the emails are still likely stored plaintext in their archives, which is why emailed passwords should force users to set them on first login. – Ave Jun 3 at 11:41
0

I would argue that the main insecurity comes from this:

The website does NOT require you to set a new password after you login with the newly created password.

In a best case scenario the flow would be like this:

  1. You request password reset
  2. A new password or URL with token is sent to your email
  3. The password or URL has a lifespan of 30 minutes
  4. Upon entering your new password or clicking the URL with token you are prompted to set a desired password

Notice how step #3 needs to have a lifespan? This is what combats a compromised email. An attacker can just as easily click on a URL with a token as they could type in a given password; it's all plaintext anyways!

Given that #4 does not seem to be implemented then I assume #3 is not either. I would consider their password reset system insecure.


Whether or not the password is stored as a hash on the server-side is a completely different discussion. At this time I would assume the answer is Yes.

If the email simply told you your old password in plaintext then that would indicate either plaintext password storage or a reversible encryption mechanism.

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.