8

Scenario: I have a web application with an authentication system (classic). The application is basically an interface to a DB (MongoDB) which holds sensitive data. I properly hash the stored passwords.

Assuming hashing prevents the attacker from knowing the passwords when he already gained access to the DB:

Question 1: Is there a point for hashing passwords when you store all the data in one DB?

Question 2: What's the right way to separate sensitive data and credentials? Separate databases? Using Mongo's built-in auth system for user authentication maybe?

DKNUCKLES
  • 9,237
  • 2
  • 37
  • 47
Icki
  • 81
  • 1
  • 3
    "I hash properly the stored passwords" - side question: what method are you using? – Polynomial Sep 22 '17 at 14:32
  • 1
    @Polynomial: hash = bcrypt( hmac(key, pass) ) - recommendation by OWASP and [Mozilla - link](https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines) – Icki Sep 22 '17 at 15:44
  • Don't understand your Question1: When should it be necessary to hash passwords, if not in this situation, or what alternatives do you have in mind? Did you mean when passwords and credentials are in two separate databases? – martinstoeckli Sep 23 '17 at 07:03

2 Answers2

1

Regarding Question 1:

In general case — yes, it does. You don't know the details of a potential future attack so your job is to make an actual exploitation of any vulnerability as hard as it possible.

As you know, information security mission is to provide three values: confidentiality, integrity, and availability. Let's assume that a hacker gained a full copy of your DB (which affects confidentiality). Being able to log in as a user, he can take over integrity (by modifying user's data and performing actions on their's behalf) and availability (e.g. by changing email which can be used to regain access.

Before switching to question 2. As far as I know, MongoDB also has access control on a collection level, so it could help to limit attack propagation. You can also consider encrypting sensitive entries in a DB so unauthorized read-only access will won't be as critical.

Regarding Question 2: There is no a right way because security decisions need to be done based on many factors which can be derived from risk-analysis. You can store user creds in a different DB or create a separate auth server, or use 3rd party auth services (OAuth).

The main goal here is to keep a balance between the price of implementing, supporting those security controls and a potential loss you might have in case of a data breach. My intuition is to keep it simple and follow basic security recommendation (like password hashing and access segregation using MongoDB access control tools) combined with other security controls of the system (like strict user input validation) you can find, for example, in OWASP ASVS checklist.

Andrii K
  • 62
  • 3
0

Question 1: the point of hashing passwords is that if the attacker got a copy of your DB it should not easily crack the credentials to prevent them to impersonate your users.

Taking into account that many users reuse passwords or just change them in very subtle way, that may also helps to slow down the spread of the compromise to other components of the infrastructure.

Also hashing prevents the risk of insiders/disloyal employees, since employees who may have full access to the DB wont be able to use the information to impersonate other users for the app even if they got a copy of the hashes.

Question 2: this is completely another question, that may need to be asked separately and provide more detail, to be able to give a more specific or less vague answer

Jorge Alvarenga
  • 101
  • 2