Even if you do all of that, there may still be problems if your adversary has an authenticated cookie because it appears that you have not changed the salt used to encrypt that cookie. Also, if your adversary has changed your config file to include another email address, then it would be easy to gain access again. Or if you have used the same password as your email account, your adversary may have access to your email account as well which represents a backdoor to your account.
From my own security notes to myself for Dreamhost sites which do not make use of [font=Courier]https[/font]:
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.
[*]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 [[font=Courier]a-z0-9_$[/font]]
[*]password: ≥15 from any printable characters
[*][b]vulnerability:[/b] password can be viewed by other users on the same machine when passing the password as an argument when invoking [font=Courier]mysql[/font] ∴ [font=Courier]-p[/font] 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 [font=Courier]https[/font] or an [font=Courier]ssh[/font] tunnel.
[*][b]connection:[/b] command line from shell, [font=Courier]ssh[/font] tunnel
[*][b]breach:[/b] all data stored in the database including all usernames, email addresses, hashed passwords, and possibly PII.
[*]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.
[*][b]password:[/b] [url=http://wiki.dreamhost.com/SSH#Passwordless_Login]public key authentication[/url] (preferred if the private key is adequately protected) or ≥12 from ⊇ [[font=Courier]a-zA-Z0-9+/[/font]]
[*]vulnerability: few if connections are made over secure channels and public key authentication. Keyloggers may capture passwords on compromised systems
[*][b]connection:[/b] [font=Courier]ssh[/font], [font=Courier]sftp[/font], [font=Courier]scp[/font], or other secure communications channel only
[*] [b]breach:[/b] 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.
[*]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
[*][b]password:[/b] ≥12 from any printable characters
[*][b]vulnerability:[/b] 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.
[*][b]connection:[/b] [font=Courier]https[/font] only. There is an option which can be set under [font=Courier]Edit Profile[/font] > [font=Courier]Preferences[/font]: 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.
[*][b]breach:[/b] everything, complete disaster.
[*]Application admin account: this account is full permissions account for WordPress, Joomla, or some other web-based application.
[*] username: ideally avoid ([font=Courier]admin[/font]|[font=Courier]administrator[/font]) 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).
[*][b]password:[/b] ≥12 from any printable characters
[*][b]vulnerability:[/b] [i]this is the only account which can not be authenticated over a secure channel[/i] ∴ 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.
[*][b]connection:[/b] [font=Courier]http[/font] only ∴ credentials are passed in cleartext. The only way to avoid this situation is to set up a local mirror and open an [font=Courier]ssh[/font] 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 [font=Courier]ssh[/font] tunnel to the live database, then switch to normal [font=Courier]http[/font] 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).
[*][b]breach:[/b] 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.