GoDaddy store your passwords in clear and may access your VPS without permission
blog.sucuri.net
blog.sucuri.net
It might not be unrealistic to expect them to ask before looking, but if your concern is "one bad apple" then you've already lost.
It's clearly easier to get root passwords out of a database, but in the unlikely scenario where an internal employee sets out to sabotage the whole operation, a couple hundred lines of C code doesn't make the effort that much more unlikely.
Don't get me wrong; storing the passwords in the clear is very bad. The thing that is really going to go wrong? Someone's going to commit a change to their web app that coughs up everyone's password to an outsider.
One requires significant sophistication and risk (of colleagues knowing your intentions are malicious), the other requires virtually no knowledge and low risk.
The default hash for crypt(3) (and thus /etc/shadow) in newer Linux distributions is salted SHA-512. Shouldn't that be significantly more difficult to crack than the old MD5 hashes? john didn't even support it when I checked a few months ago.
Kind of pointless to crack your password, though. I mean, it's not like you use the same one for more than one account.
1Password and encrypted text files serve well as a backup.
I do care if someone uses my password to log in. I'm better than most folks at password security, but there's still too much opportunity provided by letting them have plaintext access to the password (I don't care if it's a decryptable format).
This is a company that has been shown to be consistently anti-customer time after time.
Their founder's latest blog post, on the GoDaddy homepage, is titled '5 things I wish I learned in Business School. Plus ... a smoking HOT blonde.' That pretty much sums up their cynical view of their customers as sheep to me.
It's not that I don't trust GoDaddy. They've been good to me. It is just that I don't trust every person who might happen to see their data base in the next decade.
Crikey, now I have to treat every password I've ever used there as compromised. Bleeeeeeech.
[Edit: It occurs to me that I probably lose consistency points for this since I've previously argued that plain text passwords are "not that big of a deal." Thomas, I owe you a drink.]
It's also standard operating procedure at hosting providers to escrow root access to systems. Some are better than others, but there are even colo providers that do this.
My advice on this issue is simple: no matter who your hosting provider is, your password should be random and system-specific. You shouldn't be using a Unix password so often that you need to remember it. You don't use GoDaddy itself enough to justify a memorable password either. If you lose a random password, who cares?
I don't have a VPS at GoDaddy. However, if their customer service reps can try his GoDaddy account passwords to attempt to log into his VPS, that means that GoDaddy is holding those in the clear somewhere, and that makes it very, very likely they are holding my passwords in the clear, too. That scares me because the prospect of a compromise of my GoDaddy account is really bad. It would allow an attacker to:
1) Compromise my DNS settings. Such as, e.g., MX records. So that they can compromise anything attached to my email address(es) without ever having to actually compromise my email provider. (Change MX record to point from Google Apps to L33t Hacker Krue, ask for password reset, watch as Internet obligingly delivers the email straight to their server.)
2) Compromise my SSL certificate.
3) My real nightmare: authorize transfer of my domains from my account at GoDaddy to their account at a disreputable registrar. They could either commercially exploit them or hold my business for ransom.
Remember, most of these companies have a somewhat-reasonably-tested customer visible web application, and an absolutely horrific "put-a-tick-in-the-URL-and-watch-the-fun" backend customer support web application.
The worst offender is Parallels/Virtuozzo(which I think godaddy uses).
On the linux side. A root user on the host node can simply run the command vzctl enter 1111 and enter your vps without a password. To make things even scarier, when an admin enters your container this way. It doesnt leave a bash history file. You have a very small chance of ever knowing they entered the container at all.
Even if they dont want to enter your container. They still have full access to all of your files which are located in in the /vz folder on the host node.
Other vps solutions are slightly more secure. But it seems like %50 of the vps hosting industry is using virttozzo and most of them probably have no issue entering your container with or with out your permission.
But just for calling back and talking about improvements, gives them a +1 (they are famous for ignoring their users).
Plus, that happened almost two months ago (see the date in the logs) and this post was on my draft for a while... So the sustained anger had time to pass.
But to me this still seems like letting GoDaddy off the hook. I understand they want to provide some sort of malware protection service for which they need to periodically log in to your vps with your password. The question is, if you are concerned about security at all, and you're not interested in taking advantage of that service, why would you continue to do business with a company that openly stores your password and makes it retrievable?
Seems like you shouldn't care if they have some sort of "procedure" in place for password retrieval. That's almost irrelevant. It's time to move your business elsewhere.
This is so unusual, and so unexpected that it should have been in the TOS, at the top. This should NOT have been a surprise, with proper description of the REAL TOS, rather than just the written TOS. (I am assuming this isn't in the TOS, I'm not a GD customer.)
They got root access (at least most hosts I know do), why would they need to reverse an encrypted password that would give them less access than what they already should have? Seems like BS.
That's the title of the post. without permission -- what you're saying could be true; however, permission is granted in that case.
The point is, the person with this key can view -- and possibly lose -- your password (which you may, but shouldn't, use in other places).
And once someone goes through this process, they can take it home with them.
The choice to do this, rather than to use an SSH key, is indefensible, and their explanation shows that they haven't got a clue.
I'll be seriously thinking about moving to them. The most expensive combo package there is less than I pay right now. Plus, they're committed to privacy. Very very compelling.
How has your uptime been? Had any problems?
I had a dedicated server that ran without any problems, and when I had a few questions it was easy to get in touch via phone, mail and IRC.
1) TPB owns them
2) Its a spin-off of TPB
3) They currently host TPB
4) They used to host TPB and no longer do so
5) The two are unrelated
That being said, I don't really care about them having your root password for your VPS. I really don't. Why? Because it's their server (physically). So, if they wanted access to it, they could just pull the hard drive and mount it in another computer. Your expectation of privacy just goes out the window if you don't own the hardware.
You can also view MySQL user passwords by clicking on the username in the panel (https://panel.dreamhost.com/index.cgi?tree=goodies.mysql). This shouldn't be a big deal, though, as you have to store the passwords in the clear in config files anyway.
After looking at the ping and traceroutes, this is not an issue of server slowness, but of the connection slowness from DE to the United States, and as such there is nothing I can do to assist you in this matter.
Basically, it will take some input from you (a password) and then hash that with the domain name of the site you're accessing and supply that when you actually submit the form. This means that my GoDaddy password would be "O0ErvdwEiy" instead of "asdfasdf".
It helps protect you against sites that may store your password in plain text because a compromise of one system does not mean a compromise of all systems.
It's fairly painless to use, but is only supported as a Firefox extension or through their website. There are some issues with sites that use different domains for their login servers or that use flash for their login dialog (yes, they exist).
Storing passwords in the clear sucks. Why would they do that, unless their audience is primarily 'non-technical' people?
Right or wrong, it is very common at hosting companies.
Using the VPS owner's account and password is ridiculous and could cause a legal liability for the VPS owner.
And if you've ever had to deal with them you may agree with me when I say that their website constitutes criminal negligence on the part of the UI/UX designer. Deceptive and high-pressure sales tactics are a bad sign; especially in a company that wants so much of your trust.
* GoDaddy - registrar * Tocici/BuildYourVPS.com - VPS server * EveryDNS
GoDaddy is by far the biggest pain in the @$$ to use out of these.
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.
Longtime slicehost customer here, haven't seen any negative impact from the acquisition.
http://news.ycombinator.com/item?id=1132138
http://journal.uggedal.com/vps-performance-comparison
http://news.ycombinator.com/item?id=966555
http://journal.dedasys.com/2008/11/24/slicehost-vs-linode
Still, Slicehost is certainly one of the best VPS providers.
I am a former Slicehost customer. It was simply put the best hosting solution I ever had. If I were looking for a VPS solution now, there are other good or even better solution out there.
Either way, I stopped using Godaddy a while back - slicehost is amazing for developers and hackers.
its the least navigable site i've ever used in my life. i will always use enom via google.
Who in their right mind would work with this funky company in the first place? They seem to be hiring morons. Or maybe they have the Superbowl models doing their Security.
I really don't see the correlation between a memorable (and thus brandable) business name and business performance.
Some of the web's biggest and most respected properties have almost whimsical names, but that doesn't reduce their "street cred" so to speak.