Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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

closed as off topic by Tom Squires, MichaelT, Glenn Nelson, ChrisF Feb 22 '13 at 15:15

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

No, never send out passwords via email. Why would your application even know the password in the first place? If you are storing plain text passwords in your database, please stop. More details here: stackoverflow.com/q/1054022/99456 –  Yannis Feb 22 '13 at 6:12
Please take the advice posted by everyone here to heart; if the application is currently storing passwords in the DB in plain text, it's a massive security risk. (Some of) your users probably have the same passwords for their email accounts, online banking, etc. You can still retrofit your application to use hashes (preferably bcrypt, etc), but your DB backups will probably have tons of sensitive information in it for quite some time. Anecdotally, if any site emails me my password, I immediately "burn" that password and stop using that site; it's one of the worst security mistakes. –  Daniel B Feb 22 '13 at 6:54
Having a password emailed to you can happen when a password was generated/reset. It's not an indication that the password is being stored in a plain-text or reversible format. Now, if you can actually "recover" a forgotten password and email it, that's terribly insecure. –  Andrew Vit Feb 22 '13 at 9:00
Cross site dup to Security.SE: Is sending password to user email secure? –  MichaelT Feb 22 '13 at 14:44

3 Answers 3

up vote 6 down vote accepted

The main problem with sending passwords by email is not necessarily the security of the transport layer, but the long-term storage. Once that password is emailed, it will sit in the user's mailbox and they only need to leave their years-old archive of GMail unattended a moment for someone to search "password" and copy them all into a pastebin.

A better solution is to send a short-lived access token for the user to reset their own password, then they remain in control of where their password is stored, whether in an offline hard-copy format or their encrypted password manager tool of choice.

share|improve this answer
+1 for the first paragraph, however I do feel that you're underplaying (or under-emphasising) the risks of storing the password in plain text (or reversible format) anywhere. Even if it's just a little system, on a little server, it's not OK. –  Daniel B Feb 22 '13 at 7:14

What alternatives do you have to giving people a replacement password (I assume you're not storing their current passwords in any form that can be decrypted, instead using best practices and storing a hash).
The alternatives are few, cumbersome, and very expensive:

  • send the password by registered mail, on paper, to an address that's given in the account details. Never send the account name in the same letter, or on the same day. To send both, you'd thus need at least 2 letters, sent several days apart, each costing potentially upwards of several Euros (depending on whether it's sent international, insured, courier service, etc.). So at minimum the recipient won't have access to his/her account for up to a week after requesting a new password.
  • let the account holder phone you to request and receive a new password. You get a phone call, do voice analysis of the person on the phone to later verify you are giving the response to the same person. They hang up, you call them back on a registered line and after verifying it's indeed them you give them the new password. Cumbersome, expensive, and no more secure than an email.
  • fax? Still exists. Same vulnerabilities as mail and email both.
    So yes, just send them the password. But don't send the account name and password in the same message.
share|improve this answer
You can e-mail them a link that will take you through the processes of resetting the password (with the URL containing a short lived token that identifies the request). –  Loki Astari Feb 22 '13 at 19:40
which has the same vulnerabilities as sending the password itself: someone could intercept it and so gain control over your account. –  jwenting Feb 23 '13 at 2:08
It has the same vulnerabilities for this particular system (apart from it can be time-limited and you can ask other validation questions). But the important thing is it will prevent the release of a password in plain text. This is important as the password may be re-used on other systems and thus allows an attack vector outside of the current system. –  Loki Astari Feb 23 '13 at 17:10

Sending password in never been a good approach in case of forgot/reset password. In this case we are breaking two laws

  1. Never put the password with algorithm that can be decrypt. PCI Compliance is not fulfilled.
  2. in this case we can say that the system/application is not secure and there are more chance to use your password.
share|improve this answer
1) too local 2) no alternative given 3) bogus –  jwenting Feb 22 '13 at 14:56
There are many alternatives to consider. First store the password in un-decryptable format. Say in SQL Server use HASHBYTE('MD5') or other algos. Second . ON password change send a temporary token through email to reset the password and keep the expiry of this token for short duration say 1 hour or so. Depends upon the security of your business –  Sandeep Kumar Feb 24 '13 at 11:51
MD5? Seriously? –  Craig Apr 20 '14 at 22:53

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