Researchers recently revealed that mobile app developers use weak security and authentication methods in their apps. This puts user data at risk. One researcher writes:

"The weakest form of authentication, meant to identify rather than to protect the data, uses a simple API token, a number embedded into the app's code. With current tools, however, attackers can easily extract those tokens and not only read the data, but often even manipulate it. Attackers could, for example, sell email addresses on the underground market, blackmail users, deface websites, or insert malicious code to spread malware or build botnets." - https://www.sit.fraunhofer.de/en/news-events/latest/press-releases/details/news-article/technische-universitaet-darmstadt-und-fraunhofer-sit-datenleck-in-apps-bedroht-millionen-von-nutzer/

As you can see, embedding credentials in a mobile application is unsafe, but what's the alternative and best practice? We offer Amazon Cognito to mobile app developers as the recommended alternative. Amazon Cognito will provide temporary, limited-privilege credentials to each user whether the user is an unauthenticated guest or an authenticated user. By "credentials," we mean Amazon Cognito provides a unique AWS access key and secret key to each user. These credentials and their distribution mechanism have a few important properties that increase security over embedding shared credentials:

• They are produced for the current user, so nothing is embedded in your app's binary files or configuration for a malicious user to capture and reuse.
• They expire after a short period of time so that, in the unlikely event a malicious user was able to nab the credentials, they won't be usable for long.
• They are also limited in privilege. When you set up your identity pool in Amazon Cognito, you can give unauthenticated guests permissions that are different from those given to authenticated users.

In this article, we'll explain how to switch to Amazon Cognito and touch on some other ways you can use Amazon Cognito to protect your users.

Amazon Cognito as an Alternative to Embedded Credentials

Here is an example of what not to do (initializing the AWS Mobile SDK with embedded credentials):

// Warning! Example of what not to do! Don't do this!
AWSStaticCredentialsProvider *credentialsProvider = [AWSStaticCredentialsProvider credentialsWithAccessKey:"your-access-key" secretKey:"your-secret-key"];
AWSServiceConfiguration *configuration = [AWSServiceConfiguration configurationWithRegion:AWSRegionUSEast1 credentialsProvider:credentialsProvider];
[AWSServiceManager defaultServiceManager].defaultServiceConfiguration = configuration;

Here is the same code using the more secure Amazon Cognito credential provider:

AWSCognitoCredentialsProvider *credentialsProvider = [[AWSCognitoCredentialsProvider alloc] initWithRegionType:AWSRegionUSEast1 identityPoolId:@"your-cognito-identity-pool-id"];
AWSServiceConfiguration *configuration = [[AWSServiceConfiguration alloc] initWithRegion:AWSRegionUSWest2 credentialsProvider:credentialsProvider];
[AWSServiceManager defaultServiceManager].defaultServiceConfiguration = configuration;   

As you can see, the difference here is that we embed the Amazon Cognito identity pool ID instead of your access key and secret key. At first, you may wonder why this is any more secure. The biggest difference is that rather than using a single set of credentials for all users of your app, each user is issued unique credentials for calling your AWS resources. Amazon Cognito provides this unique user identifier for the current user of your app and facilitates user login with social login providers like Amazon, Facebook, Twitter, Google, and any OpenID Connect-compatible provider, or your own user authentication system.

Anyone who reverse engineers your application and retrieves the identity pool doesn't gain additional access. The identity pool is not secret. Anyone who uses it will get a different Amazon Cognito ID. You can easily prevent him or her from seeing data from your other users using the techniques described below.

Protecting User-Specific Data with the Cognito ID

Every user of your app, even guests, will get a unique identifier called a Cognito ID, which looks something like this:

us-east-1:1234abcd-1234-abcd-ab12-abcd1234abcd

For authenticated users, the same ID will be issued whenever they log in to your app, even if it is from a different device or even if they use multiple social providers. You can use the Cognito ID to protect assets and user data. For example, you can store the ID as the owner in a column in a DynamoDB table, and use IAM policies to prevent anyone else from reading or changing the user's data. For more information, see IAM Roles in the Amazon Cognito documentation. Similarly, you can use the ID as a bucket prefix on Amazon S3 where the user's photos are stored so that only the user can download or upload photos to the bucket. Just using this identifier gives your users a great deal of extra security because even if a malicious user gets enough information to make calls into your AWS resources, each user's data is behind a unique identifier, making it next to impossible for someone to access another user's data.

Authenticated Users

