The most fundamental rule of database use is to give each user or group only the minimum permissions necessary to do what needs to be done. You wouldn’t let strangers walk into your house and kick back in your bedroom and read your diary—so why should you give them the option to do analogous things on your site? It’s a little more work to manage multiple users and make sure all the permissions are set to the right levels at all times; but if that tiny pinprick of pain can prevent a massive infection later, you’d be extremely foolish to refuse this simple but effective prophylaxis .
Besides the threat of malicious/experimental outsiders, setting the correct permissions can protect you from your coworkers and yourself. Insiders have been known to cause massive problems through disgruntlement, ignorance, momentary brain freeze, or a combination of motives. You do not want to have to cope with the consequences of a fired employee’s parting shot or a new intern trying out the DROP database command just to see what happens.
A typical database permissions package might be something like:
✦ Web visitor: SELECT only
✦ Contributor: SELECT, INSERT, and maybe UPDATE
✦ Editor: SELECT, INSERT, UPDATE, and maybe DELETE and maybe GRANT
✦ Root: SELECT, INSERT, UPDATE, DELETE, GRANT, and DROP
DROP in particular is the nuclear bomb of SQL because it allows you to blow away an entire table or database with a single command. Someone’s got to have the ability, but heavy lies the tiara of responsibility on the head of the root database user. Use the power wisely, grasshopper.
In many databases, including MySQL, passwords are encrypted using a different algorithm from system passwords (and, of course, they are typically stored in entirely different locations). Even if one is crаcked, the other is not necessarily vulnerable. This assumes you take the time to set permissions correctly, pick good passwords, and usually employ a special command to insert usernames and passwords correctly into the grant table (as opposed to inserting them like other data).
Database usernames and passwords should not be identical to system usernames and passwords. Never, ever, ever set any database password to the root system-user’s password! If crаckers should happen to get into your database via Web scripts, you don’t want to offer them the key to the whole system.