Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Dreamhost FTP/Shell Password Database Breached

Soulskill posted more than 2 years ago | from the another-day-another-intrusion dept.

Security 123

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.'"

cancel ×

123 comments

Sorry! There are no comments related to the filter you selected.

Not a big deal (5, Informative)

slimjim8094 (941042) | more than 2 years ago | (#38776719)

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.

Re:Not a big deal (3, Insightful)

ZackZero (1271592) | more than 2 years ago | (#38776761)

After spending time reading the misplaced anger and blatant misunderstanding of the method of password storage over on DreamHostStatus, it's good to see some rationality being injected somewhere.

Re:Not a big deal (5, Funny)

Anonymous Coward | more than 2 years ago | (#38777195)

it's good to see some rationality being injected somewhere.

You mean as opposed to SQL being injected somewhere, of course.

Re:Not a big deal (4, Funny)

ZackZero (1271592) | more than 2 years ago | (#38777463)

Of course, since rationality hasn't historically been deliverable by SQL injection :P

Re:Not a big deal (-1, Flamebait)

Alex Zepeda (10955) | more than 2 years ago | (#38777489)

The anger and misunderstanding probably comes from the way that DreamHost uses their system status blog to talk down to and make fun of their customers. DH is a mickey mouse operation if I've ever seen one. If they're owning up to the FTP/SSH database being compromised, there's probably more to it. I haven't used DreamHost in almost six years, and I didn't have a hard time talking clients into switching away after their last spate of self-inflicted downtime (and nonchalant manner in which they dealt with intrusive maintenance).

More to the point, storing hashes of passwords doesn't guarantee security... and there's no indication that they actually stored the passwords in a secure manner.

Re:Not a big deal (3, Insightful)

etresoft (698962) | more than 2 years ago | (#38777913)

Like many Dreamhost customers, I have used many other hosts over the years. None has even come close to Dreamhost. Many companies try to project an aura of professionalism but are really mickey mouse operations on the inside. Dreamhost is the opposite. I think they make a point to act like clowns only to scare off the clueless, high-maintenance market.

Re:Not a big deal (2)

JWSmythe (446288) | more than 2 years ago | (#38778025)

    Well, several years ago, before they moved their servers, I was in the same datacenter with them. My cage was almost next to theirs. On several occasions, I talked to them. All of their folks knew their stuff, and showed me around the inner workings a good bit. I was impressed. I highly recommended them at the time. Unless someone made some horrible decisions, I strongly suspect they're still worth the praise.

    Now, what happened? Hell if I know. I'm on the other side of the country now, and we don't talk. Was it that someone snagged the shadow file, or a hashed password list? Was it that someone brute forced several passwords? Either way, they did the right thing, and changed all the passwords that were potentially compromised.

    Sure, there's a risk of finding hashed passwords via rainbow tables. Someone could brute force the passwords on their home machine (otherwise, someone would notice a script taking 100% of the CPU time). And, if users can pick their own passwords, there's always a huge risk of weak passwords. I've known so many people that use dictionary words, or dictionary words followed by one or two digits. And of course, I follow that up by lecturing them on strong passwords, and password security. So they may pick a strong password that time. They'll probably go back to using weak passwords for other things.

   

Re:Not a big deal (1)

Alex Zepeda (10955) | more than 2 years ago | (#38778575)

I'd be hard pressed to believe you've dealt with anyone other than DreamHost. When I failed to renew my service with them it was because their hosting was glacial. It could barely keep up with a lightly used PHP image gallery. That was years ago. When I migrated clients away from DH last year it was because of chronic downtime. "Oops we fucked up" is great, and it's honest. It's also not something you want to keep seeing [dreamhoststatus.com] . "Oops we fucked up, but your worthless blogs about your kittens' trousers are safe" [dreamhost.com] is /not/ something you want to see, ever. We're suffering a DDoS... no... wait... we don't know how to fix our Cisco equipment... [dreamhoststatus.com] is not something you want to see ever. Certainly it's not something you want to keep seeing [dreamhoststatus.com]

Not doing any manner of scheduling for intrusive maintenance is not simply a tactic to scare away high maintenance customers, it's a tactic to scare away paying customers. You wanna know what's even less professional? Not having any phone support in the first place, and then not having any e-mail support or publicly available system status because everything's on the same network. A single point of failure isn't a tactic to "scare off the clueless, high-maintenance market" it's a hallmark of someone who doesn't know what they're doing.

Re:Not a big deal (0)

Anonymous Coward | more than 2 years ago | (#38779299)

Reads a bit like fud to me. They have thousands upon thousands of servers. Something is bound to be down at any given time and from the status site I get the impression that statistically most of the time their stuff is running well.

I've been with them for 6 years. Very happy. My particular server has hardly ever gone down for noticeable period and gets 2.5 million page views per month without problem. 6 years before with a much inferior service for double the price.

Oh they do have phone service - they call you back, though in us and Canada only. Fair enough - I am in UK, but there email response, which they do have btw, is decent. And I am only on shared hosting.

Re:Not a big deal (2)

makomk (752139) | more than 2 years ago | (#38779739)

We're suffering a DDoS... no... wait... we don't know how to fix our Cisco equipment... is not something you want to see ever.

I think off-hand - though I don't deal with Cisco kit - that is indeed a failure mode that shouldn't happen ever.

Re:Not a big deal (0)

Anonymous Coward | more than 2 years ago | (#38776779)

I got the same message even though I am only a DNS customer. I chose to ignore it...

Re:Not a big deal (2)

kelemvor4 (1980226) | more than 2 years ago | (#38776789)

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.

It's good to see they took the matter seriously, even with the circumstances you describe. Bad that it happened in the first place, but it sounds like the situation was nicely handled.

Re:Not a big deal (1)

Anonymous Coward | more than 2 years ago | (#38776821)

>Apparently the passwords were hashed.

If you choose the "forgot my password" option for the dreamhost webpanel it automatically emails you your current password in plain text form (not a new password or a way to reset).

Given that webpanel password is stored in platintext by dreamhost I have little confidence that ftp passwords have stronger protection.

Re:Not a big deal (1)

ZackZero (1271592) | more than 2 years ago | (#38776843)

The only offered method for dealing with a forgotten ftp/shell password is to force a reset through the panel, either by having one generated on request or by providing one yourself. It is displayed only once after that point, in the panel, as a confirmation.

Re:Not a big deal (3, Informative)

LordLimecat (1103839) | more than 2 years ago | (#38777265)

Just because you can get it emailed to you does not mean that it is stored plaintext.

Re:Not a big deal (1)

metrix007 (200091) | more than 2 years ago | (#38777301)

It means they are stored in a less than ideally secure way. If a script can retrieve the password, so can an attacker.

Re:Not a big deal (1)

LordLimecat (1103839) | more than 2 years ago | (#38778201)

That is probably true in this case, but is not necessarily true in all cases. Imagine, for example, that the password is encrypted with the email address as its key, and the email address is hashed. Upon login, a hash lookup is done for the email address, and the encrypted password is decrypted and compared to the one sent. Or alternatively, the password is stored both encrypted as mentioned, and hashed, so that logins are done by 2 hash checks.

Either scenario would allow the user to retrieve the password without the host or an attacker being able to see what the associated email or password is.

Re:Not a big deal (1)

fluffy99 (870997) | more than 2 years ago | (#38778369)

That is probably true in this case, but is not necessarily true in all cases. Imagine, for example, that the password is encrypted with the email address as its key, and the email address is hashed. Upon login, a hash lookup is done for the email address, and the encrypted password is decrypted and compared to the one sent. Or alternatively, the password is stored both encrypted as mentioned, and hashed, so that logins are done by 2 hash checks.

Either scenario would allow the user to retrieve the password without the host or an attacker being able to see what the associated email or password is.

I'm pretty sure the hosting provider would require an unencrypted/unhashed copy of your email address.

Re:Not a big deal (1)

metrix007 (200091) | more than 2 years ago | (#38778751)

For that to work any records of email address would have to protected. Not really a practical solution.

Re:Not a big deal (1)

dkf (304284) | more than 2 years ago | (#38780985)

That is probably true in this case, but is not necessarily true in all cases. Imagine, for example, that the password is encrypted with the email address as its key, and the email address is hashed. Upon login, a hash lookup is done for the email address, and the encrypted password is decrypted and compared to the one sent. Or alternatively, the password is stored both encrypted as mentioned, and hashed, so that logins are done by 2 hash checks.

Store the password hashed in the "production" database, and keep an encrypted copy in a separate database hosted on a service that is responsible for sending out emails relating to password reminders (or resets). All the frontend services can do are to validate that a supplied password matches (through hashing) or request a reminder or reset for a particular user; nothing else should be possible since the encrypted version is kept out of reach.

Not that I expect anything so sensible in this case. SQL injection in one part of a system is a good indication that the rest is not much better.

Re:Not a big deal (1)

asdfghjklqwertyuiop (649296) | more than 2 years ago | (#38778093)

If they can email you the plain text then they are not hashed.

Re:Not a big deal (0)

Anonymous Coward | more than 2 years ago | (#38776851)

Apparently the passwords were hashed.

Where are you seeing that they were hashed? Their control panel displays passwords for email/mysql.

Re:Not a big deal (1)

Literaphile (927079) | more than 2 years ago | (#38776967)

Where? I've been a DH customer for 5 years and I've never been able to recover a password, only reset it. You can see the password when you first set it (i.e. it just confirms that you've chosen XYZ as your password), but after that you can only reset it, which would lead to the conclusion that it's hashed.

Re:Not a big deal (3, Interesting)

Anonymous Coward | more than 2 years ago | (#38777011)

>Where? I've been a DH customer for 5 years...

The "forgot my password" link on the webpanel login page (discovered today by virtue of needing to log in to set user passwords again).

You are right that for users within your webpanel account there is no email reset option - you log into the webpannel to set these passwords.
But the webpanel account itself - passwords are emailed in plaintext.

Re:Not a big deal (1)

slimjim8094 (941042) | more than 2 years ago | (#38777141)

Yes, it does. Those are stored in plain text anyways, at least the mysql ones (your config files). The passwords in question are for shell/FTP accounts, as the title says.

Re:Not a big deal (1)

Anonymous Coward | more than 2 years ago | (#38776909)

This has been a problem for at least 3 months, any dreamhost user can upload a php based rootkit and download the password database.

I'm speaking from experience in removing rootkits from dreamhost hosted wordpress sites.

Re:Not a big deal (1)

dgatwood (11270) | more than 2 years ago | (#38777099)

Uh... what do WordPress user databases have to do with shell account user databases?

Re:Not a big deal (1)

Anonymous Coward | more than 2 years ago | (#38778007)

Not a wordpress database. Upload a rootkit to DH, and you can read any file on the system as if you were root. It has nothing to do with wordpress other than that being the mechanism by which the rootkit was dropped into DH's servers. The rootkit runs with the privileges of the web server, not the user. You can read all the files in /etc

Re:Not a big deal (1)

MichaelJ (140077) | more than 2 years ago | (#38778249)

And why is the web server running as root?

Re:Not a big deal (0)

Anonymous Coward | more than 2 years ago | (#38778631)

Good question, either one of their servers was setup improperly, or the rootkit did some privilege escalation. I only remove the rootkits, I don't risk damaging the system with tampering with the files.

But that's the point. The rootkit can read EVERY file on the server. By all accounts, the web server has more access than any single SSH user other than the root user. No password database needed.

Re:Not a big deal (4, Insightful)

sortius_nod (1080919) | more than 2 years ago | (#38776925)

I actually think it's a big deal, but not for the reason most people are crying about.

It's a bit deal that they have been open, honest, & cautious about the intrusion. Having seen so many high profile companies take the opposite stance lately, the DH intrusion should be made a big deal of, if anything, to show other companies how you react to being hacked without losing face with customers.

For me, there is only one chance when it comes to security to get it right. If you try to hide intrusions, lie to customers, or stonewall tech sites trying to get more information, you aren't a company to be trusted with my data.

Re:Not a big deal (2, Informative)

Anonymous Coward | more than 2 years ago | (#38777239)

Let me second that. I got the email, checked into my dreamhost account, used the excuse to call my sister (and will have a conversation with someone else). and then I was done with the *protective* aspect. Actually, the protection happened right away because dreamhost locked the possibly-compromised accounts immediately, as I understand it. The *recovery* aspect, then, just took a few minutes, and involved an enjoyable family chat.

I don't think of dreamhost as "less secure" than I thought it was. I think of it as *more* secure than I thought it was. Before, I assumed they followed good practices. Now I have more reason to think so.

Had I found out months later, that hackers had compromised dreamhost, and that dreamhost had kept it quiet, I would have been an unhappy customer. As it is, I'm a happy one.

Nice work, dreamhost!

Re:Not a big deal (1)

tqk (413719) | more than 2 years ago | (#38777511)

Had I found out months later, that hackers had compromised dreamhost, and that dreamhost had kept it quiet, I would have been an unhappy customer. As it is, I'm a happy one.

I'm happy for all the DH customers that this's turned out to be little more than "HEADS UP", and it appears DH went out of their way to handle the damage correctly. Great! Bravo!

However, as an IT guy interested in system security, I *hate* that this happened in the first place, and seems to happen far too often regularly. Why is FTP still being used, and why don't you guys know how powerful a shell account can be in the hands of a master (or a gifted amateur, for that matter)?

This !@#$ shouldn't happen. Yet again, someone dropped the ball, IMO. If you're not sure what the downsides are, don't turn it on until you do know and understand how to mitigate it.

FTP, in 2012! Eeeww! Just sayin'.

Re:Not a big deal (3, Informative)

etresoft (698962) | more than 2 years ago | (#38777807)

Alas, Dreamhost markets to the public at large, who often have no idea anything other than FTP exists. Dreamhost also provides sftp, ssh, WebDAV, and secure e-mail.

Re:Not a big deal (0)

Anonymous Coward | more than 2 years ago | (#38778105)

I wouldn't be surprised if somewhere out there exist software packages that are unable to use anything but FTP. For the rest of us, DH has a "Disallow FTP" checkbox the user account panel.

Re:Not a big deal (1)

Voyager529 (1363959) | more than 2 years ago | (#38778407)

FTP is still a useful protocol because:

1.) few people upload sensitive data to a web hosting service.
2.) it requires less CPU overhead.
3.) FTP transfers, while better with a client like Filezilla/Cyberduck/xFTP, don't *require* a client since both Windows and OSX support it natively.

Re:Not a big deal (2)

Solandri (704621) | more than 2 years ago | (#38778967)

FTP is still a useful protocol because:

1.) few people upload sensitive data to a web hosting service.

The problem with FTP isn't that it transmits data as cleartext (though it does that too). The problem is it transmits passwords as cleartext. Anyone snooping on your FTP session will know your username and password.

Re:Not a big deal (1)

Tanktalus (794810) | more than 2 years ago | (#38780939)

"Shell account" is why I'm with DH. I upload everything using rsync-over-ssh. It's not like those other options aren't there.

Meanwhile under the radar (3)

dbIII (701233) | more than 2 years ago | (#38777997)

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.

Re:Not a big deal (2, Interesting)

Anonymous Coward | more than 2 years ago | (#38776957)

It's a bit less trust-inspiring than you represent it.

Brian H. from Dreamhost initially posted on the Dreamhoststatus page that FTP/SSH passwords are only stored hashed. Later he deleted that statement. Why?

Web panel passwords are definitely stored in a retrievable way, because when you forget your web panel password they mail it to you. Not a nonce key that allows you to set a new password, they mail you the actual password. According to Dreamhost CEO Simon Anderson [dreamhost.com] , they're now evaluating if they could change this practice.

Anderson also said that FTP/SSH passwords are stored "encrypted". He didn't say "one-way hashed" or "salted and hashed", he said "encrypted". So it could be a reversible encryption with the master password retrievable from somewhere else. Anderson doesn't reply to requests to specify what "encrypted" means.

“however the hacker found a legacy pool of unencrypted FTP/shell passwords in a database table that we had not previously deleted.”

So they had stored passwords in plaintext in the past and forgotten about it.

Allegedly, email passwords were not compromised, but they recommend changing them just to be sure. Actually an intruder with a FTP password could just FTP into the user's home directories and with a pretty good chance retrieve SQL and email passwords from config files and logs of any webapp that uses a database/email. Most webapps store those in plaintext. Dreamhost doesn't say if they checked which user files where accessed in the vulnerable time span. SQL connections are restricted to Dreamhost servers, but an SQL password gives you web access to databases over phpmyadmin.

There are several requests in the web panel's Suggestions section to stop sending passwords to customers or displaying them in the web panel. Dreamhost has been ignoring those requests for years.

Re:Not a big deal (2)

jafo (11982) | more than 2 years ago | (#38776999)

Well, it *IS* a big deal, but only for people who are using the same password on dreamhost and other services. Obviously, people shouldn't do that, for reasons that are now obvious, but people do. Whoever got this password list is likely to start looking at facebook and other sites for accounts with similar names and use any passwords they can crack from this database.

The compromise is sometimes not the obvious one... For example, I had an account on a service that was recently compromised, and that account had a special e-mail address associated with it that was whitelisted. The password on that account was a strong password, and wasn't shared with another service, but it didn't take long before I started getting all sorts of spam to my inbox that used that e-mail address to get around my anti-spam filters...

Re:Not a big deal (0)

Anonymous Coward | more than 2 years ago | (#38777045)

If someone is using shared/managed hosting (which I assume this is) I would hope that they would realise the eggs are in one very attractive and lucrative to infiltrate basket that they have little control over the security of and would have some kind of disaster response planning and implementations that take this into account.

Re:Not a big deal (0)

Anonymous Coward | more than 2 years ago | (#38778155)

Are you sure they are hashed? When I click on the "forgot my password" link they email my password to me in plain text. I emailed them about it a year ago and they said that was by design.

Re:Not a big deal (1)

fluffy99 (870997) | more than 2 years ago | (#38778493)

Except that they found a symptom, and not the actual problem. Someone has unauthorized access to their servers. Until they figure out how they've gotten in and closed the door, it's pointless to scramble passwords. This also wasn't a "quick response" as people have been complaining about their accounts getting hacked and their WP configus and .htaccess files getting modified for months.

Re:Not a big deal (1)

Mike (1172) | more than 2 years ago | (#38778499)

Well, my sister's company uses Dreamhost, and they were hacked. They do use ftp (instead of sftp) to upload their files, so I'm guessing that's the likely culprit. I've since set them straight.

I've been a loyal Dreamhost cusomter since 1998 and I'm happy with their response.

Cleartext passwords (1)

phorm (591458) | more than 2 years ago | (#38778513)

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

Re:Not a big deal (1)

spong (32007) | more than 2 years ago | (#38778623)

Apparently the passwords were hashed [...]

I'm not sure that's quite true across the board. According to a blog comment here [dreamhost.com] by Simon Anderson (dreamhost CEO):

Zachary:- 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.

FTP? (5, Insightful)

MichaelSmith (789609) | more than 2 years ago | (#38776741)

If the passwords are used for FTP they should be considered comprimised anyway.

Re:FTP? (1)

Wayne247 (183933) | more than 2 years ago | (#38776881)

Very valid comment, this deserves to be modded up. Since FTP authenticates in cleartext, anyone capable of sniffing the transaction gets the authentication credentials in full.

That's why it's never, ever safe to attach FTP credentials to anything else.

I believe Dreamhost handles this by issuing a separate password for FTP.

Re:FTP? (2)

reve_etrange (2377702) | more than 2 years ago | (#38776941)

I believe Dreamhost handles this by issuing a separate password for FTP.

They should handle it by only supporting SFTP.

I'll see your SFTP and raise you... (4, Insightful)

sakdoctor (1087155) | more than 2 years ago | (#38776995)

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 [ubuntu.com]

Re:I'll see your SFTP and raise you... (0)

Anonymous Coward | more than 2 years ago | (#38777109)

all of the malicious login attempts

fail2ban is your friend.

Re:I'll see your SFTP and raise you... (3, Informative)

MichaelSmith (789609) | more than 2 years ago | (#38777129)

I'll see your SFTP and raise you disabling password authentication entirely, and using SSH public key authentication only.

I do this on my own servers but I don't use plain file transfer at all. Instead I use a distributed version control system (mercurial) and I push to the server. Mercurial lets me define a hook to update the remote copy to the repository tip when new changesets are pushed to it. Working this way I have a full version history at the local and remote end. Additionally I only have to manage the directory tree locally. The remote end is taken care of.

Another advantage is that mercurial hashes the whole repository so if anybody does fiddle with any files, I hear about it as soon as I touch the repository.

Re:I'll see your SFTP and raise you... (1)

reve_etrange (2377702) | more than 2 years ago | (#38777919)

I do this myself, but unfortunately I can't convince my university division's so-called "UNIX admin" to disable remote root logins, let alone password authentication, on our machines. In spite of this it's somehow a "security risk" to run our (computer science) lab's web applications on port 80.

Re:I'll see your SFTP and raise you... (0)

Anonymous Coward | more than 2 years ago | (#38779053)

I can see why they wouldn't want to disable password authentication. It can be a huge pain in the ass. Cost/benefit and all that.

Disabling root logins seems like a "duh", as it's a very minor inconvenience for only one or two people with a good benefit up-side. The port 80 thing is just mind-blowingly goofy.

The stolen laptop problem renders that insane (1)

dbIII (701233) | more than 2 years ago | (#38778075)

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.

Reading comprehenion? (1)

sakdoctor (1087155) | more than 2 years ago | (#38778337)

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.

No, caught out with bad advice instead (0)

dbIII (701233) | more than 2 years ago | (#38778743)

Nobody implied that you shouldn't encrypt your private key with a strong passphrase.

Apart from some guy under the handle of "sakdoctor"?

disabling password authentication entirely, and using SSH public key authentication only

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."

Re:No, caught out with bad advice instead (0)

Anonymous Coward | more than 2 years ago | (#38779165)

Parent suggested using keys, which are usually encrypted with a password. He stated clearly what he meant, and that is to disable password authentication on the SSH server. This does not imply anything in either direction for password protecting the keys. So yes, it is a problem with reading comprehension, or perhaps technical understanding.

Re:FTP? (1)

Grishnakh (216268) | more than 2 years ago | (#38777495)

That'd be nice, but for some reason it still seems to be the standard to support FTP for web hosts. My host, fatcow,com, does so as well. Why, I don't know; I'm guessing it's probably because a bunch of people use shitty website-authoring tools that don't support SFTP. I wouldn't be surprised if MS FrontPage is the big reason; my host supports FP and FP extensions, even though last time I checked, FP is defunct and unsupported, and has been replaced by some other MS tool with a totally different name. But just like some people just won't stop using IE5.5 and IE6, I guess there's other ancient MS junkware that a bunch of home users won't give up, no matter how much MS tries to coerce them to.

Re:FTP? (1)

reve_etrange (2377702) | more than 2 years ago | (#38777953)

Horrifying. Still, it would be easy to use SSH forwarding to keep using an FTP-only client, but I guess the people who know that use rsync.

Re:FTP? (1)

Solandri (704621) | more than 2 years ago | (#38778943)

They support FTP and/or SFTP. As much as I like the idea of forcing everyone to use SFTP, it's really a decision for each customer to make. If you want to only allow SFTP connections, you can.

Re:FTP? (2)

awilden (110846) | more than 2 years ago | (#38777025)

I'm pretty sure it's the same password for both. Inside the control panel there's a popup to assign each user "ftp", "sftp+ftp", or "shell+sftp+ftp" access. But if you choose either of the latter two, you have "disallow ftp" checkbox. Fairly bassackwards in my opinion, but does let you block ftp into your account - one user at a time.

Re:FTP? (2)

trip23 (727132) | more than 2 years ago | (#38777161)

For what it's worth, there's FTPS and FTPES. So you can secure FTP-Conntections since quite a time.

Re:FTP? (0)

Anonymous Coward | more than 2 years ago | (#38777035)

Users have the option to restrict access to SFTP. But this is not the default. Why they allow insecure FTP access at all is beyond me. Are there any FTP programs left that don't know SFTP?

Re:FTP? (1)

Billly Gates (198444) | more than 2 years ago | (#38777327)

Content management software from commercial vendors lack it. I guess they assume you have your own ftp servers in your big corporate office. They forget not everyone has the luxury of 10 t1s for a good network connection and their own IT management and servers in the same building. Most small to medium businesses use an ISP.

Re:FTP? (1)

fnj (64210) | more than 2 years ago | (#38779133)

Are there any FTP programs left that don't know SFTP?

Is that a serious question? If so, how about /usr/bin/ftp just for starters? And I imagine c:\windows\system32\ftp.exe as well, though I don't use toy operating systems myself. Those are by far the most common ftp clients.

Public Relations (-1)

Anonymous Coward | more than 2 years ago | (#38776755)

I wonder if they'll explain this with an image of Homer Simpson on their official blog as well.

Only since last June.. (2, Interesting)

Dynamoo (527749) | more than 2 years ago | (#38776787)

This has been going on since last June [dynamoo.com] . Dreamhost were completely unresponsive to reports that their services were being abused. Hey, it only took 'em half a year to figure out there was a breach..

It got so bad at one point that I recommended that readers of my blog . [dynamoo.com]

Re:Only since last June.. (2)

Dynamoo (527749) | more than 2 years ago | (#38776865)

..darn it, I screwed up the formatting. I recommended [dynamoo.com] that people consider blocking the Dreamhost IP ranges altogether.

Re:Only since last June.. (0)

Anonymous Coward | more than 2 years ago | (#38777003)

I don't see anything that indicates a hack?

I just see spammers who bought Dreamhost accounts to host their spam sites.

Sucks and Dreamhost and any other host should terminate spam sites once notified but it doesn't prove any insecurity and doesn't seem related whatsover with this /. story.

Re:Only since last June.. (0)

Anonymous Coward | more than 2 years ago | (#38777299)

nightmarehost!
Had them for a year and going back to Hostgator for my site soon!

Re:Only since last June.. (3, Informative)

Maestro4k (707634) | more than 2 years ago | (#38777665)

This has been going on since last June [dynamoo.com]. Dreamhost were completely unresponsive to reports that their services were being abused. Hey, it only took 'em half a year to figure out there was a breach..

Probably because that has all the hallmarks of a software PHP vulnerability web-hack of a site, NOT an FTP compromise. I've seen plenty of those, they use some vulnerability to gain access, then upload a file (through the web software) that gives them what's basically a PHP web-based shell. There's no need for the FTP account password to be compromised (and it usually isn't).

All web hosting companies get a lot of that type of attack because their customers don't all update and/or secure their sites properly. WordPress is a particularly popular target.

Re:Only since last June.. (0)

Anonymous Coward | more than 2 years ago | (#38777991)

And this makes it not their problem, how, exactly?

Sites they were hosting were hacked, repeatedly, and they took absolutely no action. I'd think about black-listing them over that, too.

The entire point behind using a hosting provider and not just running your own server is for them to deal with shit like that. Clearly they don't, and clearly they're incapable of keeping their "password database" out of hacker's hands.

And, knowing their level of competence, it would AMAZE me if the "password database" wasn't /etc/shadow, protected by crypt.

Re:Only since last June.. (0)

Anonymous Coward | more than 2 years ago | (#38778477)

So, uhm, customer installs software and doesn't bother about updates and that's the hosting company's fault?

Re:Only since last June.. (0)

Anonymous Coward | more than 2 years ago | (#38778547)

Let me just quote you something off Dreamhost's front page:

DreamHost proudly hosts more than 500,000 sites running WordPress at their core. From bloggers to businesses, WordPress is the swiss army knife of web apps. Weâ(TM)ll install it, keep it up-to-date, and keep you online.

Dreamhost installs WordPress for their users. So, YES, it is DREAMHOST'S FAULT for not keeping it up to date.

Re:Only since last June.. (1)

Rakishi (759894) | more than 2 years ago | (#38778661)

The entire point behind using a hosting provider and not just running your own server is for them to deal with shit like that.

No it's not. It's like saying it's a car rental companies fault if someone steals a rented car and crashes into a school bus. All a hosting provider does is provide the hosting environment, after that it's up to the customer to deal with things unless they pay for some specific service.

Were they hashed? (1)

Anonymous Coward | more than 2 years ago | (#38776795)

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?

Re:Were they hashed? (0)

Anonymous Coward | more than 2 years ago | (#38776885)

Yes, they were hashed, according to the Dreamhost guy responding to the blog post.

-1 hysterical (0)

Anonymous Coward | more than 2 years ago | (#38776963)

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

Re:-1 hysterical (2)

icebraining (1313345) | more than 2 years ago | (#38777437)

Those passwords aren't stored in a database, but in the shadow file.

Not necessarily. SSH can validate the passwords using PAM, and PAM can use a database (e.g. Postgres or LDAP) as backend.

Painless (1)

radcore (2558169) | more than 2 years ago | (#38776841)

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.

Re:Painless (1)

dgatwood (11270) | more than 2 years ago | (#38776863)

I'm not sure what the password for my account was before, and I'm really not sure what it is now. I use an SSL key for authentication anyway, so this doesn't matter much....

What would be really cool would be if DreamHost allowed you to inject an SSL public key into the account for login purposes, and stopped having a password database entirely. Just my $0.02.

Re:Painless (1)

dgatwood (11270) | more than 2 years ago | (#38776901)

Err... s/SSL/RSA/g.

Re:Painless (2)

chimericdream (1680374) | more than 2 years ago | (#38776923)

I disagree that the process is entirely painless. As a developer and reseller, my account has several dozen different sFTP users set up. Each of them required a password change. Easy? Absolutely. Frustrating? A little, but I'm really glad DreamHost chose to play it safe. Painless? Not really, since the process took over an hour and involved me emailing my users to let them know why they couldn't log in with their old user/pass combinations. In all, I prefer having to spend an hour or two changing passwords and contacting people to discovering that my site (or that of one of my clients) has been hacked.

Re:Painless (1)

radcore (2558169) | more than 2 years ago | (#38777131)

If you're reselling to several dozen users, then that would be a different story. I could be totally wrong about the nature of reselling through Dreamhost, but why did you have to individually change their passwords? I was assuming you could've just sent an email blast to your users providing some "explanation."

As opposed to all the legal unauthorised access?? (0)

Anonymous Coward | more than 2 years ago | (#38777221)

or the illegal authorised access...

Conversation probably went like this (0)

Anonymous Coward | more than 2 years ago | (#38777229)

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."

Re:Conversation probably went like this (0)

Anonymous Coward | more than 2 years ago | (#38777577)

"But wouldn't they need to know our salting algorithm for that to be useful?"

Of course, but then the issue depends on whether they rolled their own, which they probably fucked up like just about everyone else who makes up their own hash scheme does? Or did they use a standard one like everyone else which is well known and works well?

Conversation probably went like this (1)

webbiedave (1631473) | more than 2 years ago | (#38777293)

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."

Could this breach affect computers? (0)

Anonymous Coward | more than 2 years ago | (#38777519)

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.

Why a Database of Password? (1)

segedunum (883035) | more than 2 years ago | (#38777619)

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?

Re:Why a Database of Password? (1)

etresoft (698962) | more than 2 years ago | (#38777831)

The massive web hosting companies don't run vanilla Linux. The require custom setups to run hundreds or thousands of sites per server and the flexibility to change servers based on usage.

Re:Why a Database of Password? (0)

Anonymous Coward | more than 2 years ago | (#38778403)

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?

Perhaps they wanted the ability to authenticate logon requests, duh!

Didn't they stored passwords crypted?! (1)

hubertf (124995) | more than 2 years ago | (#38778555)

As the Unix does since ... 1969?
Seriously, WTF?!

  - Hubert

Re:Didn't they stored passwords crypted?! (0)

Anonymous Coward | more than 2 years ago | (#38778863)

Unix crypt has been trivially breakable since 1985. As others pointed out, they expired all their passwords right after they discovered the breach.

Love Dreamhost (1)

seandiggity (992657) | more than 2 years ago | (#38778849)

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.

I think they do store clear text passwords (1)

Anonymous Coward | more than 2 years ago | (#38779259)

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?

argh! (1)

jthomp (1266534) | more than 2 years ago | (#38779693)

What sucks about this is I set up a DH account the day before this happened x.x
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>