Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
44  
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 '12 at 13:19
8  
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 –  Simon Whitaker Aug 1 '12 at 14:05
7  
No, never. We even shame those who do at plaintextoffenders.com. –  Omer van Kloeten Aug 1 '12 at 14:43
3  
@SimonWhitaker Amusing that you posted that - I've been heavily involved in the campaign to get them to fix it! :) –  Polynomial Aug 1 '12 at 15:30
8  
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 '12 at 15:52

5 Answers 5

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.
  • 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.

share|improve this answer
23  
+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 '12 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 '12 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 '12 at 19:49
2  
@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 '12 at 19:53
2  
@chiborg If an attacker breaches the database, he could use the reset tokens to gain access to any account he likes. Hashing the tokens prevents this, since he can't determine what the original token was. –  Polynomial Aug 2 '12 at 10:58

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 ?

share|improve this answer
6  
+1 for the last paragraph. –  Polynomial Aug 1 '12 at 11:35

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.

share|improve this answer
    
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 '12 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 '12 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 '12 at 0:07

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.

share|improve this answer
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 '12 at 0:00

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.

share|improve this answer
    
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 '12 at 23:57

protected by Lucas Kauffman Jan 2 at 10:57

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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