I know that a public client shouldn\'t use a client secret because, no matter how much you obfuscate it, it won\'t be protected from reverse engineering.
But, the
As you said, whatever you do, how much you try to hide your key, you can not hide it 100%. But, if you want to make reverse engineer's work harder;
Firstly obfuscate your client (I guess you already do).
Secondly, do not put your key into the client hard-coded. Receive the key after login or user opened the application. And deliver secret key to the client over SSL. Store the secret as byte array and do not save it into the client. Just store in the memory.
These steps do not guarantee the safety of the secret key, but makes reverse engineer's job really hard.
This article suggests these options, from less to more secure:
Store in cleartext
Store encrypted using a symmetric key
Using the Android Keystore
Store encrypted using asymmetric keys
Probably, using a combination of #4 and some way to univocally identify the device would be secure enough
You can also try Dexguard to obfuscate and encrypt the data. Dexguard is made by the same guy that developed proguard.
Maybe the best option is to use NDK because it can not be decompiled, like Godfrey Nolan points here
Here is a resource I found useful that helped me to implement it link to the resource
Cheers
@Semih's answer was on the right track. The secret key part is what needs to be expanded upon.
The secret key is built using the following after the login process is complete
Any future requests would involve the following
All data being sent from client to the server would be encrypted using JWT the message would be signed by the app's private key and encrypted using the server's public key.
The problem is securing #1 anyone can login and get the process started, so how would you prevent that? The only way I can think of is to do a CAPTCHA check on the login.
The solution pushes the storage of the client secrets to the server rather than on the app itself and protecting it using the app's credentials.