Accidental API Key Exposure is a Major Problem | Hacker News Reader

Accidental API Key Exposure is a Major Problem

rosspenman.com

19 pointsRossPenman14 comments

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.

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.

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 very far from the point... but nearly impossible to argue against without lecturing.

I think another thing is that calling it an "API key" gives a slightly different impression from "password" - the latter almost certainly implies something that should be kept secret, while it's not so clear with the former - for example, ReCAPTCHA API keys are very much publicly available in the source of whatever pages use them.

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.

"If you can, you might want to consider revoking the keys that have been made public, so that anybody who may have discovered them already will be prevented from using them."

Thats a very weak statement. It is the first thing you should do.

"As stated above, the history features of version control systems mean that simply removing the tokens and then committing the result is not enough. If you can, you might want to consider revoking the keys that have been made public, so that anybody who may have discovered them already will be prevented from using them."

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?

It seems like a malicious party could just view the source of the client app and see the key and hijack it.

Yes. That's true - if your source code is exposed to a client. Going back to my example of Twilio apps, usually the code that interacts with Twilio is on the server side, so you couldn't find the API keys by viewing source.

Another thing we (Twilio employee here) do, for our Client product, which runs on iOS and Android, we use a different form of authentication: we require a server-side component to generate a "capability token" which is signed by your main auth token. The capability token is limited in what it can do, and expires after a configurable amount of time, so if an attacker gets hold of one, the damage they can do is limited.

Of course, people can "cheat" and put their auth token and a capability token generator in their mobile app, but we try to discourage that use.

I am loving Firebase's serverless model of application development, so that server solution is not ideal.

But I don't think its possible to solve a different way. That said, there are smart people who have thought of ways of reducing server burden in ways I never thought possible (like encrypted sessions), so it might be possible ???

How does google analytics stop rogue clients registering hits on the wrong domain? It checks the domain the incoming data is on, right? (cookies?)

Reply on news.ycombinator.com