7

The 'root'@'localhost' MySQL account can only be accessed by someone currently on the server hosting the MySQL server.

Assuming that only the person or persons who are in charge of the MySQL server even have the password to ssh in, and given that the server is hosted on an internal network so that you can't ssh in from outside, is there any reason to put a password on the MySQL server for 'root'@'localhost'?

Reasons not to have a password:

  • Managing passwords in a volatile system is incredibly cumbersome, with each additional password increasing entropy in the system.

  • If a password gets lost it can cause a lot of headache.

  • If someone has ssh'ed into a machine, and if the root password for the machine is the same as the user they logged in as, they can just start up MySQL without a password anyway.

  • If the server is on a local network, and your only concern is how much damage someone can do to your MySQL server, someone logging in as root while ssh'ed into the server is the least of your concerns. They could just physically take the hard drive(s), or wreck the machine in any number of ways.

So, despite these reasons stating having a password in this situation would just make things harder without any real benefit, is there a compelling reason to give one to 'root'@'localhost'?

  • 1
    SQLi that runs shell commands? – schroeder Jul 6 '15 at 22:11
9

The first rule of 10 Immutable Laws of Security Administration written by Scott Culp, is a good law regarding your situation:

Law #1: Nobody believes anything bad can happen to them, until it does.

Even though your server is only accessible from within your local network, try to think of how many computers or servers are connected to that internal network. Pivoting from one computer to the other is part of a hackers job, and having perimeter-only security will save you from nothing as soon as one of the employees are victim to a spear phishing attack, and click that link in that email.

Another possibility is, what happens when someone can get a shell using a vulnerability in your website? The person can then try to access and run MySQL-commands from the shell, and in the worst case drop/dump your entire database?

Yes, managing passwords in a multiuser environment is hard, that's why software such as KeePass and LastPass offer Multi-User databases, such that multiple users can have access to the same keychain and same passwords.

My recommendation is, secure it with a strong password, because it's probably not going to be as much of a hassle as you think, and it could potentially stop your database from getting leaked or dropped. The more friction you create for potential hackers, the better!

Be proactive!

  • Great answer thanks - I use KeePass although I've not heard of the keychain for multi-users you mentioned...how do I use that? – Bendy Jul 7 '15 at 7:43
  • @Bendy follow the KeePass-link in my answer, or click here. That site should be a good starting point for further investigation. I have no real experience with KeePass myself, so I can't tell you the specifics. – Mrtn Jul 7 '15 at 7:45
  • Thanks @Mrtn, I'll read through - if you don't use it yourself do you recommend something else? – Bendy Jul 7 '15 at 7:55
  • @Bendy I don't use a password manager in the setting described by the asker, so I can't really recommend one over the other. That question would however be a better fit for Softwarerecs.SE. This for example – Mrtn Jul 7 '15 at 8:01
2

Consider this -

Someone pops a shell on your box via a vulnerable webapp and they want to dump all databases however they can't because they're only limited to the db user that's listed in your config file (or something related). They think they're stumped until they attempt to log into MySQL as root, and they soon discover that there's no password. This leaves the attacker striking the jackpot because of something as silly as you not giving the MySQL root user a password.

It's good to have a password for everything it's applicable to, regardless of what you might think can't happen. There's more scenarios where not having a password for root is bad, but you get the idea.

0

Always Plan Ahead. It may seem like a pain to manage the passwords, and like you mentioned, they might SSH into the machine in the future.

If someone can contribute the exact statistics that would be great - but most security threats come from inside your organization, not outside. Leaving no password on your MySQL server is just like leaving a printed copy in the break-room. If you are okay with that, then you really don't need a password. If the databases have any information that you may not want in that coffee table book, take the extra couple of steps and secure your data. A few years, or maybe even months from now, you can buy me a coffee to thank me for doing so!

0

I suggest you define two users: 1. root@localhost with full admin rights AND complex, long password 2. work@localhost only allowed to access the tables (grant) he is supposed to with the rights (grant) adapted to normal operations (create, change row). This user should be used by all scripts around.

Admin is too powerful to stay unprotected.

0

If you were using a single root password / su, one approach would be to use that same password for MySQL. Then if anyone started letting other users on the server, they're not giving them access to MySQL without realizing it.

That's not truly forward-looking as the sudo model (multiple admin accounts) is generally considered preferable. For that, you'd need to start creating multiple admin users in MySQL.

If that became too complex, you could avoid managing passwords separately in MySQL by setting up PAM. Both MySQL and MariaDB have PAM modules. (You still have to create the users though. Also for local users (pam_unix), they require that you grant MySQL access to /etc/shadow, because the MySQL pam module does not include an SUID-root helper :(. Apparently other PAM methods have similar requirements too).

  • That means that stealing your mysql root password gives access to the machine root! – Ángel Sep 30 '15 at 23:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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