Is it good to store passwords in a separate table/database and manage them in a separate process?

Question

I'm quite a newbie at systems architecture and security so I just want to check that this plan makes sense. I'm building a web app and I need to store a password for each user. I've already read plenty about hashing algorithms, salt, and so on. I'm going to use Argon2 since it seems to be the current recommendation. My question concerns how the hashes are stored and checked in terms of overall architecture.

Since hashing with Argon2 is intentionally quite expensive, I want to create a service in a separate module/process so that it can easily be moved to a one or more separate machines if needed. Even if it lived on the same machine as the main app server, it would be trivial to monitor its CPU and memory usage to tune the cost factors for the hashing algorithm.

My app will send HTTPS POST requests to the service to either create, update, delete, or verify a password. All the details will be in the request body, including the password in plain text. The connection will be encrypted. The response will simply be an indication of success or failure.

The service will handle the logic of database operations, hashing passwords, and comparing hashes for equality. The passwords will live in a separate database from the users, so that even if an attacker dumps the entire password database they still don't actually know anyone's password, and vice versa. Also, if I ever migrate to a different storage solution for my other data, there is less migration to do since the passwords can remain as they are.

Does that sound good? Or does it somehow open up more weaknesses that I'm not aware of?

Answer 1

Hashing being too slow means you need to use a faster hash, not a second process. Try tweaking the parameters on Argon2 or move to bcrypt (which is still really secure). Adjust the parameters to get the hash to a reasonable time (~0.2-0.4 seconds) and keep everything in one process.

If you want, you can still keep the passwords in a second database to reduce data loss if your primary database's contents get stolen, but I am not sure this is needed. Conventional wisdom says that bcrypt is secure even with all data being stolen. Now that is no guarantee, but unless you have the NSA coming after you, or you're storing something valuable enough to motivate large portions of the Bitcoin network to stop miming and start cracking your passwords, I'd be very comfortable with a reasonably performing bcrypt.

Answer 2

While this is a security question, I'd like to make you aware of another consideration:

Performance considerations

Creating a micro web service to handle authentication might be a good idea in some cases, this depends on the use cases.

Yet, you might want to consider that establishing many https connections (for many requests) comes at a cost as well. It might be useful in terms of load minimization (as that seems to be a concern) to have the two services establish a long lived tunnel that is used by multiple connections.

As to the security considerations

• The actual, user facing web service will act as a TLS client in this szenario.

  It is extremly important that the trust store is working as intended (e.g. trusting only the certificate of the password service) and that the password services' private key as well as the web services' remains private.

  Else,

  • the service could become vulnerable to MITM attacks (especially when running on different machines)
  • attackers could directly interact with the password service, maybe DOSing it with extremely big payloads or being able to use indirect side channel timing attacks.

• The web service and/or the password service should preferably use some strategy to be sure to mitigate possible timing attacks and DOS.

Also, of course, the increased scalability, seperation of concerns and especially network segmentation (which are good and important), comes at a price: Implementing the logic may become more complex and you might introduce subtle problems you are not aware of. This is especially true if you are not used to that.

An example of increased complexity could be: On email changes, who handles the actual commit atfer the new email as been verified and how, e.g. who is authorative for changing data that is duplicated across the databases? Do you want to start network IO within a database transaction?

As to the hashing function

There is a question here about hashing passwords securely that has very good answers.

Consider that there is no need for you to use bleeding edge research hashing functions. The others (PBKDF2, bcrypt and scrypt) are as-good for this purpose and you do not have to expect a severe problem to be found anytime soon as they have had time to be thourougly peer reviewed.