Store client secret securely

问题:

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 people in charge of the service I am authenticating to don't want to/can't change it. So, I need to store the client secret and try to protect it from reverse engineering as much as I can.

So, I thought of encrypting it using at build time using gradle and store it in a file. Then, when I need it at run time I decrypt it. But now I have to solve the problem of how to store the encryption key...

I don't know much about security, so, I don't know if this can be solved, or if Android (min sdk 15) provides any mechanism for this kind of scenarios.

Any idea?

回答1:

This article suggests these options, from less to more secure:

1. Store in cleartext

2. Store encrypted using a symmetric key

3. Using the Android Keystore

4. Store encrypted using asymmetric keys

Probably, using a combination of #4 and some way to univocally identify the device would be secure enough

回答2:

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

回答3:

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.

回答4:

You can also try Dexguard to obfuscate and encrypt the data. Dexguard is made by the same guy that developed proguard.

回答5:

@Semih's answer was on the right track. The secret key part is what needs to be expanded upon.

1. The secret key is between the application and the gateway server not to the underlying services.
2. The gateway server is responsible for converting that key to something specific for the services.

The secret key is built using the following after the login process is complete

1. the server generates a key pair specific for the client logging in.
2. The server's public key is sent for encryption specific for the client logging in
3. the app will generate a key pair for it's own purposes
4. the app will send the public key encrypted with the server's public key
5. the server will validate the public key is signed with their public key.

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.