Have you ever whispered in your friend’s ear and told them a secret? You probably have. You lean in, say it quietly so no one else can hear, and pose your question. If your friend is just as concerned with security, they will turn their head and whisper back into your ear with a response. In a nutshell, you just had a secure communication, exchanged data, and performed a challenge and response limited to two people. You exchanged a secret relatively securely.
So how do two computer programs handle security? Outside of a detailed discussion on encryption, access control lists, and authentication techniques the process is at a high level very similar. Two programs build a trusted connection (like friends) and exchange data (encrypted) directly to each other (whispering) so no one else can hear. When two programs need to build that initial trust this is typically performed with certificates to prove the source is a trusted friend to ask the question. When the question itself is very sensitive, like asking for a password, then just trusting your friend alone is not enough. You want to make sure the source of the friendly request is in a trusted location (like not being in a crowded room). This is typically translated into the computing world as access control lists.
When two computer applications are communicating sensitive information like a stored password, businesses typically rely on a password safe to store the information. If you consider the amount of sensitive data stored in the safe, ensuring the request is truly from a friend is absolutely required.
So, what does this typically look like in the real world? For a solution like BeyondTrust’s PowerBroker Password Safe, making sure the request from a friend is an exercise in trusted technology communications. Below is an illustration for this trust using a key and trusted IP sources.
If the initiating connection can provide the proper key, certificate, and comes from a trusted source (in this example), using a REST API, then it can ask for the appropriate secret (password) as long as the requesting application has the proper entitlements in the safe. That is an additional permissions layer to ensure that the possible requests are scoped to only ones they are allowed to ask and ultimately get an answer for. For the sake of our analogy, this is like stating only certain friends can ask specification questions and get a valid response. They are entitled to get a valid response.
When programs need to tell a secret with each other, like requesting a password, the connection needs to be secure and the communications trusted; just like telling a secret with a friend. While this may sound like common sense to many of our technical readers, the analogy helps other team members understand what is involved programmatically in sharing a password and the technology in place to ensure the communications is secure.
If you would like to learn more about PowerBroker Password Safe’s API technology for sharing secrets programmatically, please check out this data sheet. BeyondTrust can help make sure your development and DevOps procedures and scripts are secure, and having a solution that does it natively helps provide a layer of security every organization needs.
