Firstly I wasn't sure on which Stack Exchange site to ask this so if this is the wrong one I apologise.
I read this article that talks about the most secure way of storing API keys on your mobile app and one of the methods that interest me is having a function that generates an API key locally and having the same function on the server that way no one can hack your code and get the API key string literal. Here's exactly what the article says:
Your device does not need to store any kind of key and deal with all the hassle of protecting a String literal! This is a very old technique used by services such as remote key validation.
The client knows a function() that returns a key. The backend knows the function() implemented in the client The client generates a key through the function(), and this gets delivered to the server. The server validates it, and proceeds with the request. Are you connecting the dots? Instead of having a native function that returns you a string (easily identifiable) why not having a function that returns you the sum of three random prime numbers between 1 and 100? Or a function that takes the current day expressed in unixtime and adds a 1 to each different digit? What about taking some contextual information from the device, such as the amount of memory being used, to provide a higher degree of entropy?
Now what I want to know is what's to prevent the hypothetical hacker from using the same algorithm you used to come up with a valid API key too? In my mind the function would look something like this (written in javascript):
function generateKey() {
var key = 0
for(var i=0; i<4; i++) {
key *= Math.floor((Math.random() * 10) + 1);
}
return key // after encrypting it with unixtime as seed, for example
}
Please excuse if this function can't work or is stupid, it's just literally the first thing that came to mind. So can't the hacker, after reverse engineering your code just follow the same method and come up with a key that the server will flag as valid?
If you want you want to post an example in your answer feel free to leave out encryption as I only need simple 'proof of concept' answers.
Thanks
There's nothing to prevent an attacker from doing that. If an attacker can reverse engineer your app, they will find whatever secrets you've stored in it.
The point of the article is how to make it as difficult as possible for a hypothetical reverse engineer to actually find your secrets. That's why, in the article, the author is moving from a Java method (easily decompilable) to native methods (not as easy to decompile, but can be identified by the long, seemingly-random API key they're using) to a dynamically-generated key.