Password Security Improvements

Hi DreamHost Team.

Please can you explain this ?

After reading this I as many others it seems are now looking at other hosts.

Wow. Just wow. Thanks zoro for pointing this out, have you created a ticket yet?

No didn’t create a ticket as I saw that the dreamhost staff come here at least once a day.

I’d be surprised if they haven’t already read the forum post. (but I’m guessing are just ignoring it).

Just FYI, if you change your password in a shell, as opposed to through the panel, DH staff won’t have access to your password. From what I have been able to piece together based on previous discussions, when you change your password through the panel, DH will store an encrypted copy of that password in their own database, then use the previous password on file to log in to your account and change it to the new password. Changing the password yourself bypasses the middle step.

I think that’s logically impossible. Because, what if you first change your password from the shell, and then, a few days later, change your password from the panel. Dreamhost would not then be able to “use the previous password on file to log in to your account and change it to the new password” because the previous password which they have on file would already be out of date.

The panel robot won’t need your old password to change it. It will re-write the file containing your already hashed new password. So change it from the shell and you will have a secret password not in a database. FWIW I don’t think dreamhost can see webserver user passwords anymore, I believe they are now stored in a non retrievable encrypted form. Took too long and an “incident” for that to happen tho.

The incident noted above however is an EMAIL, and that is a different story, it looks very much like those are still stored in plain text. Maybe they think that’s OK because without SSL/TLS email protocols send plain text passwords. Be interesting to hear a courts opinion tho if someone sued for breach of privacy.

The idea is the same, even if the exact implementation details may be off. There are other ways of achieving the same result.

$ man passwd […] DESCRIPTION The passwd command changes passwords for user accounts. A normal user may only change the password for his/her own account, while the superuser may change the password for any account.

I doubt they have a different system for different types of passwords. They all go into the same (hopefully encrypted) database on the way to the server when changed via any DH-provided interface. From what DH has revealed, passwords are encrypted in that database, not hashed. That may have changed though; I haven’t kept up on this issue.

In the US, emails older than 180 days are not subject to the same privacy protections. They are considered database entries, just like call records and the like. See So, depending on which emails were accessed, then there may be no claim. And it doesn’t look like the emails were actually read, just the account accessed.

I really doubt any customer could claim a reasonable expectation of complete privacy given clause six of the ToS: