Protecting against unintentional regressions to cleartext traffic in your Android apps

Protecting against unintentional regressions to cleartext traffic in your Android apps

Android Android N Featured HTTPS Security

Posted by Alex Klyubin, Android Security team

When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.

Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.

Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.

New protection mechanisms

For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.

Block cleartext traffic in production

To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.

You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.

Please note that WebView does not yet honor this feature.

And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.

Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.

Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.

Detect cleartext traffic during development

To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.

Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.

Declare finer-grained cleartext policy in Network Security Config

Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.

Next steps

It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!

As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at security@android.com.

Using Google Sign-In with your server

Using Google Sign-In with your server

Android Android Developer Security signing

Posted by Laurence Moroney, Developer Advocate

This is the third part in a blog series on using Google Sign-In on Android, and how you can take advantage of world-class security in your Android apps. In part 1, we spoke about the user experience improvements that are available to you. In part 2, we then took a deeper dive into the client-side changes to the Google Sign-In APIs that make coding a lot simpler.

In this post, we will demonstrate how you can use Google Sign-In with your backend. By doing so, users signing in on their device can be securely authenticated to access their data on your backend servers.

Using Credentials on your server

First, let’s take a look at what happens if a user signs in on your app, but they also need to authenticate for access to your back-end server. Consider this scenario: You’ve built an app that delivers food to users at their location. They sign into your app, and your app gets their identity. You store their address and order preferences in a database on your server.

Unless your server endpoints are protected with some authentication mechanism, attackers could read and write to your user database by simply guessing the email addresses of your users.

Figure 1. An attacker could submit a fake request to your server with an email address

This isn’t just a bad user experience, it’s a risk that customer data can be stolen and misused. You can prevent this by getting a token from Google when the user signs in to the app, and then passing this token to your server. Your server would then validate that this token really was issued by Google, to the desired user, and intended for your app (based on your audience setting, see below). At this point your server can know that it really is your user making the call, and not a nefarious attacker. It can then respond with the required details.

Figure 2. Attacker’s Forged Tokens will be rejected

Let’s take a look at the steps for doing this:

Step 1: Your Android app gets an ID token (*) after signing in with Google. There’s a great sample that demonstrates this here. To do this, the requestIdToken method is called when creating the GoogleSignInOptions object.

 GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)  
         .requestIdToken(getString(R.string.server_client_id))  
         .requestEmail()  
         .build();  

This requires you to get a client ID for your server. Details on how to obtain this are available here (see Step 4).

Once your Android app has the token, it can POST it over HTTPS to your server, which will then try to validate it.

(*) An ID token is represented using JSON Web Token, as defined by RFC7519 and the OpenID Connect spec. These are an open, industry standard method for representing claims securely between two parties.

Step 2: Your Server receives the token from your Android client. It should then validate the token with methods that are provided in the Google API Client libraries, in particular, verifying that it was issued by Google and that the intended audience is your server.

