0

In the case of a Linux system, is there any security concern to let MySQL users with standard privileges (that is, not the root users) connect to the database with no password from localhost?

I think that enforcing a password even for localhost can add a layer of protection, since, with no password the database access would be compromised if the SSH access is itself compromised. Considering that, would it be less safe to allow no password connection to MySQL than having the same password for SSH and for MySQL?

I don't know if that is to be taken into account, but we also use phpMyAdmin to let users administrate their own database.

I am asking because I kinda dislike having to put our database passwords unencrypted in the source or configuration files of our applications, where they can easily be leaked unintentionally. Since our servers are configured to run our applications as the Linux user the application belongs to, I was considering allowing no password from localhost as a simple solution.

So, would that be a very bad idea or not?

Improve this question
1
  • 1
    I would use a password. Usually, when you deal with security, you can't afford the little risks. Even if you can't think of a way to exploit that, maybe some people will.
    – zneak
    Mar 1, 2011 at 3:43

4 Answers 4

Reset to default
1

I think that enforcing a password even for localhost can add a layer of protection, since, with no password the database access would be compromised if the SSH access is itself compromised

The general principle of "defense in depth" would incline one to be extremely wary of having user accounts without passwords at all. The password is a large part of the authentication mechanism; having accounts setup without passwords is akin to having locks without tumblers. I'm in agreement with you here.

Considering that, would it be less safe to allow no password connection to MySQL than having the same password for SSH and for MySQL ?

This is really a question about password re-use. Ostensibly, any password re-use at all is considered a Bad Thing(TM). The mechanism only works because the password is a secret known only to you... and the more frequently you use the secret the less likely it is to remain a secret. However in the real world we have to re-use passwords, either by literally re-using the same password in multiple accounts or by using one master password to secure a list of unique passwords. The answer to this question really depends on your environment and threat model.

As @boris quiroz pointed out, what kind of server is? Who needs access to it? In what other places would the password likely be re-used (i.e., is just for SSH or is also for the nuclear missile control panel? It'd probably be fine to re-use the password for the former, but not for that latter). What do you stand to lose if the password is stolen (i.e., how many eggs are in that single basket)? And what's the price of the data hidden away in your database with the password-less accounts compared that? Then document this process and the reasons underlying your decision. If there's ever an issue in the future, you can justify your choices.

There's no hard and fast rules here. You just need to think about the threat model (what am I protecting and from whom), and decide whether the benefits outweigh the costs. Security is always a compromise, so make sure you buy as much of it with what you give up (say in administrative overhead for example) as you can.

Personally, I would be inclined to use the passwords on both the SSH and MySQL accounts, preferably different ones, but even a re-use here would be better than nothing in my opinion. (Unless you have lots of user accounts, which is an entirely different problem).

Improve this answer
2

Sometimes, in security, you have to be paranoid :-)

In this case, my recommendation is always use password even for your local users, but you have to evaluate every situation:

What kind of server is it? Production? Development? Testing? Or is just the sandbox? If it's the sandbox and no critical data is in it, don't worry about password for local users (assuming that you already has a policy for ssh access). But, if it isn't your sandbox my advice is the use of password for everyone.

Sometimes simple solutions are OK, but they can compromise the security of your data...

Improve this answer
3
  • Thanks for you answer. I was indeed thinking to do that on the production server... I may look a bit suicidal, but can you think of a concrete case or example of an added security risk that would result ?
    – rixo
    Mar 1, 2011 at 2:55
  • SQL injection attacks are still way to common in many web apps. If you don't have passwords for your databases, it takes on vulnerable app and you expose all your data, without the attacker needing any form of shell access.
    – Sven
    Mar 1, 2011 at 3:15
  • I don't see how a password would protect from exposing all the data even if a password is set, since the SQL injection would rely on the connection the app has already established with the database. Maybe I'm missing something here?
    – rixo
    Mar 1, 2011 at 3:26
1

In general, I think it's a bad idea. If application A gets compromised, the attacker might only have access to the user and it's files that this app belongs to, but if you don't use passwords for the database, he will be capable to access the databases of applications B and C etc. as well, which might have been prevented otherwise.

Improve this answer
2
  • In our current configuration, if the SSH got compromised the database would go as well, since the password can be found in the user files. However, different users are used for each application, so only one application (files and database) can be compromised at once. I also feel that somehow it's a bad idea to allow connection without a password, anyway I can't figure a single reason why. In fact, that even seems safer to me, since the password would not be exposed in the filesystem then...
    – rixo
    Mar 1, 2011 at 3:02
  • Well, it's possible to secure an SSH login quite well with certificate-based logons etc, so if you are doing it right, this should be a quite unlikely attack vector, much more unlikely than some bug in i.e. a web-app.
    – Sven
    Mar 1, 2011 at 3:13
0

Sometimes it helps you with problems that don't go as far as external security. Just by helping prevent from simple, local, stupid accidents makes it worth it. I'd enable it with a strong password, though.

Of course, if the application gets hijacked it would be [just a bit] more difficult to --say-- remotely request the DB for a full database dump. That "just a bit" can make a difference.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .