Hello folks, We have a

Client

table . We are required to make a third party API call in which we have to pass a certain credentials that are specific to each

Client

. We need store these credentials somewhere. 1. We needed to know if it is recommended to save these credentials in the database. 2. We would be required to use these credentials in plain text when making the call to the API. Saving an encrypted version and decrypting every time upon usage is what came to me. Don’t know if this is the correct approach. How would you have handled that? I am looking for best options to go for. Thanks

If you are at the stage where you need to save credentials- which seem like a username/password to me, I think it is already janky. Technically you would use an OAuth like mechanism in which the client would authenticate the third party service and you would save the access token and refresh token or similar at your end. However, if you HAVE to store client credentials at your end, it would need to be a symmetric encryption using AES or something similar. The encryption key would need to be stored at another location and would need to be rotated regularly. Maybe evaluate something like a KMS (Key Mgt Service). AWS has one but not sure if it would work for your scenario. Storing passwords in a way that they can be decrypted is just super risky and I don’t know what a better way to do it is. Interested to see what other folks have to recommend.

I agree with @loud-glass-33663, avoid saving username and passwords if possible. If your are still looking for a solution go for a secret manager like Vault with controlled access for your applications only. Your team should have minimum access to vault production servers. Another option is AWS Secret manager. For encryption Keys, you can use AWS KMS.

While its easy to ask to build in vault integration into your systems, you’ll definitely need more infra and engineering support to run vault. A lot of discussion around vault conveniently side steps the operational complexity that vault brings to the table. I understand these are secrets. You can still store them encrypted (I’d recommend asymmetric encryption here - bcrypt for ex) in the database and make sure that you store the salt as an environment variable thats injected JIT.

@straight-continent-34777 Good points. Just curious about the asymmetric encryption recommendation. (I don’t have a lot of cryptography experience). Considering he’d probably end up saving the private key similarly to how you’d save the symmetric encryption key, any other benefits to using asymmetric here over symmetric?

encryption key ==

salt

. The salt can come in as an environment variable at the very least.

If you are using cloud every cloud has key vaults which are for passwords alone

Every cloud does. But it assumes that there’s an active and efficient devops team standing alongside engineering. I’m wary of making that assumption since I’ve seen this fail hard and on the face many times.

I think the right solution would also depend on data and usage. If you have limited clients and they are not updated regularly - you can easily use AWS KMS or something similar and load data in your boot script. If your client table is huge and increasing - you can store them in database but encryption is must IMO. If the usage is minimal - I would probably store encrypted data in a separate storage (may be s3).

Thanks for sharing your thoughts folks. I am in the exploration stage. Will need to read up on certain aspects on cryptography. I will update you with the approach I took finally