API Key and Secret recommendations bundled with applications

Question

I am developing an application that will use text messages to check the user's phone number, the usual procedure for entering the code.

After reading it a little, it seems like a bad idea to keep secret keys for any third party that I will use in the application (twilio, nexmo, etc.). Someone can reverse engineer them from my binary and use them in their application.

However, if this doesn’t help on the server either, someone can simply reverse engineer the endpoint of my server, which I use to send text messages, and use them instead.

eg. I could deploy WhatsApp and get the private keys or API endpoints that they use to verify the phone number, and just use this in my application, saving a thousand dollars.

Any ideas on how to protect yourself from such an attack?

Answer 1

Hiding API keys on the server

However, having nothing on the server helps, someone can just change the engineering endpoint of the server that I use to send text messages and use them instead.

Yes, that helps a lot.

If someone gets access to the keys to your web service, they can only do what your service allows them to do . It is a very good idea to have a web service that encapsulates all 3d third-party keys and APIs - this is more secure.

No one will ever gain access to your secret keys, which will allow them to do everything .

For example, a third-party API allows you to delete - the server wrapper API will not allow this.

In addition, you can add any additional logic or warnings about suspicious behavior.

Hiding API keys in an application

If someone thinks about it, you cannot prevent your keys from turning back from your application. You can make it harder. Computer security should never be about “how hard / hard it is to do,” but in this case we have no choice.

So, you need to hardcode the API keys into source files. It can be easily reconstructed.

You can confuse your keys so that they cannot be read directly. The result will be that they will be scattered in the compiled file, and not conveniently placed in one place.

In iOS, you can use something like this.

On Android, you can use DexGuard or any other way to obfuscate a string.

Key encryption

Another word for hackers is key encryption.

Here is an example for iOS.

You can do the same for Android.

Perfect scenario

So, let's say you have a third-party video management API.

The hacker wants to delete all the videos on the server, because the third API allows this.

First he must glue all the scattered lines in the file. If he succeeds, he must find a way to decrypt it.

Even if he succeeds in decrypting it, it will give him API keys for your server and your server, and your server will be able to download videos, rather than delete them.

Answer 2

I think firebase functions can help us hide third-party API keys. Proposed Solution -

• Store API keys in firebase as environment variables.
• Create an https firebase function that only responds to authorized users. If an authenticated user requests it, the API secret key from the firebase environment variable is returned as a response.
• The Android application makes anonymous login to firebase for the first time, receives a token.
• This token is used as the authorization token in the headers when requesting the https firebase function. The firebase function will look like https: // us-central1- {your_project_name} .net / {function_name}

I discussed this approach in detail on this blog and made a sample project