Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

When installing a web application where a single user is used to talk to a single database (say MySQL, but this could apply to other RDBMSes also), you often have a sequence of events such as this:

CREATE DATABASE wordpress CHARACTER SET utf8;
GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'localhost' IDENTIFIED BY 'hunter2';

Some guides suggest using a different username to the database name, where others suggest using a different name, such as 'appuser' for the user, and 'app' for the database name.

Are there any obvious technical downsides to using the same name? Is there anywhere you're likely to create confusion by doing this?

Edit: I'm aware that this is questionable security practice, and you should name your databases fhqwhgads and your user flobadob; however, (a) obscurity is a questionable tool, and (b) this is the example every webapp gives in their documentation.

share|improve this question

3 Answers 3

up vote 1 down vote accepted

The downside of using the same user name as the database name is simply that it's far too obvious. If you have a look at access logs you will see attackers regularly try that combination and if you get the name right you're already part way in. Other than that it makes little difference what name you use, although there is something to be said for not using dictionary words either.

share|improve this answer
    
If you've got the username, but there's a strong password still to beat, your "part way" is within epsilon of the start. –  womble Jul 23 '11 at 2:00
    
@womble, if you don't have the user name you need to find that before you can even begin on the password, so it really is quite a bit of a head start. –  John Gardeniers Jul 24 '11 at 21:49

I think the downsides are not at a technical level, but more of an administration and/or security level. You could think along the lines that usernames == database name is simple for administration and knowing what accounts access what databases, but it also makes it easier on an intruder to be able to easily guess at valid account names with a better ratio of success. Typically I suffix the account with the purpose and application. Something like _wp would reduce the intuitive access and yet still be visible for a database administrator to quickly determine the nature of the account.

share|improve this answer

Obfuscated databases provide about 15-30sec of defense in the event of a compromise and about 1234783562387561235 hours of frustration.

I'm of the opinion that you tie the role in to the username. Something like:

app_role

Or:

wordpress_www
wordpress_dba
wordpress_cron

If I ever see a wordpress user, I know something's not right. Using the *_dba convention helps drive home the point that web users should not own database objects, only the *_dba's should. For users, you just use their site username. Simple conventions like this make administering permissions easy, especially when coupled with SCHEMAs.

Here's a sample project that I'm working on that does exactly this:

https://github.com/sean-/flask-skeleton/blob/master/sql/create_roles.sql

https://github.com/sean-/flask-skeleton/blob/master/sql/perms.sql

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.