I received an excellent reminder about protecting secrets from a developer this morning. His advice included:
In the course of development work, many of us need to encode or encrypt strings. He had just bumped into a situation where teams were using an Internet-available, public service to base 64 encode OAuth key/secret pairs. These OAuth “secrets” are used all over the Internet to authenticate against web service interfaces. Too often they are static/permanent strings — which means that once stolen they are useful to anyone, hostile or otherwise, for long periods of time. This type of authentication credential must be very carefully protected throughout its entire life-cycle.
[Please stick with me even if you are not familiar with base 64 or OAuth, because this is broadly reusable advice]
The specific site is not really important as it could have been one of thousands of other free data encoding/encrypting sites.
The risk issue is associated with the fact that the “free” encoding service cloud site knows the client’s source IP address (plus other endpoint/user-identifying metadata) and the secrets that the user inputs. Using that information, they can infer (with some confidence) that a given company is using these secrets, and can sometimes also infer what the secrets are used for by the structure of the inputs. Nothing on the Internet is truly free. We need to assume that these sites earn revenue by monetizing what they learn. Cyber-crime is a business, and it is often less expensive to buy information about specific or classes of candidate targets than to independently perform the initial reconnaissance. So we should expect that some percentage of what free sites learn ends up as inputs to cyber-crime planning and activities. In that context, our secrets would not remain secret — and our risks would be elevated. In addition, extruding secrets in this way would also violate company policy at every global Financial Services enterprise.
Lucky for all of us, there are easy alternatives to using Internet-available public services to encode/encrypt our secrets.
Encoding can be as simple as a PowerShell or Python one-liner:
python -c "import base64; encoded=base64.b64encode(b'mySecret'); print encoded;"
Or you can use any other development language of choice to easily assemble a utility to encode secrets. This is not technically difficult or especially risky.
Encrypting safely is a greater challenge. Understand your goals first. Once you know what you need to achieve, you can work with a professional to select a cryptosystem and coding/operational processes that should have a chance of meeting those goals. Cryptography can go wrong. Do not attempt to invent your own.