I'm a dev working on an app that has a monolith DB (PostgreSQL). We are using a third party provider for AUTH and MFA, but want to move MFA back into our control. The plan was to move the encrypted MFA secrets into our monolith DB, but there was concern voiced by members of the team about storing something like an encrypted 2fa secret that could be potentially associated to a username if the DB was ever compromised. The suggestion was to create a second DB for our MFA tokens, so that the association cannot be made between usernames and 2fa codes if one of the DB's was ever compromised. I haven't heard of this approach being used, but I understand the logic.

I'm curious if this sounds like it actually solves a legitimate security concern (or if it's overkill), and if there are any best security practices for handling this sort of situation.


tldr: The approach you outline fails do address the actual problem, use a separate application and a secure authentication scheme.

While you are right that keeping account credential information with the rest of the lot (i.e. whatever your application actually uses when it's not authenticating users) is a bad idea (tm), the approach to just have a second database falls short to solve this problem and here's why:

The threat you are trying to mitigate is either:

  1. compromise of the database or
  2. compromise of the application

If (1), depending on what information is inside the database and how it's used (i.e. what the trust level of the application regarding the db is), I am quite confident that (2) will be possible to achieve.

If (2), having a separate database your application connects to will be useless at this point; the attacker has access to the applications credentials and thus access to both databases and can dump and use them, effectively as if they were a single database.

So, from that point of view, your proposed sollution seems like overkill because the cost outweighs the benefits. Yet, there are viable ways to doing this:

Authentication is petty known task for applications to do. This is the reason software exists that takes care of only that task.

The idea would be to have an abstracted web service (or the like) that only processes authentication and responds with a token that the actual application accepts (because it trusts the service to authenticate users, that's it's job).

One example of such a scheme would be OAuth2; you have one service for authentication and another one to serve your actual business needs. Hence you can abstract from sensitive data where you do not need it, only using the user handle your authentication platform provides.

This is independent of using multi factor or not, by the way; even if you're just using username/password auth, you gain benefits (for example, you do not leak all your customers credentials when the application gets exploited).

  • Thanks for the detail. Can you explain the attack and how the compromise of one DB (1) would lead to the compromise of the entire application (2)? – seansean11 Jul 22 at 1:46
  • @seansean11 I think that exceeds the limits of this question, but I am sure, if your question is put specifically enough to not be too broad, you might get reasonable answers. – Tobi Nary Jul 22 at 19:46

Storing OTP tokens (as well as password hashes) in a separate DB would be helpful against read-only SQL Injection vulnerabilities in the main database. This could be considered as a second layer security measure, last resort after your main DB was compromised, however I can’t decide for you whether it’s worth the added complexity.

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.