Let's say we have

  • one db server.

  • three app servers with full database access.

Which scenario is the best?

  1. Each app server connects to that one database with different passwords.

Example: app srv 1 uses : "$PSD$Passwrod3" and app srv 2 uses "sometH$ing else13pass" and so on.

  1. Every app server connects to that one database server with the same db password.

Technically, even if the servers have three different passwords, if one is hacked, the hacker will have full access to the database. So, we can use one password to make things easy for developers.

Is there any counter explanation that would justify using three different db passwords to "increase security"?

EDIT: app servers hold the same app

1 Answer 1


A scenario with three different applications

If you have three different applications in most cases they should not all have full access to the database in the first place, just the data each needs. If they all need the same data, that is already a setup that reeks of misusing the database as a synchronization mechanism. If that's the database's main purpose, okay, but in most cases this scenario has its own problems and indicates a design issue. But let's assume that's a given for some reason.

You still should use different access credentials (username and password) and here is why:

  1. At some point one app might actually start having data only it cares about and only it should access, then the initial assumption breaks and you should set up separate passwords anyway. But now you are already in production with a heavy user load and risk doing some small typo mistake that affects live users. You want to avoid that, so do it right initially
  2. If someone breaks in and compromises your app such that your database gets accessed, you want to pinpoint that breach. If you know the credentials that where used you can identify the application. That cuts out 2/3 of your search space already with a very simple and cheap preparation step.
  3. If one of your applications' security is broken and you need to change the credentials, you want to minimize the impact. If they all have the same credentials they all need to get an update of their credentials. Immediately. Now you have three apps that you need to hotfix at the same time and you risk doing a minor spelling mistake and giving your users some issues instead of just one.
  4. 2) also holds for other problems, like an app generating awesomely slow queries that drag down the database, knowing wich app did it is essential, so you want separate credentials (at least separate user id, but then you can also use a separate password).
  5. If someone breaks in and compromises your app, you will likely need to shutdown that access immediately. That means all three of your apps stop working because they cannot access your database anymore instead of just one. If one of the other apps is so important you don't want to shut down the database access immediately, that means you give your attacker a larger window of opportunity to misbehave.

A scenario with the same application on three different servers

This is indeed a relatively common scenario, so the preamble of the other scenario (that three apps accessing the same db with the same rights is a design smell) does not apply!

Using different credentials here indeed does mostly not add security but adds maintenance cost. With rare exceptions (see below).

In this case most of the issues pointed out above vanish or are diminished to the point where the convenience in maintenance of using the same credentials on all servers typically trumps the gained security. One point that still remains though is compartmentalisation for high availabilty. This would mainly apply if the three servers are reachable in different ways, such that it is likely that one is broken into without the others being compromised. Say one covers Asia, one Europe and one America, they are hosted in different places and perhaps even the OS version is different. In such a case, if one host is compromised, you could shutdown that host's access without affecting the others. If they serve the same API/region the same might apply in principle, i.e. if one is compromised you could first exchange that hosts credentials while the others could still service requests. However, typically all hosts would share the same tech stack and environment in that setting - and thus in most cases where the security of one is broken the security of all is broken and maybe just not yet exploited. So this will only apply in rare cases. If you need to ask about it, it likely isn't the case for your application setup.

You must log in to answer this question.

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