6

Adding the AWS access key and secret key directly in app code is definitely not a good approach, primarily because the app resides on the users device (unlike server side code), and can be reverse engineered to get the credentials, which can then be misused.

Though I find this information everywhere, but am unable to find a definitive solution to this problem. What are my options? I read about the token vending machine architecture for temporary credentials, but I am not convinced that it is any better. If I can reverse engineer the secret key, then I can reverse engineer the code which requests for temporary credentials. And once I have a set of temporary credentials to access S3, I am as good as if I had the key. I can request the temporary credentials again and again, even if they expire pretty quickly. To summarize, if an app can do something, I can do the same as a malicious user. If anything, the TVM can be a bit better at management (rotating credentials, and changing key in case of breach, etc.). Please note we can put the same access restrictions on the secret key, as we plan to do in case of TVM temporary credentials.

Additionally, if Amazon doesn't want people to use the secret key directly in the App, why don't they block it in their SDK, and enforce TVM or the correct solution. If you will leave a path, people are going to use it. I read several articles like these, and wonder why?: http://blog.rajbala.com/post/81038397871/amazon-is-downloading-apps-from-google-play-and

Please help me understand if this is better, and whether there is a perfect (or may be good) solution available to this problem. I do get that TVM is more manageable (and much faster incident response once the credentials are compromised), but I am not convinced that it is more secure.

PS: This is mostly related to anonymous TVM, as users don't log in to our apps.

PS2: I am clear about the secure communication between TVM and app to get temp credentials, post the app registers. I am more concerned about what would prevent a malicious user from registering with a new UDID, and obtaining temporary credentials, and hence S3 access.

2
  • 3
    The article you linked to linked to this article at Amazon: Using temporary security credentials, so that appears to be Amazon's recommended solution. I don't think there's an answer to "How do I give the user an app that has permission to do something without giving a malicious user that controls the app permission to do that same thing". I'd look at restricting the access to resources that the app has to limit the damage that a malicious user could do.
    – Johnny
    Commented Apr 1, 2014 at 20:42
  • WIF (the link) requires authentication using an identity provider, and isn't for anonymous users. But yes, I do get your point about restricting access to minimize damage. Commented Apr 1, 2014 at 22:02

2 Answers 2

1

Don't let anonymous apps do anything you don't want an anonymous attacker doing.

It's as simple as that; there's no other option if you want to use your own AWS account. Either require users to log in (and either vend them a temporary access key/credential that is scoped to the user's access and their session duration, or proxy requests for AWS through your server and verify the user's authorization then before passing them on), or accept that the app's capabilities must be restricted to what any anonymous (and potentially malicious) user on the entire Internet can do (typically this means giving read-only access, and only to data that isn't very sensitive, and you might still want to vend tokens rather than giving the app access directly so you can rate-limit to avoid excessive bandwidth charges).

A completely different approach - only suitable in some use cases - is to require the user supply their own account (AWS account, in this case). The app itself would have no access until the user provides credentials (such as an AWS access and secret key), which the app could then store. You see this sometimes with apps that use other cloud storage providers (like Dropbox, Onedrive, Google Drive, etc.) although in such cases they usually go through another app installed on the device (where the other app already has access to the user's account) rather than requesting the user authorize your app to access the account directly.

0

Have you considered signed URLs? If your app has authentication you can get the user to authenticate and then have your app create a custom signed S3 URL for the user. This then gets sent back and can be used directly from the application.

For authentication you can use something like AWS cognito. From this they get an auth token that you validate on your server to make sure the user is authenticated before you serve the signed URL.

For more info on Signed URLS

For more info on Cognito

1
  • The question is pretty old and I don't remember the exact usecase :D, but the footnote states: This is mostly related to anonymous TVM, as users don't log in to our apps Commented Feb 19, 2021 at 12:22

You must log in to answer this question.

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