We received an email last year from our hosting provider regarding one of our accounts- it had been compromised and used to deliver a rather generous helping of spam.

Apparently, the user had reset her password to a variation of her name (last name is something you could probably guess first time.) She promptly got hacked within a week- her account sent out a deluge of 270,000 spam emails- and was very quickly blocked.

So far, nothing particularly unusual. That happens. You change your passwords to something more secure, educate the user and move on.

However, something concerned me even more than the fact one of our accounts had been compromised.

Our hosting provider, in an effort to be helpful, actually quoted the password to us in the following email:

enter image description here

I am astonished. We are due to renew our contract soon- and this feels like a dealbreaker.

How common is it for a hosting provider to be able to find out the actual password used on an account?

Do most hosting providers have an account abuse department that has more access than front-line reps (and can look up passwords if necessary), or are these guys just not following best-practice in making it possible for any of their staff to access user passwords? I thought passwords were supposed to be hashed and not retrievable? Does this mean they store everyone's passwords in plain text?

Is it even legal for a hosting provider to be able to discover account passwords in this fashion? It just seems so incredible to me.

Before we look into changing provider, I would like some reassurance that this is not common practice, and that our next hosting provider wouldn't also likely have things set up the same way.

Looking forward to hearing your views on this.

  • 4
    While obviously of great concern, for all you know this is a one-two punch of a phone rep recording the new password in a ticket (which they should never do) and another rep seeing it in the ticket notes. You are within your rights to demand answers, but as it stands you do not know how the password was retrieved.
    – Andrew B
    Commented Jul 19, 2013 at 1:25
  • 1
    I know for a fact that the user set the password through the web interface. They pulled it up from records on the server- no one in the office has spoken to them about it on the phone (besides, I believe this provider has email-only support anyway) Commented Jul 19, 2013 at 1:34
  • 3
    What would I do? Shrug. Anything you do on systems controlled by someone else is visible to them. If you don't want someone else to have this visibility into your email systems, run and host them yourselves. You might not approve of what they do with the information they by definition have, but if there are no contractual obligations on them not to do it, well, you signed the contracts.
    – MadHatter
    Commented Jul 19, 2013 at 9:18
  • 19
    The storing of a plaintext password is bad (like Time to find a new provider bad!) - lots of people do it but still: BAD. Sending you the password in an unencrypted email though? ALL OF MY NOPE. That shows a casual disregard for security. Run, don't walk, to a new provider with some common sense...
    – voretaq7
    Commented Jul 19, 2013 at 18:31
  • 2
    I'd like to expand on what @MadHatter said: Lots of people here are focusing on the idea of "storing plaintext passwords". The simple fact is that if I'm running a POP/IMAP server, an SSH server, or anything else into which you can type your password, it can be configured to log that password when you type it in, regardless of whether or not I am storing things hashed or in cleartext. Google can see your password and Dropbox can see your password and Facebook can see your password and so forth. You either trust your provider or host it yourself.
    – larsks
    Commented Aug 1, 2013 at 13:06

7 Answers 7


Yes, it is common for ISPs and email service providers to store your password in plain text, or a format which is easily recoverable to plain text.

The reason for this has to do with the authentication protocols used with PPP (dialup and DSL), RADIUS (dialup, 802.1x, etc.) and POP (email), among others.

The tradeoff here is that if the passwords are one-way hashed in the ISP's database, then the only authentication protocols that can be used are those that transmit the password over the wire in plain text. But if the ISP stores the actual password, then more secure authentication protocols can be used.

For instance PPP or RADIUS authentication might use CHAP, which secures the authentication data in transit, but requires a plain text password to be stored by the ISP. Similarly with the APOP extension to POP3.

Also, all of the various services which an ISP offers all use different protocols, and the only clean way to have them all authenticate to the same database is to keep the password in plain text.

This doesn't address the issues of who among the ISP's staff has access to the database, and how well it is secured, though. You still should ask hard questions about those.

As you've probably learned by now, though, it's almost unheard of for an ISP's database to be compromised, while it's all too common for individual users to be compromised. You have risk either way.

