This does not excuse them from accessing your VPS without your permission, of course, but the only thing you know about their password storage mechanism is it allows them to access your password when they need it. You have no idea what the procedure for this access is, or how exactly it's stored.
The problem is not that they can get hacked and someone steal all their data, the problem is a malicious employee acessing my private server and my passwords. That's the issue.. unless they trust all their employees.
Having the password reversibly encrypted means that if someone gets their hands on a dump of the db, they will at least not be able to automatically gain access to millions of accounts with no effort. Depending on the encryption scheme used, it may even be extremely secure - for example, decryption could require sending the encrypted string to a different, extremely secure server off the WAN that answers with the password.
I have seen lots of "reversable encryption", though.
Maybe I've just gotten lucky in my career, and I just get the fun applications where people do this wrong. But there's no way GoDaddy did it right.
If I did this, that's how I'd do it. Have a separate computer, locked down to the max, except for a couple of functions: accepting HTTP requests POSTing an encrypted password, then sending back the decrypted string. That function would be severely rate-limited. Another function, to confirm the hash of passwords, would not be rate-limited, allowing high volumes of website access.
I could make that machine friggin' impregnable (and so could you). But yeah. No-one ever does it.
I'm not sure how "extremely secure" this "password-decrypting server" design really is, by the way. SQLI is often equivalent to remote code execution. Even when it isn't, XSS is equivalent to operator access, and operators can use the feature that decrypts the password.
Passwords are hazmat. You shouldn't be storing them, at all.
You should write up a definitive guide for password security. For instance, I want to know if we should still use salts in the age of bcrypt, etc. Tell us what to do, man.
Still, storing recoverable passwords (which is what most people mean when they say "cleartext") without clear notice is a terrible idea for all the reasons people expect. The list can be stolen or misused, and this sort of thing happens routinely.
Definitely, which is why, as others have pointed out, you have to get a host you can trust.
Still, storing recoverable passwords (which is what most people mean when they say "cleartext") without clear notice is a terrible idea for all the reasons people expect. The list can be stolen or misused, and this sort of thing happens routinely.
Whilst I agree that storing cleartext passwords is not a great idea, I think the worse idea is to rely on every single web service you belong to to keep your authentication/authorisation credentials secure.
Your process of keeping your credentials secure should not depend on the security practices at any single one of the services you use.
People who publicly criticise hosts for storing passwords in clear, but then use the same password for multiple services, are nothing less than hypocrites. Remove the log from your own eye before picking at the straw in someone else's.
What you're saying is equivalent to "Yes, they stole your car, but they stored it in a safe garage". Not redeeming, at all.
Broken analogies really don't help the discussion.
I'm sorry, but this difference is completely trivial. Putting a password in some reversible encryption is just security by obscurity. In the worst case the people who managed to break into your site and steal all the passwords can just steal your magical decryption routine as well.