I recently found out that the company I use for shared hosting stores passwords for email accounts in plaintext (they mentioned this to me incidentally, while troubleshooting another issue). They're a major company that does business and e-commerce hosting, so I'm shocked. But I'm just a hobbyist, so I'm not completely sure there aren't exceptions to the rule that you should never store plaintext passwords.

Is there any possible justification for this? Are email account passwords somehow different, such that I shouldn't be concerned that they were able to look it up?

update - in case anyone was curious, I inquired further and found out that the passwords weren't in plaintext, but they were reversibly encrypted. Still not ideal but considerably less bad.

  • 1
    Any service that returns passwords in plain text is a huge nono. It's sad, because many big and major companies still do this, only from laziness and incompetence. A good way to identify [and hopefully means you promptly remove yourself from their service] is request "lost my password". If they return a password reset, then it indicates they hash/salt. If what's returned is plain text, then.. well, self-explanatory. – theGreenCabbage Mar 3 '14 at 21:37
  • 2
    @theGreenCabbage Usage of Recovery vs. Reset processes is not a good indicator to differentiate between good password storage practices and bad ones. While a Recovery process definitely indicates bad storage practices (though it does not specifically indicate cleartext storage - encryption, not as bad as cleartext but still a bad practice, may still be used), a Reset process can just as well be in place with cleartext storage as it may with hashed/salted storage. ... – Iszi Mar 3 '14 at 21:58
  • 1
    ... Even if this could tell us whether hashing/salts are used, it still wouldn't help differentiate between bad practices (weak/fast algorithms, common salts) and good ones (strong/slow algorithms, unique-per-account salts). – Iszi Mar 3 '14 at 21:58
  • 1
    There are some authentication protocols (like CHAP) that require the plaintext password. The hosting service may be supporting an authentication protocol that requires access to the plaintext password. Even though they said that it's plaintext, it could still be encrypted but with the ability to decrypt back to plaintext. Still not great from a security standpoint, but not as bad as plaintext and sometimes is a necessary evil. – Johnny Mar 3 '14 at 22:33
  • 2
    @Johnny consider adding this as an answer. It's a great point and while it may not balance out what everyone else is saying, it does give a reason why the practice isn't totally incomprehensible. – octern Mar 3 '14 at 23:58

Passwords, should NEVER be stored plain text, regardless what they are used for. People tend to reuse their passwords, meaning a person's email password could be the same for his facebook account or other more critical application. Therefore performing correct password hashing is imperative.

  • 11
    Nevermind the fact that the e-mail account is typically a gateway to password resets for every other account. – Iszi Mar 3 '14 at 21:50
  • 1
    Hashing on its own is still subject to rainbow table attacks. Better to use a salt when hashing. Even better to use something like PBKDF2 – Matt Connolly Mar 4 '14 at 1:06
  • 2
    @MattConnolly I believe Lucas meant to imply the use of salt when he said "performing correct password hashing". He probably just felt that the question is a bit too pedestrian to bother with providing any answer more complete than what he did - any security-minded individual with a lick of sense regarding the Internet should easily recognize that e-mail accounts are among the most high-value online accounts one might have (arguably more so than financial accounts) and therefore should be the last account for which cleartext password storage might be deemed acceptable or "less bad". – Iszi Mar 4 '14 at 4:11

Storing any sort of "password" data in the clear is, quite categorically, inexcusable. Storing passwords for e-mail accounts in the clear is no less so - in fact, I'd say it's much worse for e-mail accounts than any other type.

As @LucasKauffman mentioned, users very often re-use passwords across multiple systems. So, any sort of leak that includes passwords and user IDs doesn't just affect the system from which that information is leaked - it also very likely will impact several other systems where the victims have chosen to reuse their user ID and password.

The same leak in an e-mail system further compounds this risk in two significant ways:

  1. E-mail addresses are commonly used as, or can be used in place of, user IDs in other systems.
  2. E-mail accounts are nearly always used as a component in password reset processes and/or user ID recovery processes.

In this way, even the most security-conscious users could be quite fully compromised if their e-mail provider is not securely storing their credentials. Having strong and unique passwords on all accounts doesn't help if your gateway to resetting those passwords is compromised.


Not much to add here, but for the sake of gathering more opinions: I can't imagine any reason why a password should be stored in plain text, except of course from the perspective of the company as I suppose it is marginally less effort not to secure than to secure.

Keep in mind that this also means that database admins working for the company can view all passwords in plain text: so not only does this pose a risk to their customers, it is also an internal risk for the company (i.e. in case of abuse by one of the admins).


Classic challenge response authentication schemes like CHAP are one reason to store your password in a recoverable form (i.e. not hashed). This does not mean that it has to be stored in the clear, but at least it somehow must be convertible to it clear text form. At least the autheticating system must have knowledge of your password in this case, you cannot perform them if you know only the passwords hash. Some systems claim they do it, but when you take a closer look at it, in this schemes knowing the passwords hash is as good as knowing the password itself. Public key authentication schemes are even better, but not very widespread. So storing them unencrypted is a bad idea, but storing them recoverable might be necessary.


the answers I see so far proclaim (correctly) that it's very bad, and that they should be hashed but don't explain the logic so much I think on why.

Yes - people reuse passwords, that's partly why storing them in the clear is bad.

Depending on the mail server involved / protocols involved, passwords in transit may have to be in clear text (see the most basic POP setup), but even if there's some reason passwords need to be in cleartext in transit (and there shouldn't be), passwords in transit having to be clear text does not stop you from only storing hashes of passwords at rest, and matching them when people try to log in; saving people's accounts from having actual passwords stolen.

If you're using off-the-shelf software that only lets you use cleartext passwords you should campaign for them to fix it, or consider one of the free alternatives that don't have that problem.

If it's the company's own software, yes, they should fix it, it really shouldn't be that hard, and storing cleartext passwords really is that bad.

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