https://kotlinlang.org logo
Join Slack
Powered by
Hi Guys , My back-end team are adding a feature to...
# android
a
Hi Guys , My back-end team are adding a feature to add an api-key to our http endpoints for security reasons . Now this key can be anything , as in it is completely on us what key we decide to use . So I was thinking how about using my apps signing certificates using 
PackageManager.GET_SIGNING_CERTIFICATES
so I do not have to store it any where in my codebase as anything can be reverse engineered. Is this method secure or can any hacker figure out my SIGNING_CERTIFICATES as well ?
😶 1
c
Nothing on a device controlled by an attacker is secret.
Also, the signing certificate is public anyway (that's how the play store checks the integrity of the app after downloading it)
a
So what would be the most secure way of storing api keys ? people are saying using JNI with C++ .
c
There's none. It's not possible to store something on a device without having the owner of the device be able to find what it is.
The only way to have secrets is to have them server-side only. It's not a language thing, it's how computers work. No matter what you do, a sufficiently motivated attacker can dump the entire memory of the device and find your info.
a
Yes , I agree . But there must be some approaches that can make it hard for the attacker .
I just want the path of highest resistance for an attacker.
c
It's possible to make it harder, sure. But do you want a secret or a mostly secret.
a
I am sorry I do not follow
c
It's either possible for an attacker to get it, in which case it's not a secret, or it's impossible.
a
But you are saying the second part , i.e it being impossible is not possible 😄
So I have no other option but mostly secret
c
Well it's not possible to hide something from the owner of a device.
a
Event if its not a rooted device ?
c
If you store secrets server-side, an attacker can't steal them
a
But how will front-end use those secrets ?
c
How do you check it's not a rooted device? A rooted device can lie about anything. May be hard, but it's never impossible.
If you send secrets to your frontend, it's now public information. Anyone could be listening on the traffic.
a
So we are back to square 1 then
c
It's simple: if you have a secret, never give it to the attacker. Sending it to a device they own counts as giving it to them.
Now if you don't care that your API key is public, go ahead and send it to the client. One day, someone will figure out how to access it.
a
Thanks for the help .
c
With regards to API keys specifically, they're even easier to access: just setup a proxy and inject the fake certificate into the device, and you can listen in on all traffic (and read all credentials)
a
Ohk , is there a way Back-End can verify that this API call is coming from our own APK which is installed from Playstore ?
c
No. You can ask the app to send its signature and check it, but an infected app can lie and send the real signature.
👍 1
j
Ivan CLOVIS Canet [12:11 PM]
With regards to API keys specifically, they’re even easier to access: just setup a proxy and inject the fake certificate into the device, and you can listen in on all traffic (and read all credentials)
That’s only true with unencrypted traffic, which no one should be doing, or when not pinning the certificate.
c
Certificate pinning only works if you can trust the user cannot unpin it. It's more complicated, but they can do it.
It doesn't stop the fact that you replaced "my secret is server-side and impossible to access _no matter who is attacking me_" to "my secret is now on any device, it's hard to get, but it is _possible and someone will manage to do it at some point_"
Watch any security conference, and you'll see that each year, at least one person presents how to bypass tools like this. Why make your secret hard to access when you can make it impossible to access?
a
So the end goal is just that my Backend needs to know whether this call was made from a valid android phone and not a script , api keys seemed like one option but if there are other options I am open to them , this firebase app check sounds promising , will check it out
c
(also using tools like this is borderline unethical, you're forbidding a user to do what they want with a machine they bought themselves and own, just because you don't want them to know secrets you put on a device they own? It's their device, not yours)
@aishwaryabhishek3 when a user uses your service, they authenticate themselves to your service, right? They get a single token that's specific to them, that ensures your server knows who it is talking to. An attacker cannot pass for another user, all they can do is lie about themselves. That's basically what every app does
a
Yes , but the endpoind to send OTP imdoes not have any token so there is no check on that and someone is generating random phonenumbers and spamming that endpoint
c
ratelimit IPs?
👀 1
a
in most of the cases the security should be handled by the server side, you can't do much to protect the app data on the phone If a user is authenticated on their phone, why not let them do whatever they want? If they can do sth harmful, it is the responsibility of the server to prevent it there is another problem: when a phone is stolen, then a user is authenticated with a different account. But it is not your responsibility to handle this kind of cases
➕ 1
15 Views
Open in Slack
PreviousNext
Powered by