Authenticated users are more trustworthy so you can grant them more access to resources. To authenticate a user with Amazon Cognito, you pass a token from the login provider. When users sign in with your app using a social provider like Facebook, your app's code receives a token from the social provider's SDK. That token is passed along to Amazon Cognito to help establish an identity, like so:

NSString *token = [FBSDKAccessToken currentAccessToken].tokenString; // currentAccessToken comes from the Facebook SDK
credentialsProvider.logins = @{ @(AWSCognitoLoginProviderKeyFacebook): token };

By authenticating the user you get additional layers of protection:

• First, the user logged in at the provider with a valid account. This increases the likelihood the user is a real person. You can be reasonably sure that one person doesn't have dozens or hundreds of accounts because most social login providers take steps to prevent such abuse.
• Second, the Facebook SDK and other social login provider SDKs take steps to increase the likelihood the login comes from your app. The implementation details vary, but generally they use the bundle identifier on iOS, which is provided as part of the provisioning process in the App Store. On Android, they generally leverage the fact the APKs for distribution are signed with the developer key. All bets are off on a jailbroken or rooted device, but these measures increase the likelihood the authentication request comes from your app. Nonetheless, we recommend you write your application as if a user can make any AWS call using his or her Cognito-provided credentials. In this way, your application will be resilient against any jailbroken, rooted, or otherwise modified devices and callers.

After Amazon Cognito receives the token, the service makes a call back to the provider to validate the identity of the token. The authentication flow looks like this:

Note the validation step. By validating the token with the provider, Amazon Cognito will detect scenarios in which the token has expired or been revoked by the provider. This can happen, for example, if the provider detects a fake or malicious account and disables it. If Amazon Cognito can't validate the token, it will not authenticate the user and issue authenticated credentials. The user won't be able to use your AWS resources with a bogus account.

Secure Your Mobile App with Amazon Cognito Today!

We've explained how Amazon Cognito can be used instead of embedding credentials into your apps, a practice security researchers have called "the weakest form of authentication." Rather than embedding credentials in your apps, use authenticated users with Amazon Cognito to increase the security of your app. Use the Amazon Cognito ID to lock down data to each authenticated user so that it cannot be discovered or read by a malicious user.

With the announcement of the S3 Transfer Utility, we deprecated the S3 Transfer Manager. This post is a guide to help developers currently using the Transfer Manager migrate to the new Transfer Utility. The guide is split into sections based on functionality, and shows how Transfer Manager code will change to work with the Transfer Utility. So lets get started!

Client Construction

The Transfer Utility has a single constructor, which requires an instance of AmazonS3Client (which we recommend setting the region on, prior to passing to the Transfer Utility), and the application context. As with the Transfer Manager, we recommend constructing the Transfer Utility client once, and using a single instance throughout your application. An example is shown below:

CognitoCachingCredentialsProvider credentialsProvider = new CognitoCachingCredentialsProvider(
context.getApplicationContext(),
YOUR_IDENTITY_POOL_ID,
Regions.US_EAST_1);

AmazonS3Client s3Client = new AmazonS3Client(credentialsProvider);

TransferUtility transferUtility = new TransferUtility(s3Client,context.getApplicationContext());

Permissions & Service Declaration

The Transfer Manager only requires the INTERNET permission. However, since the Transfer Utility automatically detects network state and pauses/resumes transfers based on the network state, your app will require the ACCESS_NETWORK_STATE permission as well.

<uses-permission android:name="android.permission.INTERNET" />  <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> 

The Transfer Utility is now based on an Android service, which must be declared in the AndroidManifest.xml within the Application tag.

<service android:name= "com.amazonaws.mobileconnectors.s3.transferutility.TransferService" android:enabled="true" />

Uploading and Downloading

The Transfer Manager has a plethora of APIs for uploading and downloading. Pausing transfers using the Transfer Manager is not possible with stream based uploads or downloads, or those using client-side encryption (which has separately been deprecated). Additionally, when using streams, developers must still specify the content length ahead of time. To create one coherent API, which can always be paused and resumed, the Transfer Utility has one single-file-based method for uploads, and downloads. All requests will need to be converted to the API below:

Uploading:

TransferObserver observer = transferUtility.upload(
MY_BUCKET,           // The S3 bucket to upload to
OBJECT_KEY,          // The key for the uploaded object          FILE_TO_UPLOAD       // The location of the file to be uploaded          );

Downloading:

TransferObserver observer = transferUtility.download(
MY_BUCKET,           // The S3 bucket to download from
OBJECT_KEY,          // The key for the object to download
FILE_TO_UPLOAD       // The name of the file to download
);  

Tracking Transfers

To track transfer progress with the Transfer Manager, developers pass an S3ProgressListener callback to upload or download, which periodically fires the method below.

public void progressChanged(ProgressEvent progressEvent);  

The ProgressEvent gives developers an integer code if the state of the transfer had changed, and would tell developers the amount of data transferred since the last progressChanged was fired.

The Transfer Utility returns a TransferObserver object when you call Upload/Download/Resume. You can also query for TransferObservers from anywhere within your app using the following APIs:

public TransferObserver getTransferById(int id)
public List<TransferObserver> getTransfersWithType(TransferType type)
public List<TransferObserver> getTransfersWithTypeAndState(TransferType type,
            TransferState state)

You can get the current state and progress from the TransferObserver, or if you are interested in continual updates you can call

public void setTransferListener(TransferListener listener)

on the TransferObserver, and the TransferListener will fire the following callbacks:

public void onStateChanged(int id, TransferState state);
public void onProgressChanged(int id, long bytesCurrent, long bytesTotal);
public void onError(int id, Exception ex);

So code relating to :

• progressEvent.getEventCode() will now be handled by the onStateChange() function, which now uses an enum to describe the state of the transfer.

• progressEvent.getBytesTransferred() will need to be updated to use the onProgressChanged() method. NOTE: bytesCurrent in onProgressChanged() represents the total number of bytes transferred, while the getBytesTransferred in the ProgressEvent class gives the number of bytes since the last ProgressEvent was fired.

Pausing Transfers

With the Transfer Manager, transfers using APIs involving I/O streams cannot be paused. For transfers that can be paused, developers call pause() on the Upload or Download object, or pass a callback to upload and download which fires when a transfer is able to be paused. In either case, a PersistableTransfer object is received, which then produces a String via the serialize() method. This String then has to be written to persistable storage by the developer. Migrating pause functionality to the Transfer Utility is easy, since all transfers can be paused and resumed. Additionally, the Transfer Utility stores all of the metadata about transfers to the local SQLite database, so developers do not need to persist anything. The Transfer Utility automatically pauses transfers when the app loses network connectivity, and will automatically resume them when the app regains connectivity. You can manually pause a single transfer using

public boolean pause(int id)

or pause uploads, downloads, or all transfers with

public void pauseAllWithType(TransferType type)

The transfer id can be retrieved from any TransferObserver instance, which can be queried for as described in the Tracking Transfers sections above. The only other consideration is that pausing will return false and do nothing unless the transfer is in one of the following states:

TransferState.IN_PROGRESS
TransferState.RESUMED_WAITING
TransferState.WAITING

Resuming Transfers

In Transfer Manager code, to resume an upload you first create a PersistableTransfer with the static deserializeFrom() method, passing it the String you received from calling serialize() on an Upload or Download. Then with the PersistableTransfer object, you call resume() from the TransferManager class.

The Transfer Utility handles persisting the transfer metadata, so all you need to do is call

public TransferObserver resume(int id)

where id is the id from a TransferObserver. If you do not have a TransferObserver you can query for one as described in the Tracking Transfers section above. Remember that if a transfer is paused because of a loss of network connectivity, it will automatically be resumed and there is no action you need to take. Transfers that are automatically paused and waiting for network connectivity will have the state TransferState.WAITING_FOR_NETWORK to distinguish them from manually paused transfers.

Copying Transfers

The Transfer Utility does not support a copy() API, because it is not a commonly used API on mobile. However you can accomplish much of the same functionality using the AmazonS3Client class copyObject() method shown below.

public CopyObjectResult copyObject(String sourceBucketName, String sourceKey,String destinationBucketName, String destinationKey)

Aborting Transfers Using the Transfer Manager you can abort a transfer by calling

public void abort();

on an Upload or Download object. With the Transfer Utility to abort a transfer you call

public boolean cancel(int id)

on the Transfer Utility class. Canceling a transfer using the Transfer Utility will not remove it from the local SQLite database, and it can still be queried for. To completely remove the transfer from local storage, you must first cancel the transfer (if it is running), and call the delete method shown below. It is an error to delete a running transfer without first canceling it.

public boolean deleteTransferRecord(int id)

For additional help using the Transfer Utility see:

The step by step Getting Started Guide

The Sample on GitHub (including tutorial)

The latest SDK API Reference

This guide is intended to make transitioning from the Transfer Manager to the Transfer Utility as easy and quick as possible. If you have any additional questions or feedback, do not hesitate to contact us: as a comment on this blog, a post on our forums, or as a GitHub issue.

Last year, as part of the Version 2 release of the AWS Mobile SDK for Android, we introduced the ability to pause and resume transfers. Since then, we have received helpful feedback from the community, and learned more about the needs of mobile developers like you. Today we are pleased to announce the introduction of a new and easier way to transfer data between your Android app and Amazon S3, the S3 Transfer Utility for the AWS SDK for Android.

What is difference between the Transfer Utility and the Transfer Manager?

The Transfer Utility is a new client, with many of the same features as the Transfer Manager, but designed to be simpler and more efficient to use.

Some of the feature enhancements include:

• It uses the local SQLite database to persist all metadata about transfers, allowing them to be paused and resumed without the developer having to serialize or persist any data.
• It utilizes native Android Services so you don't have to worry about threading or the app being killed.
• It automatically pauses and resumes transfers when internet connectivity is lost and regained.
• It has general configuration improvements for performance with S3 on mobile.

The detailed differences are described in the sections below.

Uploading and Downloading

The Transfer Manager has APIs that support the use of I/O streams. With these APIs, pausing and resuming was not possible. Additionally, you had to specify the content size ahead of time, further reducing the usefulness of streams. With the Transfer Utility there is one file based API for uploading and downloading, which you can always pause or resume (on top of the automatic pause and resume functionality described below).

TransferObserver observer = transferUtility.upload(
MY_BUCKET,           // The S3 bucket to upload to
OBJECT_KEY,          // The key for the uploaded object
FILE_TO_UPLOAD       // The location of the file to be uploaded
);

Downloading is equally simple:

TransferObserver observer = transferUtility.download(
MY_BUCKET,           // The S3 bucket to download from
OBJECT_KEY,          // The key for the object to download
FILE_TO_UPLOAD       // The name of the file to download
); 

Tracking Transfer Progress

The Transfer Utility makes tracking transfers more mobile friendly. The primary way of tracking transfers is through instances of the TransferObserver class. TransferObserver instances are returned from the download() and upload() methods. They are automatically saved to local storage and can be queried for based on id, type (upload, download, or any), or state (such as paused) from anywhere within the app as shown below.

public TransferObserver getTransferById(int id)
public List<TransferObserver> getTransfersWithType(TransferType type) 
public List<TransferObserver> getTransfersWithTypeAndState(TransferType type, TransferState state)

TransferObservers gives access to the state, the total bytes transferred thus far, the total bytes to transfer (for easily calculating progress bars), and a unique ID you can use to keep track of distinct transfers. You can also specify a TransferListener, which will be updated on state or progress change, as well as if an error occurs.

transferObserver.setTransferListener(new TransferListener() {

@Override
public void onStateChanged(int id, TransferState state){
//Do something on state change
}

@Override
public void onProgressChanged(int id, long bytesCurrent, long bytesTotal) {
//Do something on progress change.
}

@Override
public void onError(int id, Exception ex) {
//Do something on error
}
});

Pausing Transfers

With the Transfer Manager, there is no guarantee a transfer can be paused, and there are multiple ways to attempt to pause. Also, pauses require developers to serialize metadata about the transfer to persistent storage which they must manage.
The Transfer Utility handles persisting of all transfer metadata for you. If an app is killed, crashes, or loses internet connectivity, transfers are automatically paused. You can manually pause a transfer by id with pause(transferId), pause all downloads (or uploads) with pauseAllWithType(TransferType.DOWNLOAD), or pause all transfers with pauseAllWithType(TransferType.ANY).

Resuming Transfers

The Transfer Utility automatically pauses transfers in many scenarios. In the case that your transfer was paused due to loss of network connectivity, it will automatically resume when the network is available again. In the case that the transfer is manually paused, or the app is killed, it can be resumed with the resume(transferId) method.

Summary and Transfer Manager deprecation plan

Overall, we have built the Transfer Utility as an improvement and simplification over the Transfer Manager. We believe it fits better with the needs of customers and helps accelerate high quality app development.

The Transfer Utility will replace the Transfer Manager, and going forward the Transfer Manager will be deprecated. To help customers migrate from the Transfer Manager to the new Transfer Utility, we have posted a migration guide.

Additional help, and request for feedback

The step by step Getting Started Guide

The Sample on GitHub

The latest SDK API Reference

As always, we really appreciate community feedback: as a comment on this blog, a post on our forums, or as a GitHub issue.