Your server can use the GoogleIdTokenVerifier class to verify the token and then extract the required identity data. The ‘sub’ field (available from the getSubject() method) provides a stable string identifier that should be used to identify your users even if their email address changes, and key them in your database. Other ID token fields are available, including the name, email address and photo URL. Here’s an example of a servlet that was tested on Google App Engine that can verify tokens using a provided library. These libraries allow you to verify the token locally without a network call for every verification.

 GoogleIdTokenVerifier verifier = new GoogleIdTokenVerifier.Builder(transport, jsonFactory)  
       // Here is where the audience is set -- checking that it really is your server  
       // based on your Server’s Client ID  
       .setAudience(Arrays.asList(ENTER_YOUR_SERVER_CLIENT_ID_HERE))  
       // Here is where we verify that Google issued the token  
      .setIssuer("https://accounts.google.com").build();  
 GoogleIdToken idToken = verifier.verify(idTokenString);  
 if (idToken != null) {  
       Payload payload = idToken.getPayload();  
       String userId = payload.getSubject();   
       // You can also access the following properties of the payload in order  
       // for other attributes of the user. Note that these fields are only  
       // available if the user has granted the 'profile' and 'email' OAuth  
       // scopes when requested. (e.g. you configure GoogleSignInOptions like   
       // the sample code above and got a successful GoogleSignInResult)   
       // Note that some fields may still be null.  
       String email = payload.getEmail();  
       boolean emailVerified = Boolean.valueOf(payload.getEmailVerified());  
       String name = (String) payload.get("name");  
       String pictureUrl = (String) payload.get("picture");  
       String locale = (String) payload.get("locale");  
       String familyName = (String) payload.get("family_name");  
       String givenName = (String) payload.get("given_name");  

Note that if you have an existing app using GoogleAuthUtil to get a token to pass to your backend, you should switch to the latest ID token validation libraries and mechanisms described above. We’ll describe recommendations for server-side best practices in a future post.

This post demonstrates how to use authentication technologies to ensure your user is who they claim they are. In the next post, we’ll cover using the Google Sign-In API for authorization, so that users can, for example, access Google services such as Google Drive from within your app and backend service.

You can learn more about authentication technologies from Google at the Google Identity Platform developers site.

One tap sign-up and automatic sign-in without password entry using Smart Lock

One tap sign-up and automatic sign-in without password entry using Smart Lock

Google Play Google Play services Security

Posted Steven Soneff, Product Manager, Google Identity

More than 30 percent of users signing in to the Netflix app on Android no longer have to enter a password thanks to Google’s Smart Lock for Passwords. Learn more

It’s been six months since the launch of Smart Lock for Passwords and we are thrilled with the impact it has made in getting users signed back in to many of their favorite apps. Million of users have been seamlessly signed in using saved accounts for over 40 major apps when going from one Android device to another or from Chrome to Android and vice versa. This first wave of developers have realized that removing the friction of sign-in increases user re-engagement, monetization opportunities, and cross-device analytics, improving the value and experience of their users.

The New York Times has seen 80 percent of their new sign-in events assisted by Smart Lock. Meanwhile, the Netflix customer support team found over a 20 percent reduction in support cases related to account recovery for their Android user base. Users strongly choose to stay signed in across their devices with over 60 percent opt-in to save sign-in info for major Smart Lock-enabled apps. And many of these developers were able to realize these gains with less than a day’s work by making only client-side changes to their app. To learn more about Smart Lock for Passwords, visit our developer site.

What’s New

With the latest release of Google Play services, we’ve made some enhancements to the Smart Lock for Passwords API to help you sign up new users or sign existing users in more quickly. Using the new method to retreive sign-in "hints", your users will see a dialog with a list of email addresses that they can select in a single tap:

This new experience is particularly important with Android Marshmallow’s runtime permissions model. To simplify and improve the user experience, this dialog doesn’t require device permissions and includes any email addresses that the user has saved with Smart Lock, not just the accounts on the device. This means that you can improve your sign-in and sign-up flows so that most of your users never need to type their email address. Apps using this dialog have seen nearly three-quarters of users select an entry shown, improving sign-up rates.

Next, after the user has tapped and shared their email address, with some server-side support, a sophisticated app can fully tailor the sign-in flow. By using the email address, you can check your database to see if a user has already registered for an account. You can then intelligently render either the sign-in or sign-up screens with the user’s email address, name and profile photo pre-filled.

Skipping the Password Altogether

It’s possible to do even better: if the user chooses a Google account from the dialog, an OpenID Connect ID Token is provided. This can save your app from having to verify email addresses for new accounts or skip the password altogether for returning users. ID tokens are also used by Google Sign-In to authenticate in place of a password, and are a strong assertion from Google that the owner of the given email address is present. If users on your site recover their passwords by email, then an ID token from Google is giving you the same assertion that the user owns the email address and is signed in to this device with that email address. You can also consider presence of ID token in addition to the password a signal to prevent password cracking and abuse.

We’ve found that the majority of users on Android use the email address that’s signed in on their device as their account for third-party apps, so this means seamlessly signing in most of your returning users, or creating a new account with one tap!

Code Samples and User Flow

Here’s a recap of how to streamline your app’s sign-in flow:

When your app starts, request stored Smart Lock credentials, and go straight to the user’s content when possible. Create a request for password or Google credentials, then listen for a callback with the results. Sign in immediately if stored user credentials (username / password, ID token, etc.) is available.

 CredentialRequest request = new CredentialRequest.Builder()  
     .setSupportsPasswordLogin(true)  
     .setAccountTypes(IdentityProviders.GOOGLE) // you can add other identity providers, too  
     .build();  
 Auth.CredentialsApi.request(mCredentialsApiClient, request).setResultCallback(  
     new ResultCallback<CredentialRequestResult>() {  
       public void onResult(CredentialRequestResult result) {  
         if (result.getStatus().isSuccess()) {  
          handleCredential(result.getCredential()) // sign in automatically!  

When the user wants or needs to sign in with their email address, show the picker to help them input it. Create a request for hints, pass control to the system to display UI, and handle the result when the user selects an entry.

 HintRequest hintRequest = new HintRequest.Builder()  
     .setEmailAddressIdentifierSupported(true)  
     .setAccountTypes(IdentityProviders.GOOGLE)  
     .build();  
 PendingIntent intent = Auth.CredentialsApi.getHintPickerIntent(mCredentialsApiClient,   
                                 hintRequest);  
 startIntentSenderForResult(intent.getIntentSender(), RC_HINT, null, 0, 0, 0);  
 ...  
 onActivityResult(int requestCode, int resultCode, Intent data) {  
   switch (requestCode) {  
     case RC_HINT:  
       if (resultCode == RESULT_OK) {  
         Credential hint = data.getParcelableExtra(Credential.EXTRA_KEY);  
         handleCredential(hint);  

The result from the hint request will contain the user’s selected identifier and an ID token if it is a Google account on the device. If you use the ID token, you must send and verify it on your server for security. Note that this token will also include a claim if the email address is verified, so you can skip any email verification step. If no token is present, or you can’t do server-side validation, just pre-fill the email field for the user.

 handleCredential(Credential credential) {  
   if (!credential.getIdTokens().isEmpty()) {  
     credential.getIdTokens().get(0).getIdToken(); // send the ID token string to your server  
   } else {  
     // otherwise, try fill the sign-in form fields and submit if password is available  
     mEmailField.setText(credential.getId());  
     mPasswordField.setText(credential.getPassword());  

On your server, after validating the ID token, use it to create an account or sign the user in without need for their password. Google provides libraries to do token validation, or you can use an open-source implementation. The ID token contains the user’s email address, and you can look it up in your database to determine whether an account needs to be created.

 GoogleIdTokenVerifier verifier = new GoogleIdTokenVerifier.Builder(transport, jsonFactory)  
         .setIssuer("https://accounts.google.com")  
         .setAudience(Arrays.asList(String.format("android://%s@%s",   
                             SHA512_HASH, PACKAGE_NAME)))  
         .build();  
 ...  
     GoogleIdToken idToken = verifier.verify(idTokenString);  
     if (idToken == null) {  
       Log.w(TAG, "ID Token Verification Failed, check the README for instructions.");  
       return;  
     }  
     GoogleIdToken.Payload payload = idToken.getPayload();  
     Log.d(TAG, "IdToken:Email:" + payload.getEmail());  
     Log.d(TAG, "IdToken:EmailVerified:" + payload.getEmailVerified());  
     // based on the email address, determine whether you need to create account   
     // or just sign user in  

Then save the user’s email address credential “hint” in Smart Lock for automatic sign-in next time. Simply call the Credentials API save method with the hint and either set the user-entered password, or set the account type if you logged the user in with an ID token.

 Credential credential = new Credential.Builder(hint)  
     // if you signed in with ID token,   
     // set account type to the URL for your app (instead of a password field)  
     //.setAccountType("https://yourdomain.com")   
     .setPassword(password)  
     .build();  
 Auth.CredentialsApi.save(mCredentialsApiClient, credential).setResultCallback(  
     new ResolvingResultCallbacks<Status>(this, RC_SAVE) {  

Learn More

To learn more about the basics of a Smart Lock API integration, check out our code lab for a step-by-step guide. We’re excited to make authentication without passwords possible via Smart Lock and are looking forward to a world where not only credentials can be managed more effectively, but apps can get their users signed in and up quickly and securely without the friction of typing usernames and passwords. We’d love to hear your feedback or questions!