Is it safe to store a hashed password in the same database with the rest of the data

Question

I wanted to kow if it is save to store my hashed password inside a table, that resides next to the rest of my other data(tables) in the same database?

For example imagine the following (simplified) structure (with a lot of other data-tables):

authentication      user        
--------------      -----------
auth_id {PK}        user_id {PK}
username            realname
passwordhash        auth_id {FK}

Is it safe to store a users authentication/password like this, or should it be stored differntly, maybe in an extra database or such?

Answer 1

I suggest reviewing this article by Sophos, as it really nicely describes the rationale and the secure design.

Article argues to have a separate password server, so that no one role can have access to the passwords.

Many enterprise systems compartmentize passwords away from other credentials.

Answer 2

It all depends.

In general, if an attacker can read one database, it's likely they can read another, so if your application would simply open a SQL connection to the other database, you'll get no significant benefit.

Also, if they can access your database, they can probably read the traffic to and from the database, including username/password combinations.

So, I would suggest storing the authentication data in a separate database alone isn't a huge improvement in security; you'd be better off spending your time and energy on other security matters such as key management (you are salting your hashes, right?).

However...if you can set up physically separate infrastructure, and expose the authentication features as a service to the front end, using e.g. OAuth, you would create a significant barrier to the attacker. They would have to compromise this alternative database, and as the integration would be at the front end, they can't rely on sniffing traffic to your database.