(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?


2 Answers 2


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:

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.


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.

  • $\begingroup$ Using the decryption of the private data as the authentication mechanism makes sense. Thanks. $\endgroup$
    – Ralph
    May 3, 2016 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.