Recently, I found myself wanting to share some code via Github, but realised it contained my wifi password. That’s not a huge issue (see below), but neither is it a good idea.
You should never hard-code credentials into your software – in principle. But when you’re hacking together an Internet of Things (IoT) toy for personal use in your own home, what’s the harm?
Well, the harm is that one day you might choose to share your code on Github, having forgotten that there’s sensitive information in it.
Now you might say that some hacker, living on the opposite side of the world, or even in the next county, is not going to be able to do much with your wifi password. And, on the whole, I’d agree with you. But it’s a good idea to avoid the habit of throwing credentials into code. For example, are you sure you haven’t used that password anywhere else? And while it might be just your home wifi password today, tomorrow it might be more sensitive credentials for an online account. The smarter our IoT solutions become, the more they interact with remote systems and the more they need credentials.
It boils down to this: never put passwords or other sensitive items directly in your source code. Ever. If you get into that mindset, you’ll be a lot safer.
By the way, ‘Github dorks‘ are now a thing. This is in the tradition of Google dorks, in which hackers use search engines to find vulnerable systems. With Github dorks, ne’er-do-wells use Github’s search facilities to find code uploads that leak secrets.*
Depending on what you’re coding and how, one solution is to put credentials in your computer’s environment variables. Corey Schafer has an excellent video on just this for languages such as Python.
That’s the Mac and Linux version, but he also has a version for Windows. (This is a channel that’s well worth supporting, by the way.)
On the Arduino
This approach wasn’t really going to work with the code I nearly shared. That was for an ESP32 board and I was using the Arduino IDE.
I could have edited the sensitive details and uploaded that version of the file to Github. Actually, I did. But that’s a one-off solution.
I could keep a copy of the code in a separate directory that’s linked to the Github repo, but that’s rather clumsy – having to copy over the code each time I want to commit and remembering to edit out the naughty bits.
My solution is very simple. I’ve created an Arduino library called
HomeWifi which sits in the same directory as all the other Arduino libraries (ie, in the
libraries directory within the Arduino directory). In the
HomeWifi sub-directory is a single file,
HomeWifi.h which contains the following lines.
#define HOME_WIFI_AP_MAIN MyMainSSID
#define HOME_WIFI_AP_ALT MyOtherSSID
#define HOME_WIFI_PW MyWifiPassword
You’ll note that there are two SSIDs – I have two access points in the house, and the password for both is the same. If you have only one AP, you’ll need only one entry. Oh, and that’s not my real password. 😉
I just include this like any other library:
And then use the macro names wherever I need the SSID and password. For example:
A similar approach can be used for other forms of credentials, such as tokens.
I don’t share the
HomeWifi library on Github. (And just to be safe, there’s a
.gitignore file in the directory with the name of the header file.)
Now, I can share any of my Arduino sketches via Github knowing that my password won’t be going with them. It also means that if I change my home SSID or password, I need make only one code change.
Note that this solution is simply a way of avoiding accidentally uploading credentials in plain text on Github. Somewhere along the line, these credentials will be included in the compiled binaries.
It’s unlikely that someone is going to break into my home, steal my IoT thermometer and reverse engineer the firmware on the ESP32 just to get my wifi password. I’m okay with that level of risk.
However, if you’re writing code for, say, microcontroller-based projects that will be sold and which use security tokens or passwords to access APIs, you need to think very carefully about how those are stored.
*[UPDATED 25/03/2019] See the story, ‘Over 100,000 GitHub repos have leaked API or cryptographic keys‘ over on ZDNet to get an idea of the problem.