Safely keep customer secret

Question

I know that a public client should not use a client secret , because no matter how confusing it is, it will not be protected from reverse engineering .

But the people responsible for the service that I authenticate do not want / cannot change. Therefore, I need to keep the client's secret and try to protect it from reverse engineering, as far as I can.

So, I was thinking about encryption, using it at build time using gradle and saving it in a file. Then, when I need it at runtime, I decrypt it. But now I have to solve the problem of how to save 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 some kind of mechanism for such scenarios.

Any idea?

Answer 1

This article suggests these options, from the less secure:

• Save as open

• Store encrypted using a symmetric key

• Using Keystore Android

• Store encrypted using asymmetric keys

It is likely that the use of combination No. 4 and some possibility of unambiguous identification of the device will be quite safe

Answer 2

Perhaps the best option is to use NDK because it cannot be decompiled, for example, Godfrey Nolan points here

Here is a resource that I found useful that helped me implement its link to the resource

Greetings

Answer 3

As you said, no matter what you do, as far as you try to hide your key, you cannot hide it 100%. But, if you want the reverse engineer to work harder,

First, obfuscate your client (I think you have already done this).

Secondly, do not put the key in a hard-coded client. Get the key after logging in or the user has opened the application. And deliver the secret key to the client via SSL. Keep the secret as an array of bytes and do not save it in the client. Just keep in mind.

These steps do not guarantee the security of the private key, but make the work of the reverse engineer very difficult.

Answer 4

You can also try Dexguard for obfuscation and data encryption. Dexguard is made by the same guy who developed proguard.

Answer 5

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

• The secret key is located between the application and the gateway server not for basic services.
• The gateway server is responsible for converting this key to something specific to services.

The secret key is created using the next login process

• the server creates a key pair specific to login.
• The server’s public key is sent for encryption specific to client registration in
• the application will generate a key pair for its purposes
• the application will send the public key encrypted with the public key of the server
• the server will check the public key with the public key.

Any future requests will include the following

All data sent from the client to the server will be encrypted using JWT, the message will be signed with the application’s private key and encrypted using the server’s public key.

The problem is to ensure # 1 so that someone can log in and start the process, so how would you prevent this? The only way I can think of is to do a CAPTCHA login check.

The solution puts the client secrets store on the server, not on the application itself and protects it using the application credentials.