[chrismeller]

That’s how it starts though. If everything is provided at deploy and nothing is ever embedded in source code there’s no way you can end up in this situation.

In some industries it’s also an audit or legal requirement that developers not have access to production credentials, so there’s no other way to reasonably handle that.

Edit: also, rebuilding your source because an API key changed... no thanks.

[tinus_hn]

The choices are:

1. api key is publicly readable in a configuration files you ship

2. api key is compiled into the binary you ship.

There is only obfuscation. Then again api keys are not security keys.

[chrismeller]

But literally in this case it was security keys.

Even including an API key into the binary build is avoidable. Add an OAuth-style negotiation for the key as the first startup process.

Start digging deeper and there are fewer and fewer reasons.

[dpark]

> Add an OAuth-style negotiation for the key as the first startup process.

How does this possibly work? You must have some “bootstrap key” that you would use to fetch the API key. You’re going to ship something in the app that says “hey, I’m really your app” or else you’re doing to allow anyone to fetch your API key. All you can do is obfuscate the process of getting the API key. You cannot actually keep it secret when you need clients to have access to it.

[chrismeller]

Case in point: valid user credentials and it doesn’t matter what app is trying to authenticate. Issue a different key for every user (or every user per login or device) and your problem is solved.

Even if your app doesn’t require any login there’s no reason you shouldn’t go through the same process. Every device gets its own key and then you apply limits to it...

[dpark]

OK, this depends on what you mean by an API key. If you are referring to a security token that identifies the user, then yes, you should always be creating a new key per user, and often per session.

However the term API key may also refer to an App key, intended to identify all users of a given app. The intention there is to be able to engage and widespread revocation or throttling in case an app is misbehaving or compromised. You cannot keep this sort of API key secret because it must be shared and must be available.

In the non-user device scenario you mentioned, I’m pretty sure you would actually be better off simply having the device generate a random GUID instead of going through a pointless negotiation to hand out a random GUID.

[chrismeller]

I was actually referring to both, and I think the same process applies. Even if the API key is not for your service (like, say, a Google Maps key) there isn't any reason you can't fetch that dynamically from your server. There are also various solutions for secret storage on every platform (iOS and Android at least) that you could use to store it, rather than it being "public" in the app package.

[tinus_hn]

You need an api key if you show Google Maps in your app. The api key allows your app, running on the users device, to get the map tiles. Is it possible to do that without the users device having access to the key? No. Does that require user login? No. Does ‘OAuth style negotiation’ have anything to do with that? No. Is it security? No. Can you change how Google Maps works? No.

[tracker1]

3. API key is in an environment variable configured IN the environment.

4. You use a secret service that has pk or secure access from the service machine to retrieve secure configs/settings from.