On Friday DreamHost reset all of their customers “FTP/shell access passwords” after they had unauthorized activity within one of their databases, the situation is discussed in blog posts on DreamHost Status blog and the The Official DreamHost Blog!. Since then there have been questions and confusion as to whether DreamHost only stores passwords in their hashed form. While we have no way of knowing if the database they detected unauthorized activity stored non-hashed password there is no question that they store non-hashed passwords in their systems. It’s fairly easy to see that DreamHost is doing this and we will show you how you can check this for yourselves at the end of the post.
The fact that they stored passwords in a non-hashed form has been discussed for many years and DreamHost has so far has decided that insuring that they were follow proper security practices by only storing password hashes wasn’t necessary for whatever reason. It’s then not all to surprising that they had this most recent security incident and the other apparent security incidents they have had over the years. For some time we have listed DreamHost in our list of web hosting providers with security issues due to them storing non-hashed passwords.
One possible reason for some of the confusion from DreamHost is that they don’t understand the difference between encryption and hashing, in which case it they probably shouldn’t be handling the security of a website, much less that of a major web host.
While discussing DreamHost’s security it is also worth bringing up the fact that both of those blogs are running an outdated version of WordPress, 3.2.1. They are also are running an outdated and now unsupported release of MediaWiki, 1.16.5, on a portion of their website (so are a number of the websites of web software). In a message that was forwarded to us while we were cleaning up a hacked website for client recently, DreamHost had told them that they should make sure to keep web software running on their website up to date. Obviously DreamHost don’t feel it is important to follow the advice they give to their customers. If you want to see when websites are running out of date version versions of WordPress, MediaWiki, and other software check out our Meta Generator Version Check web browser extension for Firefox and Chrome.
Considering DreamHost’s questionable security practices we would recommend that people avoid using their services until they have fixed these lapses in their security. We also don’t think that WordPress should be recommending them or describing them to be one of the hosts that “represent some of the best and brightest of the hosting world”.
What is Hashing?
You can think of hashing as one way encryption. To produce a hash you run a hash function on a specified value, in this situation it would be the value being set as a password. For example, using the MD5 hashing function the hash for the password value “password” would be “5f4dcc3b5aa765d61d8327deb882cf99”.
Unlike encryption, hashes are not meant to be decryptable and ideally you wouldn’t be able to determine what the password value was if you gained access to its hash. This is why it is important to store passwords as hashes. If they are stored them in a non-hashed way someone that gains access to them could easily use the passwords to log into your account, which has happened previously after web host’s were exploited, or if you use the same password on different systems they could potentially gain access to those as well. There are a number of ways to determine the underlying value of passwords hashes, so systems using hashing for passwords need to insure they follow best practices including making sure they use salts.
So how does a system know that the correct password was entered during a login attempt if they only have the hash? The answer is that when the login attempt is made the password you enter is run through the same hash function and then compared with the stored hash of the password. If the two are they same the login attempt will succeed. If you entered the wrong password the hashes would be different and it would fail.
If passwords are only stored in hashed form there will be no way for a provider to retrieve the password from storage that for you. The only instances where they could show you the password would be when they are generating a new password for you or if they show you the password in response to you entering it.
The most common place to see that passwords are being stored in non-hashed form is on pages for handling a situation where you forgot your password. If they can show or send you the password it means the password in being stored non-hashed in their systems. With web hosts we also sometimes see that passwords are visible somewhere in the control panel for the websites.
Spotting Non-Hashed Password Storage at DreamHost
From the DreamHost’s homepage click the Panel link at the top and then click the Forgot password link. That page currently looks as follows:
If the password were only stored in the hashed form they wouldn’t be able to email you your password because they wouldn’t know what it was.