It’s possible, but not easy. The best way I’ve found is use a single subdomain for all DB access and make it obscure as possible (8-12 random characters) because it seems that DH’s automatic phpmyadmin backdoor won’t be useful if you don’t know the DB domain. Unfortunately, most people just name it [font=courier]mysql.example.com[/font], so for the vast majority of DBs on DH, it’s pretty easy to get a crack at a dictionary attack.
You can see further discussion here and here and here and here.
[quote=“kelly7552, post:9, topic:59279”]So in summary we need to pick really secure passwords for 1) Panel 2) mysql users and 3) mysql databases?
I’ve summarised my thoughts on DH passwords here.
There’s a really easy way to reuse passwords safely. My technique is a bit more involved than this, but the idea in brief is to add unique salt to your password. You can do this safely by writing down the salt + obfuscating garbage. For example:
example.com = pgd%i9@8$43q
mysql.example.com = hH7Ic#98eca*
email.example.com = Cvet%783te(t
In the above list, your obfuscating garbage may be the first 3 characters and last character, so you just ignore those. Then you just add it to your password. If your password is [font=courier]weakPassw0rd1[/font], then your unique salt + reusable password for [font=courier]example.com[/font] would be [font=courier]weakPassw0rd1%i9@8$43[/font]
You also don’t have to worry about an adversary finding your list of salt because you never write down a) the base password, b) the method of distinguishing between salt and obfuscating garbage, and c) your method of combining the base password and salt.
All you have to do is remember a, b, and c above, which is not hard to do, and you’re set. It also helps to have a system which can reproduce your salt in case you lose the list. If not, make sure you keep multiple up-to-date copies in multiple locations, perhaps under version control in at least two locations, because if you can’t regenerate the same salt and you lose your list, you’re screwed.
Note that the shortcut of just adding the name of the service, or an abbreviation thereof, to your reusable password is not advised. In the above example, [font=courier]weakPassw0rd1examcom[/font] is not good because you can not trust the service to store your password in an irrecoverable format (which DH itself used to be guilty of). If an adversary gains access to your password for one service, it’s too simple to guess what it would be for other services. Hence, the salt needs to be opaquely tied to the service by means of the list above.
If an adversary were to obtain both your list and an example of your password, then you would have a problem, but the likelihood should be small.