2 deleted 186 characters in body
source | link

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 ana 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 runbuild 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**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 human username / password / 2FA, or certificate-based TLS client-auth, or whateversome stronger auth mechanism, you can.

2) Which of NASA's API endpoints the attacker can access through your API key. For example, maybe NASA built their API so that theyour API key attached to your credit card canwould let an attacker access the whole thing (ex.: the full archives of high-res telescope images, the full archives of Mars rover 3D Lidar scans or other scientific data, etc)all billed to your credit card. IfBut if your app only needs to access NASA's picture of the day, then your proxy server adds a point where you can restrict what the attacker is capable of doing by simply refusing to process requests for anything other than NASA's picture of the dayenforce this restriction.

I hope this is helpful.

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 an 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 run 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 can make requests to your proxy server, but now you have full control over:

1) The authentication mechanism between your client / app and your proxy server, so if you want to do human username / password / 2FA, or certificate-based TLS client-auth, or whatever, you can.

2) Which of NASA's API endpoints the attacker can access through your API key. For example, maybe NASA built their API so that the API key attached to your credit card can access the whole thing (ex.: the full archives of high-res telescope images, the full archives of Mars rover 3D Lidar scans, etc). If your app only needs to access NASA's picture of the day, then your proxy server adds a point where you can restrict what the attacker is capable of doing by simply refusing to process requests for anything other than NASA's picture of the day.

I hope this is helpful.

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.

1
source | link

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 an 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 run 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 can make requests to your proxy server, but now you have full control over:

1) The authentication mechanism between your client / app and your proxy server, so if you want to do human username / password / 2FA, or certificate-based TLS client-auth, or whatever, you can.

2) Which of NASA's API endpoints the attacker can access through your API key. For example, maybe NASA built their API so that the API key attached to your credit card can access the whole thing (ex.: the full archives of high-res telescope images, the full archives of Mars rover 3D Lidar scans, etc). If your app only needs to access NASA's picture of the day, then your proxy server adds a point where you can restrict what the attacker is capable of doing by simply refusing to process requests for anything other than NASA's picture of the day.

I hope this is helpful.