Storing of customer creds from third party server with reading access to it

Question

Our service will provide some automation over another service. Customers share the password with us, and our staff make the customer's work. Another work will going on our working agents(remote server).

So, we need access to passwords in two places: many(10-15) remote pc, what connected to the working pool by jenkins, and staff website.

For work agent we can use public key cryptography. Encrypt data on frontend, decrypt on a time of script work only. It will works great.

But how provide staff person access to data? Sharing private key is bad idea.

Creating another server, that have decrypt api is better, but bad too.

Here is limits:

1. Staff person have a limit of decryption per day(about 20). He can't do more work.
2. We want to switch private key very fast, if staff user fired
3. Better to encrypt data on a fronted.

Answer 1

You're trying to figure out how to securely store secret values, yet use them in your application, and the answer, generally, is to use some sort of secrets management system.

I really like Turtles All The Way Down because it does a good job of explaining the core problem with secrets management (you have to authenticate to the system, and where do you store that password?), as well as giving an overview of the most prominent current software solutions. It's a bit of a long talk, but it's worth watching.

Personally, I like Vault a lot to handle these sorts of situations. In a nutshell, the users' passwords get stored in an encrypted datastore; your sysadmins and application can access those passwords by making an API call to Vault. These API calls are logged for later audit purposes, and are authenticated through a session-like system, where you provide a password (for example; there are a number of auth options) and get back a token that gets stored for normal use, but which will periodically expire and can be explicitly revoked. This prevents an attacker who gains access to the token from gaining permanent access, and does the same for employees when they leave the company. This is roughly how other network-based vault systems, like Keywhiz, work as well.

There's a really important caveat to the last part of the previous paragraph: an attacker can use the token to access all users' stored passwords, and then continue to use those whether or not the stolen token expires. This attack comes about because you're storing static credentials (passwords). If instead you had to request temporary credentials from the third-party sites, then you could return those instead to your internal users, which keeps them from gaining permanent access without permanent access to Vault. Vault has support for a number of systems for doing this, but you're limited here to what the other sites support.