See also Am I wrong to believe that passwords should never be recoverable (one way hash)? on our sister site IT Security

  • 2
    APOP's pretty much a dead protocol, and MSCHAPv2 doesn't need the server to know the password in the clear - I don't really think there's a ton of reason for a service provider to be keeping clear passwords these days. Commented Jul 19, 2013 at 2:05
  • 1
    @ShaneMadden You're right; it's CHAP, rather than MSCHAP. And yes these protocols are damn near dead, but service providers who have been around forever may still be using them for legacy services. Commented Jul 19, 2013 at 2:12
  • Yeah - though I'd like to think that more of the legacy service providers have a crustly old LDAP full of {crypt} rather than cleartext passwords (the approach taken by the ones that I've had a behind-the-scenes look at in the past). Though that might just be wishful thinking. Commented Jul 19, 2013 at 2:33
  • 1
    Mandatory cryptography note, "The tradeoff here is that if the passwords are one-way hashed in the ISP's database, then the only authentication protocols that can be used are those that transmit the password over the wire in plain text. But if the ISP stores the actual password, then more secure authentication protocols can be used." is not generally true. It's only true because there are no existing protocols that allow a secure authentication scheme with hashed passwords.
    – orlp
    Commented Jul 19, 2013 at 13:42
  • 1
    @nightcracker compared to whatever amount of data you're going to transfer (encrypted as well, I hope) the small amount of authentication data shouldn't really bother you that much Commented Jul 19, 2013 at 14:40

This is, unfortunately, fairly common with budget hosts and not unheard-of even with bigger hosts. Things like cpanel frequently need your plain text password to be able to log in to various services as you, etc.

The only thing you can do is to ask upfront if the passwords are hashed.

  • 28
    It is a very low-budget host... I knew it was too good to be true. This is giraffing me crazy. Anyway, thanks for sticking your neck out with an answer. At first I thought it was a tall order, but you rose to the occasion. Answers like this help this site to reach new heights. I was thinking of marking this as best answer, but it's neck and neck. Commented Jul 19, 2013 at 2:02

They're likely either storing passwords in plain text or using some kind of reversible encryption.

As you've surmised, this is very bad.

Either due to employee maliciousness or negligence, or a compromise of their systems by an outside party, the plain text passwords being misused creates a serious risk - not only to their systems, but to other systems people might have used the same password on.

Responsible storage of passwords means the use of one-way hashing functions instead of reversible encryption, with a salt (random data) added to the user's input to prevent the use of rainbow tables.

If I were in your shoes, I'd ask the provider some hard questions about how, exactly, they store passwords, and how, exactly, their support rep was able to retrieve the password. This might not mean they store the passwords in plain text, but maybe they're logging them somewhere when changed - also a huge risk.

  • 1
    I will ask them some questions and post back here if they say anything interesting. My biggest concern is that they could potentially 1) read any of our emails 2) in reading our emails, see a reference to a personal email account 3) if a user uses the same password for work and personal email, then their personal email could be compromised too. Commented Jul 19, 2013 at 13:28
  • @Austin''Danger''Powers "could potentially 1) read any of our emails" Any host can do this - no exceptions (assuming the mail content itself wasn't encrypted by the sender - but that's a different story).
    – orlp
    Commented Jul 19, 2013 at 13:44
  • I thought that is usually only possible for top-level support. If viewing passwords is something any of their support reps can do, then the risk of a dishonest/ bored employee poking through our emails increases. Commented Jul 19, 2013 at 13:49

All the other answers are great and have very good historical points.

However, we live in the age where storing passwords in plain text causes huge financial problems and may utterly destroy businesses. Sending passwords in plain text via insecure email also sounds ridiculous in the age of NSA sucking all passing-through data in.

You do not have to accept the fact that some old protocols require passwords in plain text. If we all stop accepting such services, probably the service providers would do something about it and finally deprecate ancient technology.

Some people can remember that once when you want to board a plane to flight to another country you would literally just walk into the plane from the street parking. No security what so ever. Nowadays, people realised that appropriate security measures are required and all airports have got them in place.

I would switch to another email provider. Search on "secure email provider" yields many results.

There were some good points in the comments. Probably search for "secure email provider" would make much sense as all email providers would boast they are secure. However, I cannot recommend a particular company and it's probably not a good idea to do either. If you identify a particular company asking hard question about security first will be a good thing to do.

  • 1
    One of the reasons our last webmaster recommended this provider was because it was supposed to be "more secure" than our previous one. I soon discovered that they would not allow certain special characters in passwords that we used to be able to use, then later that their staff had access to our passwords. The only reason they are "more secure" is because they force us to meet certain minimum password length/complexity requirements- big deal. Commented Jul 19, 2013 at 13:21
  • Everyone calls their service "secure", but it turns out that can doesn't always mean what you think it means. The system should make it impossible. I worked for an ISP years ago, and although I could reset any customer's email password, I had no way to see what the current one was. These guys could theoretically read our emails without our knowledge... I shouldn't have to rely on trust. Commented Jul 19, 2013 at 13:21
  • 1
    Do they enforce a maximum length requirement? That's almost always a canary for plaintext password storage.
    – Mels
    Commented Jul 19, 2013 at 13:46
  • 1
    "Search on "secure email provider" yields many results." -- yes and how many of those sites that store passwords in plain text will come up under those results because they believe themselves to be secure. Don't pick hosting for a service you wish to be secure based on a few search results.
    – Rob Moir
    Commented Jul 19, 2013 at 19:39
  • 1
    @RobM: Exactly. What use is it asking the provider if they believe their own service is secure? 100% of them will say "yes". Doing a web search for a generic term like that is a total waste of time. It seems a rather naive way to approach the whole issue actually: "Are your systems secure? Ok, fantastic. Thank you for clarifying that. In that case we will subscribe to your services without hesitation." Commented Jul 19, 2013 at 21:05

