Brian Kreb was recently shocked when his hosting provider sent him his password in plain text. He wrote a post about it and made a conclusion that it is quite a common practice among hosting providers and that “naming and shaming may be the only way to change” it.

But why do hosting providers save passwords in plain text? Maybe because most of them don’t invent anything and just rely on web hosting automation programs?
Enter Parallels Plesk Panel.

They advertise themselves as “the most widely used hosting control panel solution. With more than 250,000 Windows and Linux servers deployed, Parallels Plesk Panel is the preferred choice for hosting service providers, web designers, and website owners.” They also advertize top-notch security that “protects personal data and websites“.

Plain text passwords

But what about the Plesk security in real world? Can we call it “top-notch” if I tell you that Plesk stores passwords in plain text?!

What’s the problem?

But maybe is not such a big issue? After all, with proper permissions, only server admins have access to the passwords and server admins should have full access to every part of servers anyway.

That’s not so simple:

Admins don’t need passwords to access sites of their clients. And they should not see their passwords. It’s a privacy thing. Some clients may use the same username/password combinations on other sites (Facebook, Gmail, PayPal, their banks, etc. – I know, it’s stupid to use the same passwords everywhere but still is a common practice) and server admins can easily abuse this information (especially given the amount of information they already know about their clients anyway: real names, addresses, phone numbers, etc.)

Server admins can be target of spear-phishing and malware attacks that steal passwords. Once attackers obtain Plesk admin credentials they can easily get passwords of all server accounts.

And don’t forget about bugs and security holes that can expose stored passwords or provide admin access to people without proper authorization.

Remember, Parallels bragged about 250,000 servers with installed Plesk Panel. That’s many millions of individual websites and millions of user accounts. Sounds like a good target for attacks.

Back to the Brian’s post I mentioned in the beginning — instead of naming and shaming individual hosting companies, we can name and shame software that they use. But if you are concerned about individual hosting providers, you can simply check if they use Plesk.

I have a few questions to my blog readers:

Do you think it’s OK that your hosting provider or your service provider stores your passwords in plain text?

How many of you have sites on servers with Plesk Panel? Did you know that your passwords are stored in plain text?

What can you say about other web hosting automation programs, e.g. CPanel? Do they store hashes or real passwords?

Is the latest version (11) of Plesk Panel still stores passwords in plain text? (They advertise “improved security” but who knows what this really means.) – Update: Brian (Parallels) says that Plesk 11 no loger stores passwords in plain text. Great!

We already swapped over to PLESK 11 immediately and deployed new servers – moving all clients over to them progressively and gracefully.

This new security feature was one of the driving forces for a speedy update. Unfortunately, there is no admin feature to send out password request e-mails that I am aware of to help provide service to clients on par with simply sending them their password (as mentioned earlier in this e-mail).

So why bother? This is as good as useless – an attacker who gains access to the passwords will have access to the encryption key so can just decrypt the passwords. Passwords should always be hashed, not encrypted.

And in the case of hashed passwords, a sitewide salt means an attacker can compute a site-wide rainbow table. Salt should be unique per password.

Then you need to be using an appropriate hashing algo (bcrypt or scrypt), and need to enforce or at least encourage strong passwords / passphrases – you’ve done your bit at this point.

How is it that such technical incompetents can be so successful? Right place, right time, wrong developers?

I tried to search for those “engine.php” and “ctrl.php3″ files on a dozens of servers affected by this last Plesk attack and got 404 errors.

Maybe they were there some time ago or maybe it’s just a different attack. After all, as Axel showed, hackers used valid user credentials to log into Plesk and modify files in Plesk Editor. He believes that the passwords were stolen earlier this year (in February), and the account that has been hacked in June (on his server) are the ones that changed their passwords back to old ones after he had reset all passwords.

A couple months ago and doing some rough statistics I noticed around 10% of the PLESK panels to respond 200 on engine.php and/or ctrl.php3.

The attacks that are mentioned, the ones that took place around the first days of 2012 were attacks to gather credentials from user accounts (PLESK panel user accounts). Credentials used later on to put specific attack bots in the systems from the client accounts. So yes the attackers gathered a very large number of Plesk user credentials.

I wrote about the issue around March 2012 and also later during that month I found that some systems were even compromised on the last days of 2011 (November 2011).

I just updated the script to cover and another possible file / request.

This is a general problem with web hosting automation software – I’ve not played with hsphere in a long time but that certainly used to store passwords for various things in it’s db in plain text.

There are other offenders too (albeit in slightly different ways) Onapp’s web interface (set to http by default) returns a vm password on the vm details page each time it’s visited, hidden by javascript.

For a good indication of what happens when this sort of issue is discussed see

One thing that plaintext passwords enable is authentication mechanisms such as CRAM-MD5 (where both sides need to know the plaintext, but even with a nonencrypted channel eavesdroppers cannot derive it — and if the server is impersonated, it cannot simply glean your password by you helpfully providing it).

Admittedly that’s seldomly used (some mail clients support it) and you /should/ be using TLS/SSL instead to protect from eavesdroppers (though that has baggage of its own, it is still the better choice).

[...] second biggest web hosting control panel after CPanel) which exposed site passwords in plain text: unmaskparasites.com/2012/06/26/millions-of-website-passwords-stored-in-plain-text-in-plesk-panel. Once passwords have leaked, just updating plesk doesn’t fix the problem, so there are loads [...]

True – Plesk < 11 stores passwords in plain text. But what's the big deal? If the server is compromised to the extent that someone gets access to these passwords, the fact that they're in plain text doesn't matter anymore.

The fact that passwords are in plain text is often a good thing. It allows server admins to police password complexity of user accounts.

All public servers are major targets for spam relaying, and mail accounts are continually being threatened with brute-force attacks.

When clients use simple passwords, they can cause a lot of problems for every client on the server, and the server admins and owners.

Setting password complexity requirements in Plesk is only good for new accounts – it does jack sh*t for accounts that have been around for 10 years.

I'm actually disappointed that Plesk 11 encrypts user passwords now.

About this blog

Occasional posts from the developer ofUnmask Parasites about things that hackers already know and site owners should know (if they don't want to be victims).