Google Online Security Blog

Enhanced Safe Browsing Protection now available in Chrome

May 19, 2020

Posted by Nathan Parker, Varun Khaneja, Eric Mill and Kiran C Nair - Chrome Safe Browsing team Over the past few years we’ve seen threats on the web becoming increasingly sophisticated. Phishing sites rotate domains very quickly to avoid being blocked, and malware campaigns are directly targeting at-risk users. We’ve realized that to combat these most effectively, security cannot be one-size-fits-all anymore: That’s why today we are announcing Enhanced Safe Browsing protection in Chrome, a new option for users who require or want a more advanced level of security while browsing the web. Turning on Enhanced Safe Browsing will substantially increase protection from dangerous websites and downloads. By sharing real-time data with Google Safe Browsing, Chrome can proactively protect you against dangerous sites. If you’re signed in, Chrome and other Google apps you use (Gmail, Drive, etc) will be able to provide improved protection based on a holistic view of threats you encounter on the web and attacks against your Google Account. In other words, we’re bringing the intelligence of Google’s cutting-edge security tools directly into your browser. Over the next year, we’ll be adding even more protections to this mode, including tailored warnings for phishing sites and file downloads and cross-product alerts. Building upon Safe Browsing Safe Browsing’s blocklist API is an existing security protocol that protects billions of devices worldwide. Every day, Safe Browsing discovers thousands of new unsafe sites and adds them to the blocklist API that is shared with the web industry. Chrome checks the URL of each site you visit or file you download against a local list, which is updated approximately every 30 minutes. Increasingly, some sophisticated phishing sites slip through that 30-minute refresh window by switching domains very quickly. This protocol is designed so that Google cannot determine the actual URL Chrome visited from this information, and thus by necessity the same verdict is returned regardless of the user’s situation. This means Chrome can’t adjust protection based on what kinds of threats a particular user is seeing or the type of sites they normally visit. So while the Safe Browsing blocklist API remains very powerful and will continue to protect users, we’ve been looking for ways to provide more proactive and tailored protections. How Enhanced Safe Browsing works When you switch to Enhanced Safe Browsing, Chrome will share additional security data directly with Google Safe Browsing to enable more accurate threat assessments. For example, Chrome will check uncommon URLs in real time to detect whether the site you are about to visit may be a phishing site. Chrome will also send a small sample of pages and suspicious downloads to help discover new threats against you and other Chrome users. If you are signed in to Chrome, this data is temporarily linked to your Google Account. We do this so that when an attack is detected against your browser or account, Safe Browsing can tailor its protections to your situation. In this way, we can provide the most precise protection without unnecessary warnings. After a short period, Safe Browsing anonymizes this data so it is no longer connected to your account. You can opt in to this mode by visiting Privacy and Security settings > Security > and selecting the “Enhanced protection” mode under Safe Browsing. It will be rolled out gradually in M83 on desktop platforms, with Android support coming in a future release. Enterprise administrators can control this setting via the SafeBrowsingProtectionLevel policy. Tailored protections Chrome’s billions of users are incredibly diverse, with a full spectrum of needs and perspectives in security and privacy. We will continue to invest in both Standard and Enhanced Safe Browsing with the goal to expand Chrome’s security offerings to cover all users.

Introducing portability of Google Authenticator 2SV codes across Android devices

May 7, 2020

Posted by Dongjing He, Software Engineer; Teddy Katz, Software Engineer; Christiaan Brand, Product Manager
2-Step Verification

Transferring accounts from one device to another with Google Authenticator

Using 2SV, 2-Factor Authentication (2FA) or Multi-Factor Authentication (MFA) is critical to protecting your accounts from unauthorized access. With these mechanisms, users verify their identity through their password and an additional proof of identity, such as a security key or a passcode.

Google Authenticator makes it easy to use 2SV on accounts. In addition to supplying only a password when logging in, a user also enters a code generated by the Google Authenticator app on their phone. This is a safer alternative, used by millions of users, compared to passcodes via text message.

Users place their trust in Google Authenticator to keep their accounts safe. As a result, security is always a high priority. We made several explicit design decisions to minimize the attack surface while increasing the overall usability of the app.

We ensured that no data is sent to Google’s servers during the transfer -- communication is directly between your two devices. Your 2SV secrets can’t be accessed without having physical access to your phone and the ability to unlock it.
We implemented a variety of alerting mechanisms and in-app logs to make sure users are aware when the transfer function has been used.

You can find more information about the Google Authenticator and its usage guide here.

Research Grants to support Google VRP Bug Hunters during COVID-19

April 20, 2020

Posted by Anna Hupa, Senior Strategist, Trust & Safety at GoogleVulnerability Research GrantVulnerability Research GrantVulnerability Reward Program (VRP) rulesVulnerability Research Grant@GoogleVRP

Introducing our new book “Building Secure and Reliable Systems”

April 8, 2020

Posted by Royal Hansen, VP of Security Engineering, Google

Site Reliability Engineers (SREs) and security engineers tend to break and fix, as well as build.

Their work encompasses operations, in addition to development.

SREs and security engineers are specialists, rather than classic software engineers.

They are often viewed as roadblocks, rather than enablers.

They are frequently siloed, rather than integrated in product teams.

The new book can be downloaded for free from the Google SRE website, or purchased as a physical copy from your preferred retailer.

Announcing our first GCP VRP Prize winner and updates to 2020 program

March 11, 2020

Posted by Harshvardan Sharma, Information Security Engineer, Googleannouncedherevideo

1st prize: $133,337

2nd prize: $73,331

3rd prize: $73,331

4th prize: $31,337

5th prize: $1,001

6th prize: $1,000

Like last year, submissions should have public write-ups in order to be eligible for the prize. The number of vulnerability reports in a single write-up is not a factor. You can even make multiple submissions, one for each write-up. These prizes are only for vulnerabilities found in GCP products. If you have budget constraints regarding access to testing environments, you can use the free tier of GCP. Note that this prize is not a replacement of our Vulnerability Reward Program (VRP), and that we will continue to pay security researchers under the VRP for disclosing security issues that affect Google services, including GCP. Complete details, terms and conditions about the prize can be found here.

Thank you to everyone who submitted entries in 2019! Make sure to nominate your VRP reports and write-ups for the 2020 GCP VRP prize here before December 31, 2020 at 11:59 GMT.

How Google Play Protect kept users safe in 2019

March 10, 2020

Posted by Rahul Mishra, Program Manager, Android Security and Privacy Team

malware and other harmful appsAdvanced similarity detectionon the deviceWarnings for apps targeting lower Android versionsAndroid OS

Uploading rare apps for scanning

Integration with Google’s Files appGoogle’s Files app

Play Protect visual updates visual redesign

developers.google.com/android/play-protectAaron Josephs, Ben Gruver, James Kelly, Rodrigo Farell, Wei Jin and William Luh

How Google does certificate lifecycle management

March 10, 2020

Posted by Siddharth Bhai and Ryan Hurst, Product Managers, Google Cloud
Google Transparency Report

Percentage of pages loaded over HTTPS in Chrome by platform (Google Transparency Report)CA/Browser ForumACME
As we round off this exciting tour of recent TLS history, we’d be remiss if we didn’t mention Let’s Encrypt - the first publicly trusted non-profit CA. Their focus on automation and TLS by default has been foundational to this massive increase in TLS usage. In fact, Let’s Encrypt just issued their billionth (!) certificate. Google has been an active supporter of Let’s Encrypt because we believe the work they do to make TLS accessible is important for the security and resilience of the Internet's infrastructure. Keep rocking, Let’s Encrypt!
Simplifying certificate lifecycle management for Google’s users

With the adoption numbers cited above, it’s clear that TLS, Web PKI, and certificate lifecycle management are foundational to every product we and our customers build and deploy. This is why we have been expanding significant effort to enable TLS by default for our products and services, while also automating certificate renewals to make certificate lifecycle management more reliable, globally scalable, and trustworthy for our customers. Our goal is simple: We want to ensure TLS just works out of the box regardless of which Google service you use.
In support of that goal, we have enabled automatic management of TLS certificates for Google services using an internal-only ACME service, Google Trust Services. This applies to our own products and services, as well as for our customers across Alphabet and Google Cloud. As a result, our users no longer need to worry about things like certificate expiration, because we automatically refresh the certificates for our customers. Some implementation highlights include:

All Blogger blogs, Google Sites, and Google My Business sites now get HTTPS by default for their custom domains.

Google Cloud customers get the benefits of Managed TLS on their domains. So:

Developers building with Firebase, Cloud Run, and AppEngine automatically get HTTPS for their applications.
When deploying applications with Google Kubernetes Engine or behind Google Cloud Load Balancing (GCLB), certificate management is taken care of if customers choose to use Google-managed certificates. This also makes TLS use with these products easy and reliable.

creation of a CAA record
While everyone appreciates TLS working out of the box, we also know power users have specialized needs. This is why we have provided rich capabilities in Google Cloud Load Balancing to let customers control policies around TLS termination.

In addition, through our work on Certificate Transparency in collaboration with other organizations, we have made it easier for our customers to protect their and their customers’ brands by monitoring the WebPKI ecosystem for certificates issued for their domains or those that look similar to their domains, so they can take proactive measures to stop any abuse before it becomes an issue. For example, Facebook used Certificate Transparency Logs to catch a number of phishing websites that tried to impersonate their services.

We recognize how important security, privacy, and reliability are to you and have been investing across our product portfolio to ensure that when it comes to TLS, you have the tools you need to deploy with confidence. Going forward, we look forward to a continued partnership to make the Internet a safer place together.

FuzzBench: Fuzzer Benchmarking as a Service

March 2, 2020

Posted by Jonathan Metzman, Abhishek Arya, Google OSS-Fuzz Team and László Szekeres‎, Google Software Analysis TeamFuzzBenchFuzzing12often have shortcomingsexampleOSS-Fuzz projectsten fuzzershereHow to ParticipateFuzzBench repo

Helping Developers with Permission Requests

February 27, 2020

Posted by Sai Teja Peddinti, Nina Taft and Igor Bilogrevic from PDPO Applied Privacy Research, and Pauline Anthonysamy from Android Security and Privacy.12Reducing Permissions Requests in Mobile Apps3

3Project Strobeour guidelines on permissions best practicesour requirements around safe traffic handlingAcknowledgementsGiles Hogben, Android Play Dashboard and Pre-Launch Report teams References[1] Modeling Users’ Mobile App Privacy Preferences: Restoring Usability in a Sea of Permission Settings, by J. Lin B. Liu, N. Sadeh and J. Hong. In Proceedings of Usenix Symposium on Privacy & Security (SOUPS) 2014.[2] Using Personal Examples to Improve Risk Communication for Security & Privacy Decisions, by M. Harbach, M. Hettig, S. Weber, and M. Smith. In Proceedings of the SIGCHI Conference on Human Computing Factors in Computing Systems, 2014.[3] Reducing Permission Requests in Mobile Apps, by S. T. Peddinti, I. Bilogrevic, N. Taft, M Pelikan, U. Erlingsson, P. Anthonysamy and G. Hogben. In Proceedings of ACM Internet Measurement Conference (IMC) 2019.

Data Encryption on Android with Jetpack Security

February 25, 2020

Posted by Jon Markoff, Staff Developer Advocate, Android Security

Have you ever tried to encrypt data in your app? As a developer, you want to keep data safe, and in the hands of the party intended to use. But if you’re like most Android developers, you don’t have a dedicated security team to help encrypt your app’s data properly. By searching the web to learn how to encrypt data, you might get answers that are several years out of date and provide incorrect examples. The Jetpack Security (JetSec) crypto library provides abstractions for encrypting Files and SharedPreferences objects. The library promotes the use of the AndroidKeyStore while using safe and well-known cryptographic primitives. Using EncryptedFile and EncryptedSharedPreferences allows you to locally protect files that may contain sensitive data, API keys, OAuth tokens, and other types of secrets. Why would you want to encrypt data in your app? Doesn’t Android, since 5.0, encrypt the contents of the user's data partition by default? It certainly does, but there are some use cases where you may want an extra level of protection. If your app uses shared storage, you should encrypt the data. In the app home directory, your app should encrypt data if your app handles sensitive information including but not limited to personally identifiable information (PII), health records, financial details, or enterprise data. When possible, we recommend that you tie this information to biometrics for an extra level of protection. Jetpack Security is based on Tink, an open-source, cross-platform security project from Google. Tink might be appropriate if you need general encryption, hybrid encryption, or something similar. Jetpack Security data structures are fully compatible with Tink. Key Generation Before we jump into encrypting your data, it’s important to understand how your encryption keys will be kept safe. Jetpack Security uses a master key, which encrypts all subkeys that are used for each cryptographic operation. JetSec provides a recommended default master key in the MasterKeys class. This class uses a basic AES256-GCM key which is generated and stored in the AndroidKeyStore. The AndroidKeyStore is a container which stores cryptographic keys in the TEE or StrongBox, making them hard to extract. Subkeys are stored in a configurable SharedPreferences object. Primarily, we use the AES256_GCM_SPEC specification in Jetpack Security, which is recommended for general use cases. AES256-GCM is symmetric and generally fast on modern devices. val keyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC) For apps that require more configuration, or handle very sensitive data, it’s recommended to build your KeyGenParameterSpec, choosing options that make sense for your use. Time-bound keys with BiometricPrompt can provide an extra level of protection against rooted or compromised devices. Important options:

userAuthenticationRequired() and userAuthenticationValiditySeconds() can be used to create a time-bound key. Time-bound keys require authorization using BiometricPrompt for both encryption and decryption of symmetric keys.

unlockedDeviceRequired() sets a flag that helps ensure key access cannot happen if the device is not unlocked. This flag is available on Android Pie and higher.

Use setIsStrongBoxBacked(), to run crypto operations on a stronger separate chip. This has a slight performance impact, but is more secure. It’s available on some devices that run Android Pie or higher.

Note: If your app needs to encrypt data in the background, you should not use time-bound keys or require that the device is unlocked, as you will not be able to accomplish this without a user present. // Custom Advanced Master Key val advancedSpec = KeyGenParameterSpec.Builder( "master_key", KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT ).apply { setBlockModes(KeyProperties.BLOCK_MODE_GCM) setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE) setKeySize(256) setUserAuthenticationRequired(true) setUserAuthenticationValidityDurationSeconds(15) // must be larger than 0 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) { setUnlockedDeviceRequired(true) setIsStrongBoxBacked(true) } }.build() val advancedKeyAlias = MasterKeys.getOrCreate(advancedSpec) Unlocking time-bound keys You must use BiometricPrompt to authorize the device if your key was created with the following options:

userAuthenticationRequired is true

userAuthenticationValiditySeconds > 0

After the user authenticates, the keys are unlocked for the amount of time set in the validity seconds field. The AndroidKeystore does not have an API to query key settings, so your app must keep track of these settings. You should build your BiometricPrompt instance in the onCreate() method of the activity where you present the dialog to the user. BiometricPrompt code to unlock time-bound keys // Activity.onCreate val promptInfo = PromptInfo.Builder() .setTitle("Unlock?") .setDescription("Would you like to unlock this key?") .setDeviceCredentialAllowed(true) .build() val biometricPrompt = BiometricPrompt( this, // Activity ContextCompat.getMainExecutor(this), authenticationCallback ) private val authenticationCallback = object : AuthenticationCallback() { override fun onAuthenticationSucceeded( result: AuthenticationResult ) { super.onAuthenticationSucceeded(result) // Unlocked -- do work here. } override fun onAuthenticationError( errorCode: Int, errString: CharSequence ) { super.onAuthenticationError(errorCode, errString) // Handle error. } } To use: biometricPrompt.authenticate(promptInfo) Encrypt Files Jetpack Security includes an EncryptedFile class, which removes the challenges of encrypting file data. Similar to File, EncryptedFile provides a FileInputStream object for reading and a FileOutputStream object for writing. Files are encrypted using Streaming AEAD, which follows the OAE2 definition. The data is divided into chunks and encrypted using AES256-GCM in such a way that it's not possible to reorder. val secretFile = File(filesDir, "super_secret") val encryptedFile = EncryptedFile.Builder( secretFile, applicationContext, advancedKeyAlias, FileEncryptionScheme.AES256_GCM_HKDF_4KB) .setKeysetAlias("file_key") // optional .setKeysetPrefName("secret_shared_prefs") // optional .build() encryptedFile.openFileOutput().use { outputStream -> // Write data to your encrypted file } encryptedFile.openFileInput().use { inputStream -> // Read data from your encrypted file } Encrypt SharedPreferences If your application needs to save Key-value pairs - such as API keys - JetSec provides the EncryptedSharedPreferences class, which uses the same SharedPreferences interface that you’re used to. Both keys and values are encrypted. Keys are encrypted using AES256-SIV-CMAC, which provides a deterministic cipher text; values are encrypted with AES256-GCM and are bound to the encrypted key. This scheme allows the key data to be encrypted safely, while still allowing lookups. EncryptedSharedPreferences.create( "my_secret_prefs", advancedKeyAlias, applicationContext, PrefKeyEncryptionScheme.AES256_SIV, PrefValueEncryptionScheme.AES256_GCM ).edit { // Update secret values } More Resources FileLocker is a sample app on the Android Security GitHub samples page. It’s a great example of how to use File encryption using Jetpack Security. Happy Encrypting!

Security Blog