6

This question is about storing the third party credentials in the database/some secure place so that it can not be accessed by only authorized user.

Our system connect to the third party system using specific username and password. They are using the basic authentication require the nonce value and plain text password to authenticate. We have a separate credentials for different users connecting to this third party system.

I understand that authenticating a user against our application is possible to salted hash and other 1-way encryption.

Please provide me some best approach so that I can store these third party credentials. our system require these credentials to store locally, so I am looking for some best approaches.

Improve this question
0

3 Answers 3

Reset to default
4

Well, the challenge there is that the credentials in question must be stored in a manner that allows them to be read as plaintext. This means that some of the conventional wisdom about password storage (use bcrypt) is not applicable.

Your goal, then, is to mitigate risk and compartmentalize data. If at all possible, you want to have a different process that authenticates to the foreign site and hands your web application back a file handle to the active authenticated socket. That means that compromised your website won't leak the actual credentials in use as the web application will have no permissions to read that part of the database.

Encrypting the database values is common wisdom, but it may have limited utility depending on how you design your authentication application if it runs on the same server as the database. If you have the time and resources, design it such that the encryption and decryption happen in the authentication application and the database stores the encrypted values. Placing each of those roles on different machines and isolating the database and outside authentication system provide the most segmentation.

Improve this answer
1

The Best Practice for your requirement is usage of OAUTH. So, if the 3rd Party (to be authenticated) provides OAUTH support..... then that is the best preferred way as in that case you wouldn't have to store deal with the credentials but secure the OAUTH Key provided to user by 3rd Party which is a lot less responsibility.

Though for both, Key or Credentials you can encrypt the sensitive data with User's password at for your portal and also use Salt with it.

Improve this answer
4
  • 3
    Useful only if the sites he is supporting also support OAUTH.
    – Jeff Ferland ♦
    Commented Sep 26, 2011 at 16:46
  • yeah, I did mentioned that
    – AbhishekKr
    Commented Sep 26, 2011 at 18:41
  • Actually, the more accurate statement is that the best practice is to use federated authentication, not just to use OAuth.
    – Steve
    Commented Sep 26, 2011 at 19:43
  • @SteveS you are technically correct on that part but I used more direct pointer to remove ambiguity with the well suited option in current scenario
    – AbhishekKr
    Commented Sep 29, 2011 at 8:29
0

I'm not familiar with perl. But SHA encryption is the one that comes to mind after reading your question for 2 way encryption/decryption. Then the only thing you need to secure will be the key instead of all the passwords.

Improve this answer
2
  • I understand that I will store the encrypted password in the database/secure place, but how will I make sure to send the plain text password to the third party.
    – rpg
    Commented Sep 26, 2011 at 7:07
  • Oh.. Did ya meant to say, to allow encrypted transmission of login info?
    – mmhan
    Commented Sep 26, 2011 at 9:40

You must log in to answer this question.