1
gitpush
1y

I have the following scenario with a proposed solution, can anyone please confirm it is a secure choice:
- We have critical API keys that we do not want to ship with the app because de-compiling will give access to those keys, and the request is done before the user logs in, we are dealing with guests

Solution:
- Add a Lambda function which accepts requests from the app and returns the API keys
- Lambda will accept the following:
1. Android app signing key sha1
2. iOS signing certificate sha1
- If lambda was able to validate them API keys are sent back.

My concerns:
- Can an attacker read the request from the original (non-tampered) apk and see what the actual sha1 value is on his local network?
- If the answer to the question above is yes, what is the recommended way to validate that the request received is actually from the app that we shipped and not from curl/postman/script/modified version of the app

Comments
  • 0
    @Ponyslaystation I think you can help me on this?
  • 1
    📌
  • 1
    Not sure if this is the right solution but yeah by default all requests are visible if I conduct a MITM attack on your app i can see everything in plain txt

    But maybe E2E, https or something like that will insure traffic from app to server is encrypted or secure such that MITM is not effective then server side uses a certificate to decrypt incoming traffic verifies its from your apk then encrypt the response
    On the apk side does the same decrypts response etc
    🤗🤷
  • 2
    MITM is always possible if it's not your machine. On Android it could even be pretty damn easy unless you obfuscate the hell out of the network calls.

    The truth is your app has an attitude problem. You think you can have both guests and authenticated endpoints using keys. This is false.

    You must accept that these endpoints are, by nature, public.
  • 1
    Sounds complicated and while it feels secure, the feeling is tainted with some voice in the back of my head whispering 'is it though....?'

    if it's a passwordless service, why not just issue an access key to anyone asking? I mean, if I obtained the app sig, I'd have the key anyways. Isn't the sig the same for all the installations of the same apk?
  • 1
    Aren't there rooted androids that could run strace on your app pid and monitor everything you're writing to the socket? Or manipulating with otherwise?

    It feels like sex w/o a condom while being drunk. One overlook, one missed syscall with your raw string, and you're fucked.
  • 2
    @AlgoRythm
    Yeah.... If client can access it then endpoint is public so auth really not that a big deal
    Unless its an endpoint that require a specific type of user like admin or something
  • 2
    Switch your policy around, make these endpoints public as they are for guests but make sure every incoming data is cleaned, verified, etc… Ensure your endpoints cannot be spammed. This is how it’s usually done. You cannot secure something that’s not authenticated one way or another.
  • 1
    Thanks everyone, basically its the site key of google recaptcha would anyone be able to abuse it and get tokens to be able to send loads of requests to the API we protect using captcha?

    Is there any risk in having site key visible
  • 0
  • 1
    @DeepHotel and everyone else, we ended up using reCAPTCHA Enterprise as it allows us to do further locking in terms of app package name and have separate keys for android and iOS
Add Comment