From DreamHost
Jump to: navigation, search

Here we attempt to group the interaction between the many passwords on one's Dreamhost account.

Where to change passwords

Changing My Password

You can change any of your account passwords (shell/ftp users, mailboxes, vpn users) by going to the Users > Passwords area of our web panel. From there you can have your passwords emailed to you, have us generate a new random password for you, or change your password (if you have the old password).

For security reasons, we suggest that passwords:

  1. have at least 8 characters, at least two of which are numeric
  2. not be based on any recognizable words
  3. contain no personal information that could be linked back to you
  4. Please note that our password checker is very stringent (no English words or

passwords derived from english words), so it may be easiest to just have us generate a random password for you!

What kind of password do you suggest I use?

My password is easy to remember, but I'm not certain it's very secure. What would you recommend I do to make it more secure? How do I change my password?

Why do I need to worry about my password?

Your password is the first line of defense to protect your account from any unsavory characters who may wish to do your site harm. Without a well thought out, secure password, the contents of your site are at risk. What can someone do? They could potentially read your email, send mail from your account (which would show up under your name for whoever reads it!), delete your web site, or even make minor or major alterations which could ruin your site's reputation. Despite all the stories of computer intruders cracking tight security on the 'net, the majority of intrusions are due to easily guessed passwords.


There are a few rules to keep in mind when you create a password:

  1. Never use your username as your password, or even a portion of it.
  2. Never use the same password twice.
  3. Combine letters and numbers to make your password harder to guess.
  4. Mix upper and lower case letters to ensure tight security.
  5. Do not share your password with anyone.
  6. The longer the password, the better. We recommend at least 6 characters.
  7. Try not to use words from the dictionary in your password.

With these tips in mind, you can create a difficult to guess password at ease. It may be a bit more difficult to remember, but it's worth it to maintain the integrity of your account.

Password storage at DreamHost

User passwords used to be stored in two places:

  1. in a hash format that cannot be reversed on the servers
  2. a symmetrically encrypted version of the password is stored in a very secure location as well. This is only used to help increase the efficiently of support and would not be reversible without knowledge of Dreamhost's algorithms.

However, after a data breach in January 2012, DreamHost reportedly changed the second storage location to use a one-way hashing function or removed the storage altogether. Theoretically, setting or changing passwords in the Panel should now be quite safe, but if you are extra paranoid, and want to avoid any possibility of having your password stored anywhere other than the server, you can simply change your password from the shell with the passwd command. Thus the only record of your password will be in the hash file on the server.

Equivalent sets

Changing the password of one member of the below sets automatically changes the others of the same set. Some sets have only one member though.

Summary of some of the most important passwords

There are basically four basic accounts involved for every website, with the possibility of others. No usernames or passwords should be recycled across accounts.

These accounts are ordered from least to most likely to be accessed which, ironically and unfortunately, is roughly proportional to the severity of a potential breach. Each level entails access to all levels below it except for #4.

For each type of account, details are given for the ideal length and characters to use for the username and password, any vulnerabilities associated with the account, and a worse-case scenario in the event of a security breach, i.e. an adversary obtains your username and password for that account.

  1. database account: this should rarely be needed except for maybe development work. The username and password should both be long and complex. There's no reason to make either easy to remember or even type.
    • username: ≥12 from [a-z0-9_$]
    • password: ≥15 from any printable characters
    • vulnerability: password can be viewed by other users on the same machine when passing the password as an argument when invoking mysql-p should be used and the password entered at the subsequent prompt. Web-based interfaces should never be used unless they are routed through a secure connection such as https or an ssh tunnel.
    • connection: command line from shell, ssh tunnel
    • breach: all data stored in the database including all usernames, email addresses, hashed passwords, and possibly PII. An adversary could also set a username or password such that s/he could log into a web app, upload a script-based shell, and take control of the shell account.
  2. shell account: this account should also rarely be needed. It is useful when installing new software, viewing log files, and other low-level maintenance work.
    • username: ≥6
    • password: public key authentication (preferred if the private key is adequately protected) or ≥12 from ⊇ [a-zA-Z0-9+/]
    • vulnerability: few if connections are made over secure channels and public key authentication. Keyloggers may capture passwords on compromised systems
    • connection: ssh, sftp, scp, or other secure communications channel only
    • breach: as database connection information is stored at this level, all data in database information would be lost. In addition, viruses, malware, and other unpleasant garbage could be added surreptitiously to the site to make it dangerous for all future visitors. Depending on the severity of the breach, changes made to the site by an adversary could result in a violation of the Terms Of Service Agreement with Dreamhost which would lead to a complete loss of all sites hosted under the hosting account.
  3. Dreamhost panel account: this account is used for higher level maintenance such as (setting up|installing|removing|modifying) new software, domain names, databases, email addresses, discussion lists, statistics reporting, etc. as well as requesting assistance from Dreamhost Support.
    • username: email address or Dreamhost-supplied WebID which is derived from email address
    • password: ≥12 from any printable characters
    • vulnerability: Email account is the single biggest threat due to the password recovery mechanism which will forward a working key to get into the panel with no questions asked. If possible, set email address to be one not used often or one which is very secure. Other than that, mostly keyloggers or other malware on the machine used to connect to the panel.
    • connection: https only. There is an option which can be set under Edit Profile > Preferences: Require email confirmation before allowing a new IP to log in to your web panel (more secure). Enabling this option is highly recommended as it limits the ability of an adversary to use compromised credentials but assumes that the associated email account has not been compromised as well.
    • breach: everything, complete disaster.
  4. Application admin account: this account is full permissions account for WordPress, Joomla, or some other web-based application.
    • username: ideally avoid (admin|administrator) because they are usually defaults and most web apps have no protection against brute-force attacks. It's better to change the default admin username to something else and possibly create a more limited account for daily content creation and moderation if the app has that level of granularity (see breach section and optional accounts sections for details).
    • password: ≥12 from any printable characters
    • vulnerability: this is the only account which can not be authenticated over a secure channel ∴ this set of credentials should be assumed to be disposable and/or compromised from the beginning. It's like leaving a spare key under the doormat or using a combination lock to secure a bicycle. Usually you'll be fine, especially if you don't do it often, but if an adversary really wanted to attack, it would not be very difficult.
    • connection: http only ∴ credentials are passed in cleartext. The only way to avoid this situation is to set up a local mirror and open an ssh tunnel to forward database queries to the remote database. Unfortunately this will result in slow queries which can make some applications frustrating to use. Another way is to create an authenticated cookie either through a local mirror or through a slow but secure ssh tunnel to the live database, then switch to normal http for the rest of the session. It's still possible to capture an authenticated cookie by listening in over unencrypted channels, but the ability to use the cookie on another computer depends on the sophistication of the app (i.e. if the app is also encoding your browser type, IP address, and other identifying features, it will be harder to reuse the cookie elsewhere, but few apps do this).
    • breach: full admin rights as granted by the application will be gained by an adversary if an admin account is breached. Some apps, such as WordPress, allow administrators to edit plugins and themes from within the application which is basically an open door to the database and shell account, but not the panel. If possible, most accounts should be set at a level below admin, such as Editor or Author in the case of WordPress, with an admin account reserved for actual application maintenance such as upgrades or changes to themes and plugins.

See also