Storing Credentials for a Third Party

Question

(Originally posted to SOF, but I got no answers)

I am designing a small application for use inside my company. My application needs to connect to a third party website on behalf of my application user. I would like to safely store the user's credentials for the third party site in my database. Obviously, storing the third party password as plaintext is out of the question.

What I am proposing is the following:

• When a user creates an account in my application, the application generates two salt values.
• The user enters a new password for my site as well as credentials for the third party site (username and password).
• My application uses the first salt value and PBKDF2 or bcrypt to hash the user's local password. This hash is saved in the database for later authentication.
• My application uses the second salt value and the same key derivation function to generate a second hash. The second hash is used to AES-encrypt the third party credentials. The encrypted credentials are saved in the database for authenticating to the third party site.

The only weakness that I can find is that if the users' local password is weaker than the third party password, an attacker need only guess the local password and both are compromised.

Are there any other problems with the algorithm? Is there a better way to accomplish the same result?

Answer 1

I've written extensively about how to solve this problem, over on the IT Security Stack Exchange site. Let me point you to my answers over there:

• What is the best way to securely keep clear passwords?

• How can I create a service that automatically logs onto a third-party service without storing credentials in plain text?

• How should you store a password that needs to be retrieved as plaintext?

Basically, I'm suggesting you set up a separate machine that stores people's credentials for the third-party website as well as a hash of their local password, authenticates the user, and then connects directly to the third-party website. That separate machine should be secured and locked down as carefully as possible, to reduce the likelihood that it is compromised. But read those links for all sorts of extensive details and suggestions.

Answer 2

That is not really an algorithm, more of a scheme. There is nothing essentially wrong with it, but it should be computationally infeasible to determine one of the hashes from the other, as each are equally important to protect.

I would use different hash algorithms in addition to different salt values in that scheme.

You could also NOT store the auth hash, and rather wait for successful decryption of the 3rd party credentials as a form of authentication. That will reduce the servers workload by half, or allow you to increase the key derivation workload.. You will need to encrypt the credential and a single iteration hash of that record with the key derived from the local password, and then simply verify the hash upon decryption.