One of my hosting providers is sending a new password in plain text per e-mail, on request.

  1. How insecure is this practice?

  2. What would be a good (more secure) alternative to this?


8 Answers 8


It's probably fine, as long as the user is prompted to login and change it immediately (and assuming it expires within hours if the user does nothing, forcing another reset cycle). A similar question is "Temporary passwords e-mailed out as plain text".

You're probably thinking of the much worse scenario whereby a system stores your passwords in plaintext, and then emails you your password if you forget it. There are a few questions dealing with why that is a bad process (and what you can do about it).


It's an interesting one, because you face two problems. You need to let someone know the password but:

  • If it's plaintext, it's easy to read for anyone with illicit access to the email
  • If it's encrypted, it needs extra software than many users will have as standard, plus the optimal is to store a password as a one way hash, rather than an encrypted string.

Myself, I would plump for transmitting by plain text, but forcing a password change on first use, and if the situation needed it, I'd contact the client by another means to tell them the password would be with them shortly - cajole them into setting their own immediately.

One option would be one-time access to a 'Set Password' interface of some sort - that's not a bad idea in some ways, because no one will ever see the password, and it need never be stored as anything but a hash.

Like everything, it all depends on what's behind the locked door.

  • Also bear in mind that clients need to behave in a secure way, otherwise your efforts are always going to be potentially pointless. Educating the users is as useful as implementing a good system.
    – Owen
    Oct 16, 2013 at 16:49

Passwords and password reset links sent in the clear is not optimal. As you become susceptible to any traffic snooping, rogue ISPs and any people with access to your mail server.

What you are seeing here is the classic problem of public key encryption not being widely used.

If citizens had a government-signed* public key, the provider could simply send the email encrypted with the citizen's public key - confident that only the real customer** could read the message.

As we don't have that yet, what the hosting provider could do is:

Require that all support enquiries for password resets go through a HTTPS encrypted chat service.

This way - whatever proof the customer gave of their identity is protected from snooping and the temporary password (or better yet, a single-use https://reset-password link) is only provided through the HTTPS chat session. The customer being instructed not to save the link and click the reset link before it expires.

* Or better yet each citizen's public key is signed by multiple mutually-antagonistic governments to reduce collusion and government misuse.
** And government spies of course if no government or only cooperating governments signed it.

  • 2
    But password reset links are clearly better than plain text passwords, so they are a better alternative. Oct 16, 2013 at 2:27
  • If you had to send it in clear, then yes - a reset link is superior because the process can be decoupled from the slower more tedious login screen and allow for much longer "temp" passwords in the form of one-shot PRNG query strings. Oct 16, 2013 at 2:40
  • 1
    What I meant is, a password reset can only change the password, but not retrieve the existing one. Therefore, an attacker can hijack an user's account but the user will notice the next time they try to log in. With a plain text password, the attacker can just write it down, and then secretly log in into the user's account in the future (and e.g. spy on the user). So, unlike the password reset, here the user isn't notified when an attack happens. Oct 16, 2013 at 4:34
  • Yes I agree, a password reset forces further access and reset into a single Mortal Kombat move. The user may be allowed to linger about and access services with the temp/new password for a while without mandatory reset (depends on the site behaviour). Oct 16, 2013 at 4:41

On #2 - One of my employers' IT department did not allow any passwords to be sent by email at all. Even the new accounts' passwords were communicated in person or by (landline) phone, not alternative email addresses.

No password, encrypted or not, was transmitted over the network. One must be an organized criminal to somehow intercept the phone line at the right time to get the password.

  • This is usually sufficient, if tedious for the users to temporarily write down a password they might not throw out the note for. And a PSTN is mostly unencrypted and has its own spies (telecom operators, governments, etc) for the truly paranoid. Oct 16, 2013 at 4:37
  • I wouldn't be worried about real humans being the middleman. Robots on the other hand... You can't rely on peoples choice of operating systems.
    – ram4nd
    Mar 2, 2015 at 14:39

The LastPass password manager can send passwords safely to other LP users. They support 2 share modes, one to share all of the info including the password string. And one mode that shares only the capability to log onto sites. The password however, is not shared visibly, unless perhaps if the site has a show password option.

  1. It varies: what do you have that will get hacked. Public info? Secure info? HIPPA?

  2. Over the phone, or a reset password link and token.

Also, at work I have found that because of the strict password configurations--set by the powers that be-- users just keep the gobbly-gook password in a PostIt on the edge of their computer screen since they have no way of memorising it.

  • Your first point is about the consequences of a breach, not about how insecure the practice itself is. Jul 27, 2016 at 18:16
  • S.L. Barth you are correct
    – JustJohn
    Jul 27, 2016 at 18:18
  • 1. Well, it’s my hosting provider. So, the attacker would get access to the admin panel of my website. Jul 28, 2016 at 3:44

sending passwords in an email is pretty poor practice. generally speaking email is insecure, even if email is encrypted in transit you typically have system admins who have access to email especially in corporate settings so now the system admin can access the account.

if your email data is not encrypted in transit MITM sniffing can access the contents.

I would not use a system where passwords are sent in plaintext in an email as this would lead me to question other security elements at the offending organisation.


I like the idea that it all depends on what is behind the door. Most small to medium Enterprises have email systems that don't span multiple mxhosts and so internal delivery is very much local host only, so that and the use of imap or pop over tls should mitigate most mitm issues. On the hand you could diceware the password and send it in an envelope, which then depends on the envelope budget. Most organisations probably aren't paranoid enough to do the envelope thing. The other method would be to get all users to generate their own keys and you retrieve their keys from a hkp server and you sign and encrypt the password in that.

You must log in to answer this question.

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