I've been reading about how unsafe and bad and terrible it is to store your API keys inside your mobile app (whatever solution you have for that) and that you should use a separate server for authentication and not store any API keys on the client app.

How does that work? How do you authenticate to the auth server without storing any keys? I don't get it.

How does this add security?

  • I assume this involves getting the user to authenticate using 2FA ? – Mike Ounsworth Mar 17 '19 at 13:57
  • @MikeOunsworth Nope. That wasnt discussed in any of the articles. – user109321948492842303 Mar 17 '19 at 14:20
  • Ok, then can you explain a little more what kind of secret is being used by the app to authenticate to the server, and how this is different from an API key? (maybe that's the question you're also asking, in which case my answer is "good question, those articles sound like they're either missing some details, or full of crap") – Mike Ounsworth Mar 17 '19 at 14:34
  • @MikeOunsworth That is indeed the question im asking. They talked something about hashing the app and all that, but a attacker can just switch out the hashing function to return hash of the legit app in their fake application, so if im not missing something here, thats not really useful at all. – user109321948492842303 Mar 17 '19 at 14:42
  • Hashing the app? That sounds like really bad obfuscation. Maybe you can link the article? – Mike Ounsworth Mar 17 '19 at 14:46

Here's my breakdown of the hackernoon.com articles you link to.

Threat model

They are trying to protect against these attacks:

  • Sniffing the traffic between your app and the server (possibly because the Android device is compromised)
  • A hacker gets the binaries for your app and reverse-engineers it to extract any secrets / keys.

Techniques they recommend

  • Rather than putting your API key in an auth header, use some kind of symmetric or asymmetric cryptography so that the secret itself is not sent over the network.
  • Obfuscate secret strings that you include in the app binary.
  • Build a proxy server that handles all 3rd party API requests on behalf of the clients / apps.

Proxy server in more detail

The example they use is this: you have an Android app which loads images from NASA over their API. The NASA API requires you to register for a developer API key which they use for billing or wtv; every request to the NASA API needs that API key included.

They are suggesting that you do not include the NASA API key in your app binary because if you do then anyone who reverse-engineers this key out of your app binary can start making request to NASA that go on your credit card.

Instead, they suggest that you build a "proxy server" where the client / app can say "Hi proxy server, can you fetch this image from NASA for me?". With this approach, the NASA API key that's attached to your credit card is stored on the proxy server, not in the app binary. Of course, an attacker who reverse-engineers your app can still make requests to your proxy server, but now **you* (rather than NASA) have full control over:

1) The authentication mechanism between your client / app and your proxy server, so if you want to do some stronger auth mechanism, you can.

2) Which of NASA's API endpoints the attacker can access through your API key. For example, maybe your API key would let an attacker access the full archives of high-res telescope images or other scientific data, all billed to your credit card. But if your app only needs to picture of the day, then your proxy server adds a point where you can enforce this restriction.

I hope this is helpful.

| improve this answer | |
  • Ah so basically theyre only trying to secure the NASA key because its a third party api which they have no control over, I see I see now. What I am trying to achieve is better security for my mobile app which is only using my API, which I already have full control over. :/ And not storing the keys to my API on the client app sounds great! That sounds like it would improve security alot, but as I previously said, I dont understand how it would work without storing a API key (and the articles didnt really explain that, aand google hasnt helped me so far) – user109321948492842303 Mar 17 '19 at 20:54
  • Yeah, well, as you point out in the question, unless you are getting a human user to do a username/password login, then you need to store some kind of secret in the app. – Mike Ounsworth Mar 17 '19 at 21:27
  • Thats what I thought, but for example a company called approov says they have a ”no client secret” auth solution. – user109321948492842303 Mar 17 '19 at 23:22
  • @user109321948492842303 Neat, I guess. Do you know how they're doing it? Is it just obfuscation and overly-excited marketing people? – Mike Ounsworth Mar 18 '19 at 0:24
  • Nope.. not open source I guess and the website says nothing atleast for a quick look, (there was a implementation example, but I dont know whether that would help understanding at all, and I was on mobile). Id like to know, as id like to implement something similar. But I think I saw somewhere that their thing was also hashing the app... lol.. Do you have any good obfuscation guides for iOS and Swift? I dont really know anything about that yet. – user109321948492842303 Mar 18 '19 at 7:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.