On LinkedIn, Facebook, Reddit and other social media platforms I’ve found myself subscribed to both Go specific and web or general programming forums of all types. About once a quarter I’ll stumble onto a post or repository that presents me an API token, database connection string or some other credential. This is frankly unacceptable given how much PII (privately identifiable information) any random database on the internet can provide on users.
You only need a few pieces of what doesn’t feel like very personal information to identify nearly any person in the united states: Age, Zip code and Gender are an easy start and common in databases storing user information. Even the largest zip codes in the US have only 100,000 people but most have around 10,000 . The distribution of ages split that group into a hundred or so groups that spread most people evenly between 0 and 80 years of age. this means that by the time you have a zip code and age you’ve narrowed your search to a group of ~120 people. Sex/Gender reduces that by half and a fraction of your name or initials can certainly single you out from there. Any known atypical trait or preference or at all, really, makes you identifiable with much less than what you might think it would take to definitively know you’re you. At least think twice before putting in your zip code for delivery estimates on sketchy websites if you don’t want ads following you around the web.
As you may be able to tell, I have found some interest in the topic of privacy protection and how exposed we all seem to be. That’s where I find my proverbial bone to pick or axe to grind with my peers in these programming forums.
STOP 👏 PROTOTYPING 👏 WITH 👏 HARDCODED 👏 PLAINTEXT 👏 CREDENTIALS
Listen, I kind of get it. I’ve been there. I started my programming journey something like an apprenticeship under a political science dropout writing PHP, so security was not prized like economic output. In fact, I’ve seen similar bad practices at many of the places that I’ve worked. Sometimes you’re on or behind on a timeline and under a materializing gun just trying to get a working solution out and move on to the next one. Under some models for deployment it’s somewhat harder than others to inject credentials from outside code, under others there just isn’t an obvious place to put the credentials and no standard procedure for tracking what they’re named or if they’re available in a given context.
The real problem here is that not all excuses are exculpatory. Some are just explanations of a moral failing. In the words of Uncle Bob, we in programming roles control everyone’s lives, whether we recognize it or not, by transitivity, having control over the systems that continuously expand control over the audience they’re meant to serve.
We have a moral obligation to the users we ultimately write software for, no matter how obvious it is that we must meet some performance expectations of a supervisor or manager. We must think about how many people it would affect and how much it could put at risk if we take the shortcut of putting a credential in the codebase for it to be exposed when a soon to be fired intern posts it in a facebook group we have no knowledge of looking for help debugging a local database connection error.
The best part about solving this problem is how universally it presents itself. No matter what operating system, programming language, or system you find yourself in, unless you’re the very first person to venture into new territory, you’re going to find a one or dozens of solutions with varying levels complexity and resulting security.
Let’s look a some of those varying levels for a specific context: Linux hosted web services, my comfort zone.
If you’re familiar with 12 factor apps, you might remember that the third factor is storing configuration in the environment. Other approaches generally build on top of this, injecting the credentials into the environment for the server or just the individual app from a secure store elsewhere.
As an additional benefit, when you use environment variables it’s easy to append them to the beginning of a command to start your app locally or export them to your environment for the current shell (making sure to know when and where the history for your commands will record it, and if that’s important).
There are so many programmers taking this approach that there are not only mature options for this job, there are many. Many of the people reading this first will know that I’m a huge advocate for the Go programming language. (link to the playground tutorial, try it!) For example, there are two approaches I’m familiar with in Go for getting credentials from the environment beside os.Getenv(), viper and a combination godotenv and caarlos0/env. I could go on for a minute about the values of the latter, but the primary purpose for using them is so that I have a .env file I can .gitignore and at runtime I can ensure that I have values and they’re all the correct datatype already.
Even if you have test credentials for a unit test around API calling code, say a test that ensures you haven’t broken the primary function sending a payment network a user’s payment info without actually charging anyone and you want to test it in your CI (continuous integration, like Github actions) there are secret stores on code platforms like Github’s specifically for that cause.
If you need a level of security beyond what I’ve known you can even programmatically interface with password stores, loading environment variables without typing or pasting values where they’ll show up in command line history. I know 1pass provides great command line tools and I’m sure many other platforms have competitive offerings.
If you’ve made it this far I appreciate your attention. In a digital world I find it difficult to focus my own and I understand how valuable your time can be as a knowledge worker. If I made any omissions, errors or outright blunders I welcome feedback as well as general trolling, all of it lets me know you care. I want to keep the ball rolling on a blog for once in my life, so check back in a month and see if I don’t have some other horrible takes.
