I had this same issue when I started working on a side project. I quickly decided to store the Github API secret and client id in a property list, and then access it from there in the code. The keys are never exposed in the code and that's great. The property list file was ignored by my github repository and all was well with the world.<p>Until I started using a CI server, which would fail to compile because that file was no longer present when it was described in the project configuration. To fix this, I added a blank copy of the configuration file to the repository, committed that so that the project would compile on Travis, then ran `git update-index --assume-unchanged` to never update that file again, so that I could fill in the correct configuration data again.
API key of any downloadable application should be considered as “public”. Removing it from public source code just makes harvesting a bit harder, but it's still possible. So if API key of such applications is so important — it's just a bad service design.
I think there are two root problems here; the first is human error/forgetfulness, and there's only so much you can do about that.<p>The second, which I see on a daily basis from a small number of my colleagues, is a lack of understanding about security - by way of an example, we distribute a script to commercial partners that I've regularly had to expunge passwords for our Subversion repo from. Trying to explain the problem to the culprit gets nowhere because 'well, they can't access the repository without using our VPN', which of course is <i>very far from</i> the point... but nearly impossible to argue against without lecturing.
It's not just a problem for "open source" applications, it's a problem for "closed source" applications too. In a large team you don't want to give every developer the keeps to the jeep.
Bizarre that nowhere does this article say you must invalidate the key. Lots of people could well have pulled a branch with the key, and rewriting history will make this very obvious.
Nice article, Ross. This is definitely a huge issue that many developers face. I did a similar search for Twilio keys and many of those accounts had hundreds if not thousands of dollars worth of Twilio credits ready for use by a malicious attacker. It just comes to show how simple most of these mistakes are while still being very serious
If you develop a API that requires a key, is there any secure way of allowing third party developers to develop client applications that use your API?<p>It seems like a malicious party could just view the source of the client app and see the key and hijack it.