41

I've seen setups where a password-protected database resided on the same server as an application holding the credentials to said database in plain text.

What are the benefits of such a setup over a simply unprotected database?

Apart of some obfuscation, having to configure both, database and application, to those credentials only seems to add complexity, but not real security. An attacker with access to the server could always just find the credentials in the application's config file.

Edit: I'm talking about a database only visible within the same machine, and not exposed to the outside.

Cedric Reichenbach
  • 522
  • 4
  • 8
  • 5
    Today you decide you don't need to password protect the database because the database allows connections from localhost only. Two years in the future you decide it'd be convenient if your server had an http proxy. – Guntram Blohm May 18 '18 at 16:52

8 Answers8

53

It makes sense to password protect the database if you secure access to the application's config file that holds the plaintext credentials. When you restrict read access to the application's account only, the attacker requires root access to see the password. In case he breached any other (less privileged) account, he will not be able to gain access to the database.

Stef Heylen
  • 1,726
  • 1
  • 14
  • 16
  • 1
    I think I see: If the DB is exposed through a port on localhost, it cannot be simply restricted to specific users, but an application config file can. – Cedric Reichenbach May 16 '18 at 12:36
  • 13
    "If the DB is exposed through a port on localhost, it cannot be simply restricted to specific users" iptables can do this with the `uid-owner` flag. – 2rs2ts May 16 '18 at 15:57
  • @CedricReichenbach Something else you may want to consider is using a UNIX socket rather than a TCP port, if your database and app support it. – Dessa Simpson May 18 '18 at 15:47
  • The attacker isn't limited to the requirement of gaining root to get the password for the attacker could compromise the application. – user2320464 May 20 '18 at 16:22
22

