31

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.

Austin ''Danger'' Powers
  • 1,180
  • 6
  • 21
  • 51
  • 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 Jul 19 '13 at 01: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) – Austin ''Danger'' Powers Jul 19 '13 at 01:34
  • @Austin''Danger''Powers What services does this provider offer? As Michael pointed out, an ISP type of business might have valid reasons for having a plain or reversible password storage scheme.. but if it's a pure web/email host, there's a lot less of an excuse. – Shane Madden Jul 19 '13 at 02:41
  • 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 Jul 19 '13 at 09:18
  • @ShaneMadden: they are an email and web hosting company, not an ISP. – Austin ''Danger'' Powers Jul 19 '13 at 13:42
  • @Austin''Danger''Powers Could you edit some of the information from these comments into the Question so we can clean up the comments a bit? Thank you! – Chris S Jul 19 '13 at 18:24
  • 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 Jul 19 '13 at 18:31
  • Lots of current email and web hosting companies started out as dialup ISPs in the 1990s, or even as BBSes back in the 1980s. – Michael Hampton Jul 20 '13 at 09:22
  • 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 Aug 01 '13 at 13:06
  • "*You either trust your provider or host it yourself.*" I think that sums it up quite nicely. We are thinking of running our own Exchange server in the future actually. – Austin ''Danger'' Powers Aug 02 '13 at 10:33

7 Answers7

33

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

Community
  • 1
Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • 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. – Shane Madden Jul 19 '13 at 02: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. – Michael Hampton Jul 19 '13 at 02: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. – Shane Madden Jul 19 '13 at 02:33
  • There are people out there that still have Windows NT in production. What do you think? – Michael Hampton Jul 19 '13 at 02:36
  • Damn it man, let me dream! – Shane Madden Jul 19 '13 at 02:38
  • It's also possible to store the passwords in every hash format that the ISP would use. This really doesn't help much as most of the hashes are utterly horrible, and rainbow table attacks are nearly trivial. – Chris S Jul 19 '13 at 02:41
  • There is another non technical reason which you have overlooked - for support convenience. Without knowing the password the ISP would not have been able to determine the cause of this breach as a weak password for example. OK so it is not a good idea to store reversible passwords but don't forget that email is forwarded in plain text usually without signatures, it should never be treated as a secure channel anyway. – JamesRyan Jul 19 '13 at 10:38
  • 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 Jul 19 '13 at 13:42
  • @nightcracker What? You can establish a secure connection via SSL, so such a protocol exists... – Tobias Kienzler Jul 19 '13 at 13:56
  • ...see https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange – Tobias Kienzler Jul 19 '13 at 14:08
  • @TobiasKienzler that's true, but encrypting and authenticating the entire communication is more expensive than necessary compared to "just" a secure authentication scheme. – orlp Jul 19 '13 at 14:30
  • 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 – Tobias Kienzler Jul 19 '13 at 14:40
  • @TobiasKienzler: I'm talking processor load mostly, not bandwidth. – orlp Jul 19 '13 at 14:59
12

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.

voretaq7
  • 79,879
  • 17
  • 130
  • 214
longneck
  • 23,082
  • 4
  • 52
  • 86
  • 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. – Austin ''Danger'' Powers Jul 19 '13 at 02:02
7

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.

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • 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. – Austin ''Danger'' Powers Jul 19 '13 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 Jul 19 '13 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. – Austin ''Danger'' Powers Jul 19 '13 at 13:49
6

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.

oleksii
  • 266
  • 1
  • 3
  • 11
  • 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. – Austin ''Danger'' Powers Jul 19 '13 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*. – Austin ''Danger'' Powers Jul 19 '13 at 13:21
  • 1
    Do they enforce a _maximum_ length requirement? That's almost always a canary for plaintext password storage. – Mels Jul 19 '13 at 13:46
  • I mean, okay, a maximum length requirement somewhere lower than a few hundred characters. I don't expect my webmail provider to willingly hash a megabyte of password every time I log in. – Mels Jul 19 '13 at 13:47
  • 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 Jul 19 '13 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.*" – Austin ''Danger'' Powers Jul 19 '13 at 21:05
  • @Austin''Danger''Powers When I wanted a "secure" email service, I did it myself. There are no plaintext passwords to be found anywhere. Nor any unencrypted connections, for that matter. – Michael Hampton Jul 20 '13 at 09:18
3

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.

Nicholas Shanks
  • 141
  • 4
  • If your second paragraph is really true, that would mean [salting](https://en.wikipedia.org/wiki/Salt_%28cryptography%29) got useless. Is this your personal opinion or based on facts? – Tobias Kienzler Jul 19 '13 at 09: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. – Nicholas Shanks Jul 19 '13 at 10:48
  • 2
    With private value do you mean [pepper](http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html)? 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?](http://security.stackexchange.com/q/3272/3272) – Tobias Kienzler Jul 19 '13 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. – Nicholas Shanks Jul 19 '13 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. – Tobias Kienzler Jul 19 '13 at 14:23
1

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.

Matt Surabian
  • 261
  • 1
  • 5
0

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... ;)

Peta Sittek
  • 1,852
  • 2
  • 11
  • 6