I'm dealing with a 3rd party vendor that clearly does not understand security - to access their API from my back-end I have to supply the end user's ID/user/password for the 3rd party service with each batch of requests.
I'm fighting with them to at least implement some sort of revocable token based authentication, but in the mean time I have to deal with this (at least they use HTTPS... sheesh).
I have to authenticate fairly regularly for synchronizing data, and sync has to happen without the end user's intervention, so that basically means the BE has to store the credentials in a reversible format. I'm not naive enough to store it in plaintext, but even if I encrypt it in the database the key won't be very far from the lock, so to speak.
If they didn't have a metric ton of confidential data stored there I'd be less concerned, but this is definitely data worth securing. Any tips?
- The passwords would be stored in a distributed database. The database itself is reasonably secure. The only real chance of a breach would be a leak of one of the developers' credentials to directly access the data, or a serious programming mishap.
- The vendor's API does not allow programatically changing the password, so rotating passwords is not an option.
Access to the back-end's source code could be locked down pretty tight. Would it be reasonable to store a private key in the source and call it a day?