Using master password to encrypt and decrypt user credentials

Question

I need a way to store third party credentials, and I want to avoid storing passwords in plain text. I can't use a hash because I will need to be able to get the raw password to log in to the third party service.

My idea is to use a master password that I enter on the startup of the service that will be used as a key to encrypt and decrypt the users third party information. The only flaw that I see with this method is that I (or anyone who can somehow get the master password) will have access to user data for the third party service.

Alternatively, the user can enter their third party login credentials when accessing my service, and my service can access the third party site. However, the service is supposed to run 24/7 and this method would require them to reenter their login credentials every 8 hours rather than only once.

Are there any significant flaws with either of these methods, or is there any better approach to solve the problem?

Answer 1

It's true that anyone who learns the master key has enormous leverage. Key management best practices are worth investigating. I highly recommend that you consider using a key management service (KMS) that is backed by a hardware security module (HSM).

There are affordable offerings in cloud-based services, such as Amazon's Key Management Service, that allow you to retrieve a key from their service and use it locally. Alternatively you can use a cloud-based KMS to encrypt by transmitting plaintext data to the service, and receiving a reply consisting of ciphertext and a reference to a key (decryption consists of sending the ciphertext back to the same service along with the key reference).

Of course using a cloud-based service requires that you authenticate with the service, and that means transmitting credentials to it at some point. You can make this process more secure by configuring the KMS to accept communication from a limited set of IP addresses. Also, your KMS authentication credentials could be encrypted and stored at rest in the form of ciphertext. The unencrypted KMS credentials could exist in RAM for a duration that you determine (your original post said every 8 hours, which seems adequate). The method for decrypting the KMS credentials could be that you supply a password which gets converted to a key that could then perform the decryption. Then let the KMS do the rest of the encryption work.

Answer 2

Is there something in your requirements that would prevent you from using OAuth? Your problem sounds very similar to the problem OAuth was created to solve.

https://oauth.net/

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service.

In general, sharing passwords is a very bad idea. Your users are essentially trusting you completely. You could change the password and contact email of their account and lock them out. OAuth is more like a valet key that allows someone to drive your car for you, but not open the trunk.