105

How secure is sending passwords through email to a user, since email isn't secured by HTTPS.

What is the best way to secure it? Should i use encryption?

20
  • 66
    No, no, no, no no! Never ever use plain text passwords in email. Infact never send passwords at all if at all possible.
    – ewanm89
    Aug 1, 2012 at 13:19
  • 9
    Worth reading this blog post by Troy Hunt on Tesco, the UK's leading supermarket, sending passwords via email. troyhunt.com/2012/07/lessons-in-website-security-anti.html Aug 1, 2012 at 14:05
  • 8
    No, never. We even shame those who do at plaintextoffenders.com. Aug 1, 2012 at 14:43
  • 4
    @SimonWhitaker Amusing that you posted that - I've been heavily involved in the campaign to get them to fix it! :)
    – Polynomial
    Aug 1, 2012 at 15:30
  • 12
    The fact that you can send users their password means you're storing user's password in plain text or at least a reversible cipher. That alone is a cause for red flag.
    – Lie Ryan
    Aug 1, 2012 at 15:52

5 Answers 5

159

You should never send passwords in the clear, nor should you store them in the clear. You should hash them using a slow one-way cryptographic hash such as bcrypt or PBKDF2. If a user forgets their password, you offer them a "reset password" function, which sends a one-time reset link to their account.

A scheme such as the following is reasonable:

  • Hash all passwords using a salt plus bcrypt / PBKDF2. See my reasoning here. (EDIT, March 2019: use Argon2)
  • Validate the hashes upon login.
  • If a user forgets their password, send them a secure one-time reset link, using a randomly generated reset token stored in the database. The token must be unique and secret, so hash the token in the database and compare it when the link is used.
  • Enforce that a token can only be used to reset the password of the user who requested it.
  • Once the token is used, it must be deleted from the database and must not be allowed to be used again.
  • Have all password-equivilent tokens, including reset tokens, expire after a short time, e.g. 48 hours. This prevents an attacker exploiting unused tokens at a later date.
  • Immediately display a form to allow the user to set a new password. Do not use temporary random generated passwords!
  • Do all of this over SSL.

I highly suggest reading through The Definitive Guide to Forms-Based Website Authentication for a full set of guidelines on how to build secure login systems.

23
  • 31
    +1 The root problem has nothing to do with email. The root problem is that passwords are being stored in plaintext or with reversible encryption. Solve that problem and the email question answers itself.
    – Phil
    Aug 1, 2012 at 14:06
  • 2
    @drjimbob well in effect that just became no different from a reset link, without the autologin and select account part.
    – ewanm89
    Aug 1, 2012 at 18:05
  • 2
    @Wug You can't revoke a temporary password as easily, after a set time-frame. It also confuses users, since they'll get a failed login despite the email saying the new password is valid. Furthermore, a reset link forces the user to immediately change their password, which reduces the risk of the temp password being stolen later. I also don't understand your HTTPS argument - why would a link like https://example.com/reset?token=123... cause the token to be sent in the clear when logging in?
    – Polynomial
    Aug 1, 2012 at 19:49
  • 3
    @Wug Erm, I think you've misunderstood HTTPS. The entire HTTP conversation, including GET parameters, are all encapsulated inside the SSL stream. Go grab a copy of Wireshark and verify it for yourself.
    – Polynomial
    Aug 1, 2012 at 19:53
  • 2
    The entire request URL is encrypted in HTTPS; this is why secured domains must be hosted on dedicated IP addresses, as certificate selection can't be based upon the request address since that information isn't available to the server until after the session has been negotiated. Even so, if the token is one-time-use-only, what would even be the harm in its being sent in plaintext? By the time anyone could have observed it, it won't work anymore. Aug 1, 2012 at 20:03
43

Email is not secure. Sending a password over email is thus a security risk. To mitigate the risk, you can (in some situations) make it so that the password sent by email is a one-time password, which only unlocks the possibility for the user to select a new password of his own.

This is what good I-forgot-my-password-for-this-Web-site systems do: the user clicks on the button "dammit, I forgot my password", and an email is sent, which contains a URL (with HTTPS) which embeds a random session identifier, and points to a page which lets the user choose a new password. The URL is the "one-time password". With this scheme, you can at least, from the server side, know when the URL was used.

If you can do encryption properly, i.e. if you can send an OpenPGP or S/MIME message encrypted with the user's public key, then the user has a private/public key pair: in that case, why would you use passwords at all ?

2
  • 9
    So what's stopping the link in the email from being hijacked by a middle-man who uses the link to reset the user's password?
    – Pacerier
    Dec 12, 2014 at 8:28
  • @Pacerier 2FA (either SMS or, much much better, TOTP) after the recovery token is presented.
    – Pointy
    Aug 14, 2022 at 17:55
23

It is bad practice to send passwords to the user, as that would mean that you have a cleartext copy of the users password.

I can think of no good reason to do this. There are other more secure ways of accomplishing what is needed.

For a general answer with regards to email security, I suggest you read this link, which has some good information in it.

If you HAVE to send sensitive information over email, use a scheme like PGP or other encryption techniques to secure the data.

3
  • This is not true; you can create an e-mail to send to the user after the submit to create the password. At a certain point in time, you will always have the password in clear text. While I agree it's not smart to e-mail passwords after creating an account, it doesn't mean the password storage is lacking. You could store the password with PBKDF2 SHA-512 with 10k itterations, this doesn't mean you can't send the password the user picked via e-mail.
    – NKCSS
    Aug 1, 2012 at 14:12
  • 5
    @NKCSS: one day someone will register an account to your website, using their shared work mail, with their personal password.
    – Lie Ryan
    Aug 1, 2012 at 16:00
  • 1
    @NKCSS True, you could send the password immediately before storing it, and your storage solution could be secure. But sending the password in the clear is still ridiculously insecure. Never minding the possibility Lie Ryan has suggested, you should also be concerned about who could be listening in on the e-mail conversation. The user may be using a service that transfers e-mails in the clear between servers or to the client. See my answer on this topic for more reasons not to trust e-mail for confidentiality.
    – Iszi
    Aug 2, 2012 at 0:07
4

If you have the 'clear password' to send in the first place (aside from the registration process), you're doing it wrong. Never, ever store the plaintext password! Lots of companies like Sony Music and the like have been being burned lately from that.. and let me tell you the consumers are not happy.

1
  • 1
    To be clear (pun not intended), you should never send the cleartext password - not even during registration. Yes, by nature of the process, you will probably have a cleartext (or encrypted) copy of the password during registration but it should be immediately salted, hashed, and stored in the secure database - never sent or displayed to the user.
    – Iszi
    Aug 2, 2012 at 0:00
3

Echoing the previous posts, email is certainly not safe and you should never email any sensitive data, in particular passwords. Especially since they are not encrypted and our found in clear text, it is extremely easy for anyone to hack into your email and gain access to these across the public network.

If you or your client have trouble remembering your passwords, you should use a secure password manager. This is a website that houses a list of your passwords in a completely encrypted vault. Good ones are KeePass or LastPass.

If you are a company that is trying to send clients their password again, you should have security questions set up that the customers answer when they initially create their account. This way if they forget it, they can click on a link that sends them to answer these questions correctly and reset their password.

For your own knowledge, this is an informative blog, which makes the case for encryption and warns against using certain passwords http://www.ziptr.com/blog-last-4-digits-ssn-password from Ziptr.

1
  • FYI: KeePass is not a "website". It's an application. And, by default, it does not synch to the cloud. I believe there are plugins available to synch it with DropBox or other cloud storage services, though.
    – Iszi
    Aug 1, 2012 at 23:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .