

Accidental API Key Exposure is a Major Problem - RossPenman
http://rosspenman.com/api-key-exposure/

======
shadesandcolour
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.

------
sigsergv
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.

------
eponeponepon
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.

~~~
userbinator
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.

------
PaulHoule
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.

------
justincormack
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.

~~~
RossPenman
"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."

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

------
ShaneCurran
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

------
tlarkworthy
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.

~~~
RossPenman
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.

~~~
kelnos
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.

~~~
tlarkworthy
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?)

