25

I originally posted this as a reply here in this thread but didn't get much feedback on it, and now I'm curious as to what others think is the best approach, or if there is any difference between the two approaches.

The original point was whether it was more secure to send out a password reset link when a user forgets their password to a website, or whether to send the original password unencrypted in an email.

Now not salting and encrypting a password is bad because when the database is eventually stolen from the website the attacker will have all the passwords clear as day. OK fine, I get that.

But if we ignore the possibility of the database being stolen and only look at the user forgetting their password and going through the "forgotten password steps"; is it more, the same or less secure to send a reset link over a plain text password in an email?

My thinking is that it is the same. Because if an attacker has access to your email by any means (he knows your email login details, or he's snooping the traffic somewhere) he therefore has access to the plain text password that's sent or the reset link - even if it is a limited time link.

The attacker could reset your password before you even know you have an email.

Is my thinking here flawed?

Community
  • 1
  • 1
    Thanks for asking. This is an open question with a client of mine. I still think that announcing to your users that you store their passwords in a recoverable form (plaintext or encrypted) opens up a liability for the company, because the user has proof that anyone from the company (at least) could have compromised their account with a valid login. – schroeder Mar 27 '12 at 20:20
  • 1
    I'd really like to know peoples opinion of sending a plain text, freshly generated, one use password, instead of a reset link. A large ish organization just lost my details and I had to use the recovery function that worked like that, they sent me an email with a password (6K$NHw) that I could use to login, but then the only option was setting a new password. It reminded me of stack exchanges " Here's your password: wizard` Just kidding!" – daniel Apr 03 '12 at 07:43
  • 3
    In addition to the "stolen database" scenario, anyone with access to the database can see those passwords. This might be just you, any admin, any developer, or even any employee. As many users use the same password everywhere, there might be very tempting scenarios and someone might get weak and use one of the passwords. You really do not want to be responsible for that happening. – Flo Aug 22 '13 at 05:37
  • 3
    The application should not know the password!!! – Shurmajee Oct 13 '13 at 08:47

7 Answers7

42

It's far simpler to get access to the existing corpus of email than to get access to the incoming stream. For example, getting a couple of minutes of access to someone's system allows easy searching through their email. So, for the case where an attacker has access to old mail, but not to the stream of new, incoming, mail:

You are relying on the user either changing their password after they receive it (unlikely, given that you've told them what it is), or deleting (permanently, not archiving or moving to a 'trash' folder, also unlikely) the reminder message.

If this doesn't happen, then if I get access to the user's email account some time later, then a (limited time/limited use, perhaps even limited such that the attacker cannot easily use it) reset link is not going to be any use to me, but having the (most likely still valid) password certainly is.

In addition, by sending me the plain-text password, you are demonstrating that you have this stored somewhere accessible. In most cases, there is no need for this, because you don't need to encrypt the password (and salt/pepper), you only need to hash it. If it's encrypted, then anyone with access to the database and the decryption key (e.g. probably most of the staff, or anyone that steals the code along with the database) is able to get the plain-text password. If it's hashed, then you'd have to get it before the hashing takes place (e.g. during a login session).

Furthermore, although people shouldn't, it's very common to use the same password (or very similar passwords) on multiple sites. That means that rather than providing a way to get into only one account, you're providing a way to get into many.

For the other case, where the attacker has access to all incoming mail (potentially even the ability to remove incoming mail before the user sees it), neither of these are secure. The email account is high-risk, because if you have that sort of access, then you can likely go to every site that the user has an account with, and generate a password reset. To avoid this, you need to use something other than (or as well as) your email account to get access, such as two-factor authentication.

Note that even in the latter case, a reset link is still superior: if the attacker changes the user's password via a reset link, then when the user tries to log in, they'll find out that something is wrong (too late, but at least they know). If you're just providing the password, then the user has no idea that the attacker has silently gained access.

Tony Meyer
  • 917
  • 7
  • 10
  • 7
    Just to clarify what i think is one of the more important points in this answer, though not quite fully articulated: password change links that become inactive after use can otherwise indicate to a legitimate user that an attacker has access to your account. Having just the password sent will not yield this information. – logicalscope Mar 23 '12 at 23:22
  • 1
    That's a well thought answer. One should really only store the hash of the password, otherwise an attacker needs only 1 key to get all the passwords. One cannot ignore the possibility of the database being stolen, with SQL-injection an attacker can make queries even when he doesn't has access to the database itself. – martinstoeckli Mar 24 '12 at 09:08
22

Ok, ignoring the fact that the passwords are stored in plain text, and diving straight into the question: . The password is a credential which has long validity, while a password reset link can be scoped in different ways:

  1. Only valid for a short amount of time
  2. Only valid from a certain ip
    • Preferrably the same IP the password-request was sent from.
  3. Only valid within the user session
    • When the user enters detail in the web form to request a new password, the user is issued a cookie (starting a session). The validation of the password reset-url depends on something in this session, therefore the validation-function will fail if the request is made without the cookie.

It should also be noted that an old password, that may no longer be valid at your site, may still be highly sensitive for the customer, since people reuse passwords across all kinds of services.

From that aspect, putting passwords in peoples email boxes could be considered kind of rude.

mhswende
  • 856
  • 1
  • 7
  • 9
9

Worth adding that if you do send a user's password in plain, you may be sending a password which they also use on other sites - even if you force the user to change the password on your site at next login, you have done them no favours at all.

Tom Newton
  • 276
  • 1
  • 5
9

It is unethical to be storing passwords in plaintext if you have the least bit concern for your users. You should be storing secure salted hashes. Sending a plaintext password may cause security-conscious users to stop using your service (even though security conscious users do not re-use passwords; they just don't like to support services that are that blatantly non-security conscious).

As to how to implement a password-reset; generally for a moderately secure site (say credit card), you require they answer some basic security questions (e.g., mother's maiden name) and verify that they have control of their email account or phone number, as a form of two-factor authentication. The link should be valid only in a short time window (hours to days) and only valid once (e.g., includes a randomly created token that expires after first use and after a time period).

You also notify them that the password has been reset (and even if their email was compromised; they will find evidence of an attacker when they can no longer log in with their old password). Sending the password (without changing it) means this attack can be done stealthily without the user ever knowing (if say the emails were deleted).

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
3

It's better to send a reset password link.

Some sites have the forgotten password form immediately reset the password to a random value, and that is emailed to the user. This has a denial-of-service flaw - someone who is not the account owner can cause their password to be reset. The reset password link avoids this, because the password is only reset once a user click the link - and they must have access to the email address to do this.

If you want a bit of security against an attacker who has access to the user's email, the usual approach is to have security questions as well. These are questions like "What was your pet's first name". And the time to ask these is after the user has clicked the reset password link in the email.

Some good advice here: https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

paj28
  • 32,736
  • 8
  • 92
  • 130
2

It is better to send a reset link.

In addition to the reasons given by @Tony Meyer and @mhswende, the page at the reset link can require additional authentication. Many sites require users to answer "security questions" for exactly this purpose (the old pre-computer standard is asking for your mother's maiden name). Sites which have your phone number may, on their password reset page, require you to enter a code they sent by SMS. Financial institutions may ask questions about old financial records (past morgtages, etc).

It's not trivial to come up with a good secondary authentication mechanism, but any password reset (or recovery) procedure that doesn't is vulnerable enough that I'd call it negligent.

ShadSterling
  • 190
  • 6
-1

Email of forgotten passwords means you are storing the password in your database either in plain form or 2-way encryption. That is not a suggested security practice.

You should store 1-way cryptic (which can't be decrypted) form of password at web-app end. So, even if your web-app or web-server face any db level in-securities, no user passwords are leaked in plaintext.

So considering this policy, the reset link is the suited and left option from two approaches.

AbhishekKr
  • 563
  • 3
  • 4