Passwords

From DreamHost
Revision as of 07:33, 23 January 2012 by Myqlarson (Talk | contribs)

Jump to: navigation, search

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

Password storage at DreamHost

User passwords are 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.

Therefore, if you do not want the symmetrically encrypted version stored you can simply change your password from the shell with the passwd command. The 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.

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