5 ms·
The only way i can think of would be to return the API keys with say a login request and store them inmemory until the app closes.
by weq 10y ago
The only way i can think of would be to return the API keys with say a login request and store them inmemory until the app closes.
- bottled_poe 10y agoMany apps do not require account registration, so then what? I guess it could generate a server-side API token on first login then persist it. But then you need an API, which adds unnecessary cost.
- tokenizerrr 10y agoUnnecessary cost? It's the cost of preventing hackers from being able to spin up 100s of EC2 instances using your account. Make your own damn API. Have it do exactly what users are allowed to do on your behalf. It's not an unnecessary cost, it is 100% necessary if you are interfacing with external services from your app. Or don't, and get bitten in the ass eventually.
- bottled_poe 10y agoThat EC2 example is a bit extreme, but in general I agree with what you are saying. Unfortunately, the reality is that most people paying for software development are more willing to accept these risks than to pay for security. That said, security is not all-or-nothing. And anyone who believes that modern web-connected software can be 100% secure is either misinformed or trying to sell you something that you probably don't need.
- BoorishBears 10y agoIf instead of exposing your API keys you implement an API that proxies that responsibilities your app would have needed those keys for, how are your API keys not 100% secure? You even get the added benefit of separating the implementation of those responsibilities from your app (and with app update processes being what they are, that's a huge deal when you need to make an emergency change to how you're using those APIs)
- BoorishBears 10y agoAmazon Congito already provides it for both registered and unregistered users: https://aws.amazon.com/blogs/mobile/using-the-amazon-cognito-credentials-provider/ https://aws.amazon.com/blogs/mobile/using-the-amazon-cognito... And they also provide a generic TVM (Token Vending Machine) implementation that you could adapt for other APIs
- jmiserez 10y agoThen you could just sniff the traffic, or if you can't MITM the connection because of pinning etc. then you could still run the app inside a debugger and get the keys that way. Note that if the keys are valid for all users, you'd only need to do this once per service.
- kranner 10y agoYou don't have to return the API keys to the user's phone. You could set up a proxy API that will call the third-party service on behalf of an authenticated user.
- izacus 10y agoIsn't that what OAuth keys are explicitly there to PREVENT? Letting application developers unlimited access to your accounts on their backend servers.
- kranner 10y agoI didn't mean this for scenarios where the user has an account with private content with the third party (e.g. Twitter), but for e.g. a common backend resource such as sending an error report to developers for user-facing errors.
- richard_taylor 10y agoFull disclosure, I work for a company called CriticalBlue that helps customers with these types of issues. We have a recent blog article about setting up a proxy for API keys in this way that might be useful at https://www.approov.io/blog/protect-your-api-keys-with-approov.html https://www.approov.io/blog/protect-your-api-keys-with-appro... . We have a way of then locking down that proxy so only approved apps can use it - without simply circling back to the original problem of hiding secrets in apps.