That is kind of an onion protection (also known as "Layered Security" or "Defense in Depth" as seen, for example, in SANS' "Layered Security: Why It Works" whitepaper). If an attacker can reach the machine (s)he cannot gain full database access. The application should have a restricted access limited to only the required tables, and everything that need not be written should be read-only. Any higher access should require a different password never used in the application.

Tobi Nary
  • 14,302
  • 8
  • 43
  • 58
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • 1
    @RenatoGuimaresMogekag: IMHO your proposed edit adds too much to my answer and focuses on NoSQL databases which is not my intent. You'd rather write it in your own answer, saying that it is a complement to mine. – Serge Ballesta May 16 '18 at 14:51
12

The benefit is that an attacker who has got network access to the database but not filesystem access to the server will be unable to actually log into the database.

Mike Scott
  • 10,118
  • 1
  • 27
  • 35
  • Sorry, failed to specify that: I'm talking about databases only visible within the same machine. – Cedric Reichenbach May 16 '18 at 11:46
  • 7
    @CedricReichenbach How do you know the database can’t be accessed over the network? You may not _intend_ for it to be accessible over the network, but if everything was going the way you intended it to go then no attacker could get access of any kind and your question wouldn’t matter. – Mike Scott May 16 '18 at 12:32
  • Yeah, that makes sense. But even within the machine, it may make a difference as pointed out in [Stef Heylen's answer](https://security.stackexchange.com/a/185891/125571). – Cedric Reichenbach May 16 '18 at 12:38
  • 1
    @CedricReichenbach Assumptions are dangerous in IT security. The whole point of defence in depth is that you don't *expect* the first layer to fail, but you implement additional layers anyway. In your scenario the first layer is that the database is not exposed to the network. The second layer is that it is password protected in case it somehow does get exposed. – Jon Bentley May 18 '18 at 15:10
5

Whether this provides additional security will depend on your threat scenario, and your security goals. I know of at least two situations where it does add security:

  • It allows you to more finely control legitimate access to the database: There may be people who legitimately need access to the database, but not to the data inside, such as DB administrators performing maintenance. An encrypted database may (depending on setup) allow granting DB access while still keeping data secret.
    In a similar vein, encrypting a part of the database (e.g. only columns with passwords) allows limited access (for example for debugging problems, for reporting or for a data warehouse) while protecting critial information.
  • It can protect backups of the database. If the database is backed up on a file level, or with a backup tool that supports encrypted databases, the backup will be encrypted. This is useful because backups can be a source of data breaches, since they are often not secured as well as the servers they were taken from (see for example Poor Backup Security Leads To Ameriprise Client Data Leak).
sleske
  • 1,622
  • 12
  • 22
  • this is the difference between protecting against incompetent snooping versus competent snooping. they can't simply run "strings" against the database files, but won't stop somebody that grabs the database and does a minimal amount of development to read all of it later. – Rob May 18 '18 at 00:06
  • @Rob: If the DB is properly encrypted, reading it will be impossible without the password. Of course this depends on the encryption setup you use. – sleske May 18 '18 at 00:33
  • from the original post: "on the same server as an application holding the credentials to said database in plain text." this unfortunately, is a very common scenario. i would not say "no protection", but it doesn't protect you from anybody you would worry about. it's common because people want to be able to do an unattended reboot. – Rob May 18 '18 at 00:48
4

Benefits of password protecting the DB

  • If it is not possible to use it insecurely it reduces the risk that if the DB and server need to be split at a later stage they will be left in an insecure way, leading to future exploits.

  • If an attacker can breach the machine with a limited account they may be able to connect to local services, but not reset the database password; requiring the attacker to authenticate limits the damage they can do.

  • If an attack can be used to reflect / relay traffic then a remote adversary can appear to be on the local machine (an example would be a proxy that can be convinced to load a DB API, or a service which shows received data when a connection fails to a given URL)

  • If passwords are used then different systems and users can be prevented from using each other's accounts, otherwise, an attacker from any system can pretend to be any other system.

Cowthulhu
  • 1,231
  • 1
  • 8
  • 22
jrtapsell
  • 3,169
  • 15
  • 30
2

If you don't have major scaling concerns in your future, it may not add any security to have a password, though please note that "not having a password" is not the same "trusting anyone who claims to be your application."

If your application runs as its own user on the server *, some databases may allow you to use 3rd-party authentication (e.g. what Postgres calls peer authentication) which allows the server to use network or operating-system mechanisms for determining which users are who they say they are. For instance, under the right config, shell-user "bob" could access database-account "bob" without giving a password. Having things be simple can make securing your database and application easier.

That said, as jrtapsell's answer hints, you may need to move your application to another server for cost or performance reasons. In that case you will likely need a stored password or other secret like a private key, although there are some methods primarily within private networks which could be used to avoid this.

If you think there's a decent chance you'll need a password (or other stored-secret) in future, then you should just make the arrangements now so they are not made insecurely later by someone with less time or experience.

* Ideally, that account should be strongly passworded, or only available to log into via sudo or equivalent mechanism

koyae
  • 125
  • 3
2

You know all those data breaches that happened recently? The ones where people found un-password-protected database backups in unsecured Amazon S3 buckets? Yeah.

Never assume your database will only ever live on your secured server behind twenty billion firewalls. The minor hassle of a password on your DB is a small price to pay for the essentially free security it provides.

Ian Kemp
  • 229
  • 1
  • 12
1

As a complement to Serge Ballesta's answer.

This gets especially tricky if you're using a NoSQL database, e.g. MongoDB, as by default any database user will have read-only privileges for all databases, and it doesn't even come configured to have a db-user out of the box. There are quite a few weaknesses as state by Spider Labs Blog some time ago (around 2013), but the recommendations are usually not followed even for big companies, e.g. MacKeeper incident (late 2015).

In both references, you will find a list of the most common vulnerabilities. If you'd rather read 'official' guidelines you can find them here, they shall be analogous for SQL databases. However, I like to think that there are no overkills when the subject is security.

Renato Guimares Mogekag
  • 11
  • 4