Hacker News Reader

Comment by lostmsu | Hacker News Reader

What are the alternatives? You have to ship secret keys with your app to be able to access public APIs

Some APIs should be accessed from your backend, not the app (eg the user can authorize you on Facebook without you sharing your API app secret).

The paper also says they found amazon tokens, with which you can spawn instances. I think you can use other kind of authentication that don't give access to the whole account.

What if you app doesn't have a backend? That's an honest question, I've been trying to come up with some way of using authe/autho keys on a fully client-side app (be it a mobile or desktop one) that is still secure; I can't think of a way to, as to communicate it requires the keys to be in memory, thus, vulnerable.

I dunno. I've wondered about all this myself quite a lot, perhaps its a non-issue?

Yes I don't know of any good solution for client side only applications. And it's a real issue I think. For instance if I have your key, it may be possible for me to access data, post on behalf, etc... of people who signed in with the service on your application

I think your only choice for doing this securely is to hide the keys behind your own server.

AWS keys should belong to IAM users who have constrained permissions to only perform the things you want them to perform.

If you're shipping root account AWS keys in any app, you're doing it wrong.

I know at least with Google you can authenticate "cross-client": https://developers.google.com/accounts/docs/CrossClientAuth

Best writeup for Google I've found: http://www.riskcompletefailure.com/2013/10/google-android-cl... (author talks about "PlusClient" which is now deprecated in favor of "GoogleApiClient", but other than that, the article is accurate - but missing server-side details).

It's a lot harder. So I'm guessing many devs just skip it.

Frequently: none. Well, you could proxy the request through your servers, but that could get relatively costly.

Ideally: either the service allows you to generate short-lived tokens (server-side, ideally without a request to the service), or you sign requests for the client. In the latter, you generally gain some measure control over what apps can do, with relatively small cost. Basically that's what you can do with S3 file uploads - your server can generate a signed URL, then the client can upload to it, all while you retain complete control of your API secrets.

Reply on news.ycombinator.com