Restrict domain access to phpmyadmin


hi all,
just wondering about a couple of things that have me baffled. The first is, how do I stop being able to access phpmyadmin using the domain name?

I find it scary to think that someone could eventually stumble upon this domain name, and then be prompted to enter a username and password.

Also, I have removed user access to some of my db’s through the dreamhost UI, yet when I access phpmyadmin, the username and password that I just removed, still allow access.

Is there any reason why this would be happening?



When you go to do you still see the user names listed?

As for the first issue, do you ever intend to go in via phpMyAdmin for yourself?


Funny you should mention that! I’ve been ranting about this for quite some time, but no one seems to care. There’s nothing preventing repeated attempts to access your database, or any database at Dreamhost, save a strong password. Nevermind that you don’t ever use phpMyAdmin, it’s there by default on every account, pointing at every database. Fire up that password dictionary and start your attack.

Anyway, you can ask the kind folks in Support to disable access, but you’ll have to talk them into it. The last time I requested this, I got the following reply:


I use it a lot when I’m debugging sites for people, actually. It’s much easier than explaining the mySQL commands via command line. It’s certainly useful if you’re using any of our One-Click installed apps.


There’s nothing wring with phpMyAdmin per se. You set it up locally and connect through an ssh tunnel and you’re fine.

There is a problem with phpMyAdmin being set up on every domain by default. It’s a door to your database that doesn’t need to be there. Anyone can try a dictionary attack on it to get in, and fairly rapidly at that since there’s no restriction on how many times you can try to log in. And it’s also a security risk as most domains are not running over https, which means when you do use DH’s phpMyAdmin default setup, you are passing the key to your database over teh interwebs in cleartext.


Personally I’d rather start forcing people to use better passwords. You can dictionary attack my sites all day long, but that won’t get you in. The way we isolate DB users via phpMyAdmin, and how you don’t use the same username/password for that as you do for SSH, makes it feel lest risky to me. The worst case scenario is you get into one DB and mess it up. If you’d hacked into my SSH, you could see my config files and get into the DB anyway, and possibly panel (if you’re one of those people who uses the same password all over, a sin I have been guilty of myself).

Don’t get me wrong, though, we certainly could make things more secure.


Yes, and while you’re at it, why not install a few other doors on every domain that people may or may not use, and ask them to use better passwords for them as well?

You have an astonishing approach to security.


Which is probably why I’m the WP expert, not security :slight_smile:

I (personally) think web security depends one three things: The user, the software, and the host. Certainly we should beef up our end, which is why I said we could make things more secure. But at the same time, I think educating the end users on what safety is wouldn’t go amiss. How many people have no idea what a dictionary attack is, and why that’s (part of) why you shouldn’t use ‘words’ as passwords unless you’re using passphrases.


You can think whatever you want. The fact is, creating paths of access which may or may not be used by users, then sitting back and saying it’s up to them to create unique, strong passwords for all of them to keep their data secure, is not security.

If that were the case, then why not open all the ports on your servers? Throw them all open! Why not?

The reason why is you close everything first. Then, only if you absolutely need to, and with great care, caution, and safe guards, do you open only the absolute minimum needed to get the job done.

The fact is that people do recycle passwords. You can educate all you want, but they will always do it. And when they are sending those over the interwebs in cleartext, with no minimum time between tries, and no maximum number of tries before lockout, you are just asking for an attack.

Even a weak password over ssh is better than a strong password over http to phpMyAdmin on DH. At least the password is encrypted and there’s a long enough delay between retries that a dictionary attack becomes painfully slow.


The plain fact is that the greater majority would rather have phpMyAdmin enabled. Shared hosting is all about the needs of the many and not the needs of the few. When you are on shared hosting you should be use to getting what everybody else has and take reasonable measures to secure your website and databases. I have used other shared hosting providers and they have it enabled by default as well. At least DH is willing to disable it for you if you ask. Good luck with that in other places. It is a standard people expect under shared hosting if mysql is provided. If you are more security conscious and want more control over every aspect then obviously a shared hosting solution (with the inherent security concerns that come with it) is not for you.

If your site is compromised due to a weak password it is no fault but your own. I actually had one of my user accounts compromised due to the same reason. Was I surprised? No, because I had a very weak password for that particular account. The buck has to stop somewhere as far as accountability. If you are a really security conscious person you would be use to having very strong passwords that are not recycled. Having phpMyAdmin enabled by default would not concern you overly much to begin with because a successful brute force attack like you spoke of would be highly unlikely.


Sure, give them the choice with a proper warning of the risks involved. But you have not addressed the fundamental problem that opening multiple points of access by default is not an inherently secure method. If you expect Joe Blogger to keep those points of access secure, then you might as well not even put a password on them.

Where are these warnings of the risks? Not in the Panel. The wiki is not much better. The minimum length for database passwords is six characters. Secure? No way.

Am I worried about my databases? Not as much as I used to be, but it took me some time to realise the risks involved. I put it all together in the wiki to save others the time and investment in figuring it out on their own.

You can bet that each of my database usernames are all unique 12+ random characters, and passwords are even longer. Even the subdomain used to access them is a long string of random characters rather than or something like that.

But still, it’s just a matter of time. It’s a cat and mouse game. There’s no lockout or timeout period when attempting to access DH databases through phpmyadmin.

If there’s no issue, then why bother limiting direct access to the databases to DH-only IPs? Why not get rid of that as well, because as long as phpMyAdmin is enabled by default, that renders the whitelist essentially worthless.


I didn’t mean that this isn’t an issue. It is but not for the majority of DH users. I think having phpMyAdmin disabled by default would cost the company more in terms of tech support tickets on where is it/why it isn’t turned on/how do I turn it on, etc (since 99.999% of the average DH users do not even care to read the wiki or do a message board search) versus the relatively few who would have wanted the feature disabled by default. You just have to face facts that the greater majority will not want (or even know how) to use command line by default. Its an ease of access issue really. They have to weigh level of security versus that. You can’t please everybody but you can probably please the greater majority of them. To have what you want you need a service that caters to the more tech inclined vs the average joe. You get what you pay for.

I think DH is simply being practical about it. Businesses such as this do not cater to the minority like that. I understand that its one more possible point to exploit but the end user taking personal responsibility with the strength of their passwords and host masks would drastically reduce that possibility.


[quote=“Ryo-ohki, post:12, topic:58618”]
…the relatively few who would have wanted the feature disabled by default. You just have to face facts that the greater majority will not want (or even know how) to use command line by default. Its an ease of access issue really. They have to weigh level of security versus that.[/quote]

Doesn’t matter if it’s enabled or disabled by default. The point is, as OP pointed out, not everyone should be forced to protect a door to their data that they don’t want there. Allow them to disable it.

Using phpMyAdmin securely does not require the command line. It can be installed locally and access the database through an SSH tunnel. MySQL workbench can create the tunnel itself. And if DH wants to host phpMyAdmin for everyone, then they should do it over HTTPS over their own domain as they do with the panel, webFTP (or whatever its called now), and pretty much every other web interface to your account that DH offers. phpMyAdmin is pretty much the only door to your account which DH enables by default which is not run over HTTPS by default.

Now combine that with inadequate warnings in the panel over database usernames and passwords (before I knew better, I thought I was supposed to use my shell account credentials!) and the incredibly weak password requirement of a minimum of six characters (even though DB passwords are generally saved in a file somewhere and not remembered), then it’s extremely easy to start a distributed dictionary attack against the database behind every domain hosted at DH. With only six characters in the password, and a high likelihood that the password is the same as the user’s password or the panel password, it’s no wonder that people complain about compromised accounts so often.

Try it. Just search for ‘hosted on dreamhost’, and pick a random domain. The just add /dh_phpmyadmin/mysql. + the and viola! There’s the door. This means that the Allowable Hosts whitelist in the panel gives a false sense of security because it’s worthless if you use the default settings. Any warning about that? No. If you are like I was, then you would assume that the whitelist should help keep your database secure from outsiders. It doesn’t. I just tried two random domains after searching for ‘hosted on dreamhost’ and both used default settings.

The only way to give yourself an ounce of protection, short of getting DH Support to begrudgingly disable it is to use an obscure subdomain for all of your database connections rather than the default of mysql and suchlike. A random string of 8 - 12 characters is a good start. Even if you do find someone at DH who can figure out how to disable it, the method they use is fragile. If you are moved to a new server, add a new domain, whatever, then your block is gone. I learnt this the hard way! After having it blocked and assuming I was safe, one day I checked by chance and there was no block! It turns out that it was because I had changed the database subdomain or something like that.

Do I even need to mention the fact that logging into phpMyAdmin is accomplished through HTTP Basic Authentication?

It’s not simply an issue of, oh well, most DH users are simpletons so you just have to accept that everything will be insecure to maintain ease of access. No. It’s not that. The problem is that the system set up by DH is inherently insecure. It’s not about dumbing things down. It’s not about ease of access. It’s about design.

I predict that we’ll just have to wait for a catastrophe. Just like the passwords fiasco. People, including me, pleaded for years to stop storing our passwords in a recoverable format. Many people claimed the same thing. Oh, we need it to provide better support, or too many people forget their passwords, blah, blah, blah.

Does DH store passwords in a recoverable format now? Well, probably not. Why? Because their design was flawed an their password database was breached.

It’s a design problem. DH, your design is wrong!


I’m with bobcat on this one. I understand everyone’s argument on this. However, out of all of the other configurations a shared plan customer has control over, disabling this “feature” should be one of them.

Just because there’s only been a handful of requests to have this functionality, doesn’t mean it isn’t wanted by many more.

I usually, as well as many others, refer to the forum to seek out these more [advanced?] topics. So someone looking into the same issue, could see this thread and say screw it, knowing that the Dreamhost staff doesn’t really care to give this any attention.

If anything, make it a One-click Install. I don’t like the idea of being forced to present a GUI to the outside world if they discover my DB domain name(s); strong passwords or not.

Having something enabled by default (such as phpMyAdmin), beyond my control, in itself is a concern to me.

Take away ammunition from a potential intruder from “attempting” to gain access to my data source.