3

I want to secure an API used by a react native app. If an authorisation header is sent, the user can read the request and access data. To avoid this I want to use SSL client certificates.

Now if I place the certificate in the assets folder, will it be possible for the user to get it from the APK? If yes, how can it be avoided?

Is there any other way to secure the request?

5
  • You cannot prevent a person from reading data, when a program that is running on their system can decrypt it. If they run your app, and your app can encrypt/decrypt data going over the line, there will always be a way. Perhaps homomorphic encryption will be a solution in the future, but that seems to be far off from widespread use.
    – Luc
    Commented Feb 28, 2018 at 10:11
  • I do not have any login associated in the app and it is available to public. so it cannot be secured using standard encryption methodology that ignores the factor of accessing data is possible only for the users who have already authorised access to the system. So in this particular scenario, you think i have no other option then taking the risk of leaving things as it is.
    – devedv
    Commented Feb 28, 2018 at 10:15
  • You can only identify individuals by things you can determine server-side: a verified email address, or an IP address, or something like that. If you have no account system and the app is public, then indeed, everyone will be able to tamper with the requests to the server. In practice, it's only a fairly small group of people that do this, though. And you can of course make it harder by using certificate pinning and other obfuscation layers. But it will always be possible for determined and skilled attackers.
    – Luc
    Commented Feb 28, 2018 at 10:56
  • i don't think you can send anything from one of my machines without me being able to tell what you're sending.
    – dandavis
    Commented Feb 28, 2018 at 16:03
  • You should have a unique client certificate for each of your clients. You should also have a way to revoke them (CRL or OCSP). Having a generic client certificate used by all of your apps is a Very Bad idea, and there is no realistic way you could protect its private key to make such setup work. Commented Mar 3, 2018 at 14:18

2 Answers 2

1

You cannot realistically hide the data stored on the device from the device owner. Both jailbreaking and offline analysis of a device can reveal it, as well as simple glitches in your app.

So you are better off using an established security protocol, like oauth2. Together with a principle of only downloading or storing data the user owns, and accepting that they manipulate it, you have reasonable security. If data must be kept secret from the user, it must be stored on the server.

Mutual TLS with the app's private key generated during installation, can also give you a reasonable expectation that the device connecting to your server is always the same. In practice, a strong device linking. No other apps will be able to present the same device certificate. But expect the owner to be able to read its private key.

2
  • True, but you can use TPM module and make it Very Difficult to get to this data. Commented Mar 3, 2018 at 14:15
  • @KirillSinitski I suppose, but it only needs to be extracted once and published before all app owners can access the encrypted stream. And then you have no recourse, integrity is permanently lost. So on the whole I believe it is better to accept that the owner has full control, and factor that into security decisions. Commented Mar 3, 2018 at 14:48
0

Hem...

If you send a paquet to some user, in order to permit user to use them, for any purpose. You won't be able to ensure user won't read your paquet's content!

Any way you use, user will be able to trace your applicaition, bx using kernel or network tracking!

And more:

Nothing ensure user that you won't use his personnal sercret you previously made...

The correct way:

Every user have to build his personal pair: private key and public key, share public key and care about private key...

There is alredy a lot of published authentication protocols.

For more doc, you could have a look at Transport Layer Security, Single sign-on

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .