Tag Archives: Security

Trust but verify attestation with revocation

Posted by Rob Barnes & Shawn Willden, Android Security & Privacy Team
[Cross-posted from the Android Developers Blog]

Billions of people rely on their Android-powered devices to securely store their sensitive information. A vital component of the Android security stack is the key attestation system. Android devices since Android 7.0 are able to generate an attestation certificate that attests to the security properties of the device’s hardware and software. OEMs producing devices with Android 8.0 or higher must install a batch attestation key provided by Google on each device at the time of manufacturing.
These keys might need to be revoked for a number of reasons including accidental disclosure, mishandling, or suspected extraction by an attacker. When this occurs, the affected keys must be immediately revoked to protect users. The security of any Public-Key Infrastructure system depends on the robustness of the key revocation process.
All of the attestation keys issued so far include an extension that embeds a certificate revocation list (CRL) URL in the certificate. We found that the CRL (and online certificate status protocol) system was not flexible enough for our needs. So we set out to replace the revocation system for Android attestation keys with something that is flexible and simple to maintain and use.
Our solution is a single TLS-secured URL (https://android.googleapis.com/attestation/status) that returns a list containing all revoked Android attestation keys. This list is encoded in JSON and follows a strict format defined by JSON schema. Only keys that have non-valid status appear in the list, so it is not an exhaustive list of all issued keys.
This system allows us to express more nuance about the status of a key and the reason for the status. A key can have a status of REVOKED or SUSPENDED, where revoked is permanent and suspended is temporary. The reason for the status is described as either KEY_COMPROMISE, CA_COMPROMISE, SUPERSEDED, or SOFTWARE_FLAW. A complete, up-to-date list of statuses and reasons can be found in the developer documentation.
The CRL URLs embedded in existing batch certificates will continue to operate. Going forward, attestation batch certificates will no longer contain a CRL extension. The status of these legacy certificates will also be included in the attestation status list, so developers can safely switch to using the attestation status list for both current and legacy certificates. An example of how to correctly verify Android attestation keys is included in the Key Attestation sample.

Trust but verify attestation with revocation

Posted by Rob Barnes & Shawn Willden, Android Security & Privacy Team

Billions of people rely on their Android-powered devices to securely store their sensitive information. A vital component of the Android security stack is the key attestation system. Android devices since Android 7.0 are able to generate an attestation certificate that attests to the security properties of the device’s hardware and software. OEMs producing devices with Android 8.0 or higher must install a batch attestation key provided by Google on each device at the time of manufacturing.

These keys might need to be revoked for a number of reasons including accidental disclosure, mishandling, or suspected extraction by an attacker. When this occurs, the affected keys must be immediately revoked to protect users. The security of any Public-Key Infrastructure system depends on the robustness of the key revocation process.

All of the attestation keys issued so far include an extension that embeds a certificate revocation list (CRL) URL in the certificate. We found that the CRL (and online certificate status protocol) system was not flexible enough for our needs. So we set out to replace the revocation system for Android attestation keys with something that is flexible and simple to maintain and use.

Our solution is a single TLS-secured URL (https://android.googleapis.com/attestation/status) that returns a list containing all revoked Android attestation keys. This list is encoded in JSON and follows a strict format defined by JSON schema. Only keys that have non-valid status appear in the list, so it is not an exhaustive list of all issued keys.

This system allows us to express more nuance about the status of a key and the reason for the status. A key can have a status of REVOKED or SUSPENDED, where revoked is permanent and suspended is temporary. The reason for the status is described as either KEY_COMPROMISE, CA_COMPROMISE, SUPERSEDED, or SOFTWARE_FLAW. A complete, up-to-date list of statuses and reasons can be found in the developer documentation.

The CRL URLs embedded in existing batch certificates will continue to operate. Going forward, attestation batch certificates will no longer contain a CRL extension. The status of these legacy certificates will also be included in the attestation status list, so developers can safely switch to using the attestation status list for both current and legacy certificates. An example of how to correctly verify Android attestation keys is included in the Key Attestation sample.

10 things to know about Android 10

https://1.bp.blogspot.com/-1m5fpSI-6n8/XW9U2K1ZmUI/AAAAAAAAA4Y/jJ-kRw1JXkoEgFeJyE5ZidZqAp_bulAjwCLcBGAs/s1600/Screenshot%2B2019-09-04%2Bat%2B11.36.25%2BAM.png Dave Burke VP Engineering


Android 10 is here! With this release, we focused on making your everyday life easier with features powered by on-device machine learning, as well as supporting new technologies like Foldables and 5G. At the same time, with almost 50 changes related to privacy and security, Android 10 gives you greater protection, transparency, and control over your data. This builds on top of our ongoing commitment to provide industry-leading security and privacy protections on Android. We also built new tools that empower people of all abilities, and help you find the right balance with technology.

Here are the 10 things you should know, centered on innovation, security and privacy and digital wellbeing: 

Simpler, smarter, and more helpful



1. Smart Reply now suggests actions. So when someone sends you a message with an address or a YouTube video, you can open and navigate in Google Maps or open up the video in YouTube—no copying and pasting required. And Smart Reply now works across all your favorite messaging apps.
2. Come to the dark side… with Dark Theme. You can enable Dark Theme for your entire phone or for specific apps like Photos and Calendar. It’s easier on your eyes, and your phone battery too. 
3. Take advantage of larger, edge-to-edge screens with the new gesture navigation. With simple swipes, you can go backwards, pull up the homescreen, and fluidly move between tasks. After switching, you won’t want to go back to visible buttons. 
4. With a single tap, Live Caption will automatically caption videos, podcasts and audio messages across any app—even stuff you record yourself. Live Caption will become available this fall, starting with Pixel.

New privacy and security features put you in control

5. You can choose to only share location data with apps while you’re using them. You’ll also receive reminders when an app that you are not actively using is accessing your location, so you can decide whether or not to continue sharing. 
6. In a new Privacy section under Settings, you’ll find important controls like Web & App Activity and Ad Settings in one place. 
7. With Google Play system updates, important security and privacy fixes can now be sent to your phone from Google Play, in the same way your apps update. So you get these fixes as soon as they’re available, without having to wait for a full OS update. 

Find the right balance with technology for you and your family

8. You have greater control over where and when notifications will alert you. Mark notifications as “Silent” and they won’t make noise or appear on your lockscreen, so you're only alerted by notifications when you want to be.
9. Now Family Link is part of every device running Android 9 or 10, right in settings under Digital Wellbeing. Parents can use these tools to set digital ground rules like daily screen time limits, device bedtime, time limits on specific apps, and more. They can also review the apps children install on their devices, as well as their usage.
10. Want to be in the zone but not off the grid? Digital Wellbeing now brings you Focus mode. Select the apps you find distracting—such as email or the news—and silence them until you come out of Focus mode. Sign up for the Beta to try it.
There’s lots more in Android 10, including a new enterprise feature that lets you use different keyboards for your personal and work profiles, app timers for specific websites so you can balance your time on the web, new gender-inclusive emoji, and support for direct audio streaming to hearing aid devices. 
Android 10 begins rolling out to Pixel phones today, and we’re working with our partners to launch and upgrade devices to Android 10 this year. Learn more at android.com/10.


Posted by Dave Burke, VP of Engineering

Expanding bug bounties on Google Play

Posted by Adam Bacchus, Sebastian Porst, and Patrick Mutchler — Android Security & Privacy

[Cross-posted from the Android Developers Blog]

We’re constantly looking for ways to further improve the security and privacy of our products, and the ecosystems they support. At Google, we understand the strength of open platforms and ecosystems, and that the best ideas don’t always come from within. It is for this reason that we offer a broad range of vulnerability reward programs, encouraging the community to help us improve security for everyone. Today, we’re expanding on those efforts with some big changes to Google Play Security Reward Program (GPSRP), as well as the launch of the new Developer Data Protection Reward Program (DDPRP).

Google Play Security Reward Program Scope Increases

We are increasing the scope of GPSRP to include all apps in Google Play with 100 million or more installs. These apps are now eligible for rewards, even if the app developers don’t have their own vulnerability disclosure or bug bounty program. In these scenarios, Google helps responsibly disclose identified vulnerabilities to the affected app developer. This opens the door for security researchers to help hundreds of organizations identify and fix vulnerabilities in their apps. If the developers already have their own programs, researchers can collect rewards directly from them on top of the rewards from Google. We encourage app developers to start their own vulnerability disclosure or bug bounty program to work directly with the security researcher community.

Vulnerability data from GPSRP helps Google create automated checks that scan all apps available in Google Play for similar vulnerabilities. Affected app developers are notified through the Play Console as part of the App Security Improvement (ASI) program, which provides information on the vulnerability and how to fix it. Over its lifetime, ASI has helped more than 300,000 developers fix more than 1,000,000 apps on Google Play. In 2018 alone, the program helped over 30,000 developers fix over 75,000 apps. The downstream effect means that those 75,000 vulnerable apps are not distributed to users until the issue is fixed.

To date, GPSRP has paid out over $265,000 in bounties. Recent scope and reward increases have resulted in $75,500 in rewards across July & August alone. With these changes, we anticipate even further engagement from the security research community to bolster the success of the program.

Introducing the Developer Data Protection Reward Program

Today, we are also launching the Developer Data Protection Reward Program. DDPRP is a bounty program, in collaboration with HackerOne, meant to identify and mitigate data abuse issues in Android apps, OAuth projects, and Chrome extensions. It recognizes the contributions of individuals who help report apps that are violating Google Play, Google API, or Google Chrome Web Store Extensions program policies.

The program aims to reward anyone who can provide verifiably and unambiguous evidence of data abuse, in a similar model as Google’s other vulnerability reward programs. In particular, the program aims to identify situations where user data is being used or sold unexpectedly, or repurposed in an illegitimate way without user consent. If data abuse is identified related to an app or Chrome extension, that app or extension will accordingly be removed from Google Play or Google Chrome Web Store. In the case of an app developer abusing access to Gmail restricted scopes, their API access will be removed. While no reward table or maximum reward is listed at this time, depending on impact, a single report could net as large as a $50,000 bounty.

As 2019 continues, we look forward to seeing what researchers find next. Thank you to the entire community for contributing to keeping our platforms and ecosystems safe. Happy bug hunting!

Expanding bug bounties on Google Play

Posted by Adam Bacchus, Sebastian Porst, and Patrick Mutchler — Android Security & Privacy

We’re constantly looking for ways to further improve the security and privacy of our products, and the ecosystems they support. At Google, we understand the strength of open platforms and ecosystems, and that the best ideas don’t always come from within. It is for this reason that we offer a broad range of vulnerability reward programs, encouraging the community to help us improve security for everyone. Today, we’re expanding on those efforts with some big changes to Google Play Security Reward Program (GPSRP), as well as the launch of the new Developer Data Protection Reward Program (DDPRP).

Google Play Security Reward Program Scope Increases

We are increasing the scope of GPSRP to include all apps in Google Play with 100 million or more installs. These apps are now eligible for rewards, even if the app developers don’t have their own vulnerability disclosure or bug bounty program. In these scenarios, Google helps responsibly disclose identified vulnerabilities to the affected app developer. This opens the door for security researchers to help hundreds of organizations identify and fix vulnerabilities in their apps. If the developers already have their own programs, researchers can collect rewards directly from them on top of the rewards from Google. We encourage app developers to start their own vulnerability disclosure or bug bounty program to work directly with the security researcher community.

Vulnerability data from GPSRP helps Google create automated checks that scan all apps available in Google Play for similar vulnerabilities. Affected app developers are notified through the Play Console as part of the App Security Improvement (ASI) program, which provides information on the vulnerability and how to fix it. Over its lifetime, ASI has helped more than 300,000 developers fix more than 1,000,000 apps on Google Play. In 2018 alone, the program helped over 30,000 developers fix over 75,000 apps. The downstream effect means that those 75,000 vulnerable apps are not distributed to users until the issue is fixed.

To date, GPSRP has paid out over $265,000 in bounties. Recent scope and reward increases have resulted in $75,500 in rewards across July & August alone. With these changes, we anticipate even further engagement from the security research community to bolster the success of the program.

Introducing the Developer Data Protection Reward Program

Today, we are also launching the Developer Data Protection Reward Program. DDPRP is a bounty program, in collaboration with HackerOne, meant to identify and mitigate data abuse issues in Android apps, OAuth projects, and Chrome extensions. It recognizes the contributions of individuals who help report apps that are violating Google Play, Google API, or Google Chrome Web Store Extensions program policies.

The program aims to reward anyone who can provide verifiably and unambiguous evidence of data abuse, in a similar model as Google’s other vulnerability reward programs. In particular, the program aims to identify situations where user data is being used or sold unexpectedly, or repurposed in an illegitimate way without user consent. If data abuse is identified related to an app or Chrome extension, that app or extension will accordingly be removed from Google Play or Google Chrome Web Store. In the case of an app developer abusing access to Gmail restricted scopes, their API access will be removed. While no reward table or maximum reward is listed at this time, depending on impact, a single report could net as large as a $50,000 bounty.

As 2019 continues, we look forward to seeing what researchers find next. Thank you to the entire community for contributing to keeping our platforms and ecosystems safe. Happy bug hunting!

Protecting Chrome users in Kazakhstan

Posted by Andrew Whalley, Chrome Security

When making secure connections, Chrome trusts certificates that have been locally installed on a user's computer or mobile device. This allows users to run tools to inspect and debug connections during website development, or for corporate environments to intercept and monitor internal traffic. It is not appropriate for this mechanism to be used to intercept traffic on the public internet.

In response to recent actions by the Kazakhstan government, Chrome, along with other browsers, has taken steps to protect users from the interception or modification of TLS connections made to websites.

Chrome will be blocking the certificate the Kazakhstan government required users to install:

Common Name
Qaznet Trust Network
SHA-256 Fingerprint
00:30:9C:73:6D:D6:61:DA:6F:1E:B2:41:73:AA:84:99:44:C1:68:A4:3A:15:
BF:FD:19:2E:EC:FD:B6:F8:DB:D2
SHA-256 of Subject Public Key Info
B5:BA:8D:D7:F8:95:64:C2:88:9D:3D:64:53:C8:49:98:C7:78:24:91:9B:64:
EA:08:35:AA:62:98:65:91:BE:50


The certificate has been added to CRLSet. No action is needed by users to be protected. In addition, the certificate will be added to a blocklist in the Chromium source code and thus should be included in other Chromium based browsers in due course.

How Google adopted BeyondCorp: Part 2 (devices)

Posted by Matt McDonald, Software Engineer, and Sebastian Harl, Software Engineer 


Intro

This is the second post in a series of four, in which we set out to revisit various BeyondCorp topics and share lessons that were learnt along the internal implementation path at Google.

The first post in this series focused on providing necessary context for how Google adopted BeyondCorp. This post will focus on managing devices - how we decide whether or not a device should be trusted and why that distinction is necessary. Device management provides both the data and guarantees required for making access decisions by securing the endpoints and providing additional context about it.

How do we manage devices?

At Google, we use the following principles to run our device fleet securely and at scale:
  • Secure default settings at depth with central enforcement
  • Ensure a scalable process
  • Invest in fleet testing, monitoring, and phased rollouts
  • Ensure high quality data
Secure default settings

Defense in depth requires us to layer our security defenses such that an attacker would need to pass multiple controls in an attack. To uphold this defensive position at scale, we centrally manage and measure various qualities of our devices, covering all layers of the platform;
  • Hardware/firmware configuration
  • Operating system and software
  • User settings and modifications
We use automated configuration management systems to continuously enforce our security and compliance policies. Independently, we observe the state of our hardware and software. This allows us to determine divergence from the expected state and verify whether it is an anomaly.

Where possible, our platforms use native OS capabilities to protect against malicious software, and we extend those capabilities across our platforms with custom and commercial tooling.

Scalable process

Google manages a fleet of several hundred thousand client devices (workstations, laptops, mobile devices) for employees who are spread across the world. We scale the engineering teams who manage these devices by relying on reviewable, repeatable, and automated backend processes and minimizing GUI-based configuration tools. By using and developing open-source software and integrating it with internal solutions, we reach a level of flexibility that allows us to manage fleets at scale without sacrificing customizability for our users. The focus is on operating system agnostic server and client solutions, where possible, to avoid duplication of effort.

Software for all platforms is provided by repositories which verify the integrity of software packages before making them available to users. The same system is used for distributing configuration settings and management tools, which enforce policies on client systems using the open-source configuration management system Puppet, running in standalone mode. In combination, this allows us to easily scale infrastructure and management horizontally as described in more detail and with examples in one of our BeyondCorp whitepapers, Fleet Management at Scale.

All device management policies are stored in centralized systems which allow settings to be applied both at the fleet and the individual device level. This way policy owners and device owners can manage sensible defaults or per-device overrides in the same system, allowing audits of settings and exceptions. Depending on the type of exception, they may either be managed self-service by the user, require approval from appropriate parties, or affect the trust level of the affected device. This way, we aim to guarantee user satisfaction and security simultaneously.

Fleet testing, monitoring, and phased rollouts

Applying changes at scale to a large heterogeneous fleet can be challenging. At Google, we have automated test labs which allow us to test changes before we deploy them to the fleet. Rollouts to the client fleet usually follow multiple stages and random canarying, similar to common practices with service management. Furthermore, we monitor various status attributes of our fleet which allows us to detect issues before they spread widely.

High quality data

Device management depends on the quality of device data. Both configuration and trust decisions are keyed off of inventory information. At Google, we track all devices in centralized asset management systems. This allows us to not only observe the current (runtime) state of a device, but also whether it’s a legitimate Google device. These systems store hardware attributes as well as the assignment and status of devices, which lets us match and compare prescribed values to those which are observed.

Prior to implementing BeyondCorp, we performed a fleet-wide audit to ensure the quality of inventory data, and we perform smaller audits regularly across the fleet. Automation is key to achieving this, both for entering data initially and for detecting divergence at later points. For example, instead of having a human enter data into the system manually, we use digital manifests and barcode scanners as much as possible.

How do we figure out whether devices are trustworthy?

After appropriate management systems have been put in place, and data quality goals have been met, the pertinent security information related to a device can be used to establish a "trust" decision as to whether a given action should be allowed to be performed from the device.



High level architecture for BeyondCorp


This decision can be most effectively made when an abundance of information about the device is readily available. At Google, we use an aggregated data pipeline to gather information from various sources, which each contain a limited subset of knowledge about a device and its history, and make this data available at the point when a trust decision is being made.

Various systems and repositories are employed within Google to perform collection and storage of device data that is relevant to security. These include tools like asset management repositories, device management solutions, vulnerability scanners, and internal directory services, which contain information and state about the multitude of physical device types (e.g., desktops, laptops, phones, tablets), as well as virtual desktops, used by employees at the company.

Having data from these various types of information systems available when making a trust decision for a given device can certainly be advantageous. However, challenges can present themselves when attempting to correlate records from a diverse set of systems which may not have a clear, consistent way to reference the identity of a given device. The challenge of implementation has been offset by the gains in security policy flexibility and improvements in securing our data.

What lessons did we learn?
As we rolled out BeyondCorp, we iteratively improved our fleet management and inventory processes as outlined above. These improvements are based on various lessons we learned around data quality challenges.

Audit your data ahead of implementing BeyondCorp

Data quality issues and inaccuracies are almost certain to be present in an asset management system of any substantial size, and these issues must be corrected before the data can be utilized in a manner which will have a significant impact on user experience. Having the means to compare values that have been manually entered into such systems against similar data that has been collected from devices via automation can allow for the correction of discrepancies, which may interrupt the intended behavior of the system.

Prepare to encounter unforeseen data quality challenges

Numerous data incorrectness scenarios and challenging issues are likely to present themselves as the reliance on accurate data increases. For example, be prepared to encounter issues with data ingestion processes that rely on transcribing device identifier information, which is physically labeled on devices or their packaging, and may incorrectly differ from identifier data that is digitally imprinted on the device.

In addition, over reliance on the assumed uniqueness of certain device identifiers can sometimes be problematic in the rare cases where conventionally unique attributes, like serial numbers, can appear more than once in the device fleet (this can be especially exacerbated in the case of virtual desktops, where such identifiers may be chosen by a user without regard for such concerns).

Lastly, routine maintenance and hardware replacements performed on employee devices can result in ambiguous situations with regards to the "identity" of a device. When internal device components, like network adapters or mainboards, are found to be defective and replaced, the device's identity can be changed into a state which no longer matches the known inventory data if care is not taken to correctly reflect such changes. 

Implement controls to maintain high quality asset inventory

After inventory data has been brought to an acceptable correctness level, mechanisms should be put into place to limit the ability for new inaccuracies to be introduced. For example, at Google, data correctness checks have been integrated into the provisioning process for new devices so that inventory records must be correct before a device can be successfully imaged with an operating system, ensuring that the device will meet required data accuracy standards before being delivered to an employee.

Next time
In the next post in this series, we will discuss a tiered access approach, how to create rule-based trust and the lessons we’ve learned through that process.

In the meantime, if you want to learn more, you can check out the BeyondCorp research papers. In addition, getting started with BeyondCorp is now easier using zero trust solutions from Google Cloud (context-aware access) and other enterprise providers.

Thank you to the editors of the BeyondCorp blog post series, Puneet Goel (Product Manager), Lior Tishbi (Program Manager), and Justin McWilliams (Engineering Manager).

New Research: Lessons from Password Checkup in action

Posted by Jennifer Pullman, Kurt Thomas, and Elie Bursztein, Spam and Abuse research

Back in February, we announced the Password Checkup extension for Chrome to help keep all your online accounts safe from hijacking. The extension displays a warning whenever you sign in to a site using one of over 4 billion usernames and passwords that Google knows to be unsafe due to a third-party data breach. Since our launch, over 650,000 people have participated in our early experiment. In the first month alone, we scanned 21 million usernames and passwords and flagged over 316,000 as unsafe---1.5% of sign-ins scanned by the extension.
Today, we are sharing our most recent lessons from the launch and announcing an updated set of features for the Password Checkup extension. Our full research study, available here, will be presented this week as part of the USENIX Security Symposium.

Which accounts are most at risk?

Hijackers routinely attempt to sign in to sites across the web with every credential exposed by a third-party breach. If you use strong, unique passwords for all your accounts, this risk disappears. Based on anonymous telemetry reported by the Password Checkup extension, we found that users reused breached, unsafe credentials for some of their most sensitive financial, government, and email accounts. This risk was even more prevalent on shopping sites (where users may save credit card details), news, and entertainment sites.

In fact, outside the most popular web sites, users are 2.5X more likely to reuse vulnerable passwords, putting their account at risk of hijacking.
Anonymous telemetry reported by Password Checkup extension shows that users most often reuse vulnerable passwords on shopping, news, and entertainment sites.


Helping users re-secure their unsafe passwords

Our research shows that users opt to reset 26% of the unsafe passwords flagged by the Password Checkup extension. Even better, 60% of new passwords are secure against guessing attacks—meaning it would take an attacker over a hundred million guesses before identifying the new password.
Improving the Password Checkup extension

Today, we are also releasing two new features for the Password Checkup extension. The first is a direct feedback mechanism where users can inform us about any issues that they are facing via a quick comment box. The second gives users even more control over their data. It allows users to opt-out of the anonymous telemetry that the extension reports, including the number of lookups that surface an unsafe credential, whether an alert leads to a password change, and the domain involved for improving site coverage. By design, the Password Checkup extension ensures that Google never learns your username or password, regardless of whether you enable telemetry, but we still want to provide this option if users would prefer not to share this information.


We're continuing to improve the Password Checkup extension and exploring ways to implement its technology into Google products. For help keeping all your online accounts safe from hijacking, you can install the Password Checkup extension here today.

Making authentication even easier with FIDO2-based local user verification for Google Accounts

Posted by Dongjing He, Software Engineer and Christiaan Brand, Product Manager 

Passwords, combined with Google's automated protections, help secure billions of users around the world. But, new security technologies are surpassing passwords in terms of both strength and convenience. With this in mind, we are happy to announce that you can verify your identity by using your fingerprint or screen lock instead of a password when visiting certain Google services. The feature is available today on Pixel devices and coming to all Android 7+ devices over the next few days.



Simpler authentication experience when viewing your saved password for a website on passwords.google.com


These enhancements are built using the FIDO2 standards, W3C WebAuthn and FIDO CTAP, and are designed to provide simpler and more secure authentication experiences. They are a result of years of collaboration between Google and many other organizations in the FIDO Alliance and the W3C.

An important benefit of using FIDO2 versus interacting with the native fingerprint APIs on Android is that these biometric capabilities are now, for the first time, available on the web, allowing the same credentials be used by both native apps and web services. This means that a user only has to register their fingerprint with a service once and then the fingerprint will work for both the native application and the web service.

Note that your fingerprint is never sent to Google’s servers - it is securely stored on your device, and only a cryptographic proof that you’ve correctly scanned it is sent to Google’s servers. This is a fundamental part of the FIDO2 design.

Here is how it works

Google is using the FIDO2 capability on Android to register a platform-bound FIDO credential. We remember the credential for that specific Android device. Now, when the user visits a compatible service, such as passwords.google.com, we issue a WebAuthn “Get” call, passing in the credentialId that we got when creating the credential. The result is a valid FIDO2 signature.


High-level architecture of using fingerprint or screen lock on Android devices to verify a user’s identity without a password

Please follow the instructions below if you’d like to try it out.
Prerequisites
  • Phone is running Android 7.0 (Nougat) or later
  • Your personal Google Account is added to your Android device
  • Valid screen lock is set up on your Android device
To try it
  • Open the Chrome app on your Android device
  • Navigate to https://passwords.google.com
  • Choose a site to view or manage a saved password
  • Follow the instructions to confirm that it’s you trying signing in
You can find more detailed instructions here.

For additional security
Remember, Google's automated defenses securely block the overwhelming majority of sign-in attempts even if an attacker has your username or password. Further, you can protect your accounts with two-step verification (2SV), including Titan Security Keys and Android phone’s built-in security key.

Both security keys and local user verification based on biometrics use the FIDO2 standards. However, these two protections address different use cases. Security keys are used for bootstrapping a new device as a second factor as part of 2SV in order to make sure it’s the right owner of the account accessing it. Local user verification based on biometrics comes after bootstrapping a device and can be used for re-authentication during step-up flows to verify the identity of the already signed-in user.

What’s next
This new capability marks another step on our journey to making authentication safer and easier for everyone to use. As we continue to embrace the FIDO2 standard, you will start seeing more places where local alternatives to passwords are accepted as an authentication mechanism for Google and Google Cloud services. Check out this presentation to get an early glimpse of the use cases that we are working to enable next.

Making authentication even easier with FIDO2-based local user verification for Google Accounts

Posted by Dongjing He, Software Engineer and Christiaan Brand, Product Manager 

Passwords, combined with Google's automated protections, help secure billions of users around the world. But, new security technologies are surpassing passwords in terms of both strength and convenience. With this in mind, we are happy to announce that you can verify your identity by using your fingerprint or screen lock instead of a password when visiting certain Google services. The feature is available today on Pixel devices and coming to all Android 7+ devices over the next few days.



Simpler authentication experience when viewing your saved password for a website on passwords.google.com


These enhancements are built using the FIDO2 standards, W3C WebAuthn and FIDO CTAP, and are designed to provide simpler and more secure authentication experiences. They are a result of years of collaboration between Google and many other organizations in the FIDO Alliance and the W3C.

An important benefit of using FIDO2 versus interacting with the native fingerprint APIs on Android is that these biometric capabilities are now, for the first time, available on the web, allowing the same credentials be used by both native apps and web services. This means that a user only has to register their fingerprint with a service once and then the fingerprint will work for both the native application and the web service.

Note that your fingerprint is never sent to Google’s servers - it is securely stored on your device, and only a cryptographic proof that you’ve correctly scanned it is sent to Google’s servers. This is a fundamental part of the FIDO2 design.

Here is how it works

Google is using the FIDO2 capability on Android to register a platform-bound FIDO credential. We remember the credential for that specific Android device. Now, when the user visits a compatible service, such as passwords.google.com, we issue a WebAuthn “Get” call, passing in the credentialId that we got when creating the credential. The result is a valid FIDO2 signature.


High-level architecture of using fingerprint or screen lock on Android devices to verify a user’s identity without a password

Please follow the instructions below if you’d like to try it out.
Prerequisites
  • Phone is running Android 7.0 (Nougat) or later
  • Your personal Google Account is added to your Android device
  • Valid screen lock is set up on your Android device
To try it
  • Open the Chrome app on your Android device
  • Navigate to https://passwords.google.com
  • Choose a site to view or manage a saved password
  • Follow the instructions to confirm that it’s you trying signing in
You can find more detailed instructions here.

For additional security
Remember, Google's automated defenses securely block the overwhelming majority of sign-in attempts even if an attacker has your username or password. Further, you can protect your accounts with two-step verification (2SV), including Titan Security Keys and Android phone’s built-in security key.

Both security keys and local user verification based on biometrics use the FIDO2 standards. However, these two protections address different use cases. Security keys are used for bootstrapping a new device as a second factor as part of 2SV in order to make sure it’s the right owner of the account accessing it. Local user verification based on biometrics comes after bootstrapping a device and can be used for re-authentication during step-up flows to verify the identity of the already signed-in user.

What’s next
This new capability marks another step on our journey to making authentication safer and easier for everyone to use. As we continue to embrace the FIDO2 standard, you will start seeing more places where local alternatives to passwords are accepted as an authentication mechanism for Google and Google Cloud services. Check out this presentation to get an early glimpse of the use cases that we are working to enable next.