Securely stored secondary password

Question

I'm currently writing a portal site for Microsoft Dynamic CRM, the portal works like this:

• Each user has his own account to login to my portal.
• Each user is assigned a seperate CRM credential by admin. Currently, both username and password for CRM site are stored as plaintext (password for the portal itself is properly hashed, salted,... using AspNet Identity Core).
• After logging into my portal, users will be authenticated with CRM site in the background and can start view, add, edit and delete records on CRM site.
• Users can change their own portal password, but CRM credentials are fixed and can only be changed by admin.

Obviously I wouldn't want to store CRM credential in plaintext, but I cannot find any working solution for my problem. I've considered the following choices:

1. Hash CRM password and store the hash. This does not work because I need the original password to authenticate with CRM site.

2. Derived a key from user password and encrypt CRM password, then store the encrypted password (password manager style). Does not work because admin won't be able to change CRM password.

3. Same as 2, but use admin password to derive the encryption key. This also does not work because then I can no longer authenticate users with CRM site.

Answer 1

Passwords are user facing data. If you have a "password" that is neither set nor used by a user, it's called a "key" or a "secret" (exact terminology varies by use). So you need to research key storage, not password storage.

There are two parts to securing a key:

1. Choose a cryptographically secure random key. Something like 128 bits from a CSPRNG will do nicely. You can base64 encode the key if you want to store it as text.

2. Encrypt, not hash, the key when it is not needed. Use something like AES 256 for encryption. This leads to a bit of a circular problem as you need to store that credential securely. The best place for that is in an HSM. If that's not possible, storing it somewhere will have to do. Just don't put it in the same database as the keys in case an attacker gets DB access.