Slashdot Mirror
Dreamhost FTP/Shell Password Database Breached
New submitter Ccmods writes "Below is a snippet from an email Dreamhost sent to subscribers early Saturday morning, describing an intrusion into the database storing FTP and SSH usernames and passwords: 'We are writing to let you know that there may have been illegal and unauthorized access to some of your passwords at DreamHost today. Our security systems detected the potential breach this morning and we immediately took the defensive precaution of expiring and resetting all FTP/shell access passwords for all DreamHost customers and their users. ... Only the FTP/shell access passwords appear to have been compromised by the illegal access. Web panel passwords, email passwords and billing information for DreamHost customers were not affected or accessed.'"
As a Dreamhost customer, I watched this unfold in real time. Apparently the passwords were hashed, and there's no indication that they were compromised, other than the fact that it was technically possible. So they changed the passwords because it's cheaper, PR-wise, than being wrong.
There's a big warning up on the panel, which has a password stored in a different, non-compromised DB. Between the panel and the email, I doubt anybody's confused as to what's going on.
In other words, it's really not that big of a deal. The database shouldn't have been compromised, and I'll expect a full postmortem of how they screwed that up, but in terms of damage (or even inconvenience), there really isn't any to speak of.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
If the passwords are used for FTP they should be considered comprimised anyway.
http://michaelsmith.id.au
It got so bad at one point that I recommended that readers of my blog .
Never email donotemail@WeAreSpammers.com
Were these passwords hashed?
If not, sweet mercy, Dreamhost, what could you possibly have been thinking?
If so, sweet mercy, Slashdot, could you be troubled to include this little detail in the summary?
As a long time Dreamhost customer, I have never encountered an incident like this before. However, I think it was a good decision to reset the passwords as it was a painless process both for them and for their users. In any case, I'm bracing myself for any aftershock.
Stop being hysterical. The passwords will be hashed.
The only thing that confuses me is the use of "database" in the context of ssh/sftp. Those passwords aren't stored in a database, but in the shadow file.
It could be a cpanel or dreamhost specific thing, where a redundant copy of the password hashes are stored in an actual database.
For the hashing algorithm used, try # authconfig --test | grep hashing
A copy of the script shown at http://www.nk.ca/blog/index.php?/archives/1275-Phishing-spam-mail-script-intercepted.html was sitting at the root of my domain. Pretty sure it's a remailer.
Why save your soul when you can sell it for a profit?
I'll see your SFTP and raise you disabling password authentication entirely, and using SSH public key authentication only.
If your SSH server is visible over the Internet, you should use public key authentication instead of passwords if at all possible. If you don't think it's important, try logging all of the malicious login attempts you get for the next week.
-- https://help.ubuntu.com/community/SSH/OpenSSH/Keys
or the illegal authorised access...
The conversation at Dreamhost probably went something like:
"The passwords are hashed though, right?"
"Yes."
"So they can't reverse the passwords out of it?"
"Virtually impossible."
"Is there any advantage they gain from having the hashed passwords?"
"Well, it would allow them to brute force their guesses against it without fear of being slowed down or blocked."
"But wouldn't they need to know our salting algorithm for that to be useful?"
"Um..."
"Let's go ahead and change the passwords."
If I had to guess, the conversation at Dreamhost probably went something along the lines of:
"The passwords are hashed though, right?"
"Yes."
"So they can't reverse the passwords out of it?"
"Virutally impossible."
"Is there any advantage they gain from having the hashed passwords?"
"Well, it would allow them to brute force their guesses against it without fear of being slowed down or blocked."
"But wouldn't they need to know our salting algorithm for that to be useful?"
"Um..."
"Let's go ahead and change the passwords."
I had only signed up to dreamhost 2 days ago, and yesterday for the first time in 5 years I was blocked by Facebook for having a virus or malware. I did a full scan on my up-to-date Kaspersky anti-virus and it found nothing. I am still blocked from posting to Facebool for another 6 hours after certifying that I ran a scan.
It could just be me and that it is late at night here, but why on Earth would you want to keep a database of SSH and FTP passwords, hashed or not?
Here's an example of somebody getting it badly wrong but little press about it.
A few weeks ago Telstra Bigpond, one of Australia's largest ISPs, was caught out with the utterly stupid situation of having their customer list of username, plain text password, email address and mailing address out there naked on the internet. Outsourced workers in call centres needed the information but some idiot decided instead of them having to log in somewhere to get access that they should simply be able to use a URL with the customers username on the end of it. The site with the passwords was still up ten hours after it hit the mainstream news.
Now that's the sort of thing I expect when I see something like the article summary above, but instead it's the opposite - full disclosure early instead of being caught out by the press and not plain text passwords.
Your suggestion is actually even worse. A passphrase or password of some kind shows that there is a human being that should be allowed in instead of whoever just happens to possess something with that key.
I think you've misunderstood some good advice of using BOTH a key AND a password/passphrase. The quote you've used has left out the point that typically when you generate a key it also prompts you for a password/passphrase. Passwordless keys are useful within internal networks but are a very bad idea for anything that comes in remotely. You can be one click away from a thief getting access.
Nobody implied that you shouldn't encrypt your private key with a strong passphrase.
This setup is absolutely perfect for laptops, because it's two-factor authentication. The thief will need both the key from the laptop and the passphrase.
As a dreamhost customer (who doesn't store anything overly sensitive there), I've noticed that they also have a tendency to send me mail with my real password in the past, which indicates that it's stored somewhere in cleartext (which is BAD).
As the Unix does since ... 1969?
Seriously, WTF?!
- Hubert
Apart from some guy under the handle of "sakdoctor"?
It's not a "reading comprehension" thing if you state the opposite of what you now say you intended.
My point stands - as written it's very bad advice to do it all with keys and no password authentication with the keys.
What the fuck do you expect readers to think you mean by "disabling password authentication entirely" apart from what it says? Despite the backpedalling I think you really did mean it. Your above post reads to me as "I'll show off and I'll top sftp with a good idea I don't understand so I'll suggest doing it in a fucking stupid way."
Dreamhost seems to have a surprisingly participatory workplace, runs on a free software stack, and has an environmentally-friendly setup. I've set up many sites with them and have tried all the other big hosts, and I now recommend only Dreamhost to friends/family/coworkers.
Their support is very responsive, and the occasional technical hiccups with hosting packages are handled quickly and professionally. Although this break-in is a bit scary, it seems like they're playing "better safe than sorry" by resetting the shell/FTP/SFTP passwords. It was an annoyance late last night when I went to do routine maintenance and couldn't get shell access, and I (somewhat comically) kept trying other passwords, thinking for some reason that there was a problem with my keyring. But I was greeted by a very visible message as soon as I logged into the Dreamhost web control panel, took two seconds to reset my pass, and that was that. Nothing to see here folks, move along.
Geeks like to think that they can ignore politics, you can leave politics alone, but politics won't leave you alone.-rms
At least in the past they sent me my web panel password when I asked them to.
How else can they send the password back?
What sucks about this is I set up a DH account the day before this happened x.x
Simon Anderson Says:
January 21st, 2012 at 11:55 am
some more detail – our systems have stored and used encrypted passwords for a number of years, however the hacker found a legacy pool of unencrypted FTP/shell passwords in a database table that we had not previously deleted. We’ve now confirmed that there are no more legacy unencrypted passwords in our systems. And we’re investigating further measures to ensure security of passwords including when a customer requests their password by email (this was not the issue here, though). Re your shell accounts, I’d suggest that you select a new password just to be sure.
Search for "January 21st, 2012 at 11:55 am" at this link
Also, due to the number of customers changing their passwords, the password sync time is very slow right now. More info here.