My recommendation is to leave, and ask the next guys what their policies are first!
If you're feeling nice, you can tell the old providers why you are leaving.

Also to address another answer's statement, the days of rainbow tables have passed. They have been superseded by high-powered GPUs and take too much storage space (binary hashes obviously don't compress well; and you wouldn't store them in ASCII anyway). It's faster to (re-)compute the hash on a GPU than to read it off the disk.

Depending on hash algorithm used and the GPU, a modern password cracking computer can be expected to churn through about 100 million to a billion hashes per second. According to this, (which is a bit dated on what it thinks a computer/supercomputer can do), that means any 6-char password can be cracked in seconds. Tables for 7 & 8 char hashes in all the various algorithms (MD5, SHA-1, SHA-256, SHA-512, Blowfish, etc.) would consume inordinate amounts of disk space (realise that you need to store them on an SSD, not a magnetic platter, for access speed) and you can see why dictionary-based attacks using the GPU are going to yield passwords more quickly.

A nice article for those coming into the scene is How I became a password cracker at Ars Technica.

  • If your second paragraph is really true, that would mean salting got useless. Is this your personal opinion or based on facts? Commented Jul 19, 2013 at 9:39
  • @TobiasKienzler Indeed, salting using a value that is stored in the output is rendered pretty useless, but salting using a private value remains a viable defence against dictionary attacks. This is not my personal opinion, it is an observation (made by others) on current behaviour of password crackers. I also updated the answer a bit. Commented Jul 19, 2013 at 10:48
  • 2
    With private value do you mean pepper? Anyway, the required properties of a good hashing function are a) they are severely time-consuming, or even better b) they can be chain-applied an arbitrary large amount of times in order to increase the time required. So while I agree that an outdated hash/salt is crack-able, one with sufficiently increased complexity is not. Related: Password Hashing add salt + pepper or is salt enough? Commented Jul 19, 2013 at 12:51
  • @TobiasKienzler Yes, I wasn't sure how specific I could be with you :) Obviously though, the sites should be using bcrypt() these days, but this is more about cracking the hashes of those that don't. Commented Jul 19, 2013 at 14:21
  • 1
    Well in that case I agree, but a bad/obsolete/weak hash (e.g. MD5) is simply inexcusable in a security relevant context. Commented Jul 19, 2013 at 14:23

This Happened To Me!

Some years ago my identity was compromised when my hosting provider (who was also my email provider at the time) suffered a security breach. I awoke to not being able to check my email because my password had been reset. With control of my email they attempted to reset my password at Amazon and PayPal. You can guess what came next, right? Fraudulent credit card charges!

Fortunately I was able to figure out what was happening relatively quickly, get my hosting provider on the phone, and painstakingly validate my identity despite account information and security questions being altered (all in the span of a few hours). During this conversation the customer service representative was able to tell me my password history, when it had been changed, and to what. That was all I needed to hear to know that I absolutely needed to change providers.

There's No Reason It Should Happen To You, Our Your Company!

I had my suspicions about this company's thoroughness when it came to security, things I'd noticed here and there over my years of dealing with them. But I always convinced myself it wasn't a big deal or maybe I was mistaken. I wasn't mistaken, and neither are you!

If I had acted when I first suspected they weren't taking security seriously that whole mini-nightmare would never have happened. To think what could occur in the event a valuable corporate account was compromised? You'd be getting off easy if they only sent SPAM. The company I was working for at the time was also using this provider and we made it our priority to transition off as quickly as possible.

Trust your instincts! Don't pass the buck on migrating out of laziness or because your existing setup "works fine". The most damning part of low hanging security oversights like storing passwords in clear text, improperly configuring servers, etc is that they speak to a general incompetence and/or laziness in their technical culture, and that's a culture I would not want my company's mission critical service contract anywhere near.


I can see an alternative explanation, where Your password actually is hashed on Your provider's servers.

As the provider contacted You just a day after, he probably (and this is a surmise) pulled it from server logs as his password changing script is submitting data via GET method.

It sounds simpler than Your provider having database full of records of when, who and how changed his password. You know Occam's razor... ;)

You must log in to answer this question.

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