Best practices for a more secure login in Google Cloud
Product Manager, Security & Identity
Whether you’re an IT executive or an administrator in charge of operations, understanding Google’s security tools—and built-in protections we already provide—can go a long way in helping ensure your cloud journey is secure and effective.
To successfully protect your organization’s data in the cloud, it’s important to first secure users’ identities. In this post, we look at two important account security features that can help you protect user accounts from bad actors:
Google’s automatic protections that work during login.
Two-step verification (2SV), also known as two-factor authentication (2FA) or multi-factor authentication (MFA).
But first, let’s talk about why we need these protections in the first place.
A password alone won’t do
Passwords are often the first and last defense for users, but they aren’t foolproof for a few reasons:
People use common words that can be easily guessed. Twenty-four percent of Americans have used the following common passwords: abc123, Password, 123456, Iloveyou and more.
People reuse passwords across services or devices, which opens up disproportionate trouble if just one is compromised. According to the same research, sixty-six percent of Americans admit to using the same weak password across multiple sites.
People can be easily tricked into sharing passwords with fraudulent sites. Four out of 10 Americans say their personal information has been compromised online.
In short, passwords have pitfalls. So IT leaders should make sure to educate users, and use the right tools to mitigate issues if they happen.
Google’s automatic protections work at login
Apart from basic defenses, like blocking brute force attacks, Google also employs sophisticated risk models built-in in our products to assess if a login event is legitimate or not. If our risk engine determines that an attempt is suspicious (for example, the login happens from a new location or device), we’ll ask for additional proof to ensure the right user is logging in. We do this by offering login challenges, which means we might ask the user to confirm their identity from a trusted phone or to answer a question. We support a variety of login challenges, including device challenges, email challenges, and employee ID challenges as shown here:
Recently, our research teams partnered with New York University and the University of California, San Diego to conduct a year-long study on account hygiene. In this research, we established that our automatic risk-based challenges are effective at thwarting malicious account access if a user is signed in on a different, trusted device or if a recovery email address or phone number is attached to that account. In particular, these protections are extremely effective against automated bots and many types of phishing attacks.
The best part of this approach is that Google only presents a login challenge to users if the login attempt is deemed risky. Google’s security tools are smart enough to know when to verify identity, like if you’re logging in to a new device or from a new location. This feature is often referred to as “adaptive MFA” in the industry, and it can help increase security without unnecessarily burdening users. At Google, we consider this feature core to securing online identities, and it’s available to all G Suite and GCP users at no extra cost.
For extra assurance, use two-factor authentication (or 2FA/2SV)
While risk-based challenges are effective against many kinds of attacks, Google recommends use of 2SV for greater assurance and protection against more sophisticated attacks. When 2SV is used, a user is required to authenticate in two steps: 1. Using something they know, like a password, and 2. Using something they have, such as a code or a hardware device.
Google supports a number of convenient 2SV methods. We can loosely bucket them into three categories based on their security characteristics. Bear in mind that using any of these methods can increase the security of user accounts; however, they each have different security properties, so it’s important to understand the tradeoffs. Let’s go over each one.
Phishing-resistant security keys: Security keys, like Google’s Titan Security Keys or your Android phone, are a form of 2SV that is designed to be resistant to phishing. They are built to the industry standard FIDO protocols. They work with the browser and use cryptographic assertions to ensure that users are authenticating only on legitimate sites. Google recommends use of security keys for all users if feasible, and at a minimum for your highest-risk users, like super admins, executives, and employees working with sensitive information. In the same study highlighted above, we found zero users that exclusively use security keys fell victim to targeted phishing during our investigation. And recent features, like security codes, have made security keys easier to deploy in the enterprise than ever before.
Other 2SV methods: Backup codes, TOTP compliant apps (e.g. Google Authenticator), and mobile push (e.g. Google Prompt), are options within this next security level. These methods provide good protection for most users, but they are not as effective as security keys, because they can be vulnerable to some sophisticated phishing attempts. For your users at the highest-risk or most privileged users, we highly recommend to use security keys and, ideally, enroll in the Advanced Protection Program for the enterprise.
SMS or voice codes: While SMS and voice codes have an advantage because most users are already familiar with how they work, these codes are the least secure of the available 2SV methods. We recommend avoiding SMS or voice codes if any of the other 2SV methods are feasible. The Admin console has policies that allow you to block your users from using them for sign in.
In general, we highly recommend all users to have some form of 2SV. Even SMS or voice codes are better than no 2SV at all.
Use the best of Google’s security defenses with your identity provider (IdP)
Many organizations use third-party cloud-based or legacy on-prem SAML-based identity providers for primary user authentication. Now, it’s possible to use Google’s risk-based login challenges and the 2SV stack with your own IdP. Read more about how to protect your users by combining your IdP with Google’s security protections, which is helpful in the following scenarios:
Your current IdP or MFA provider does not support modern phishing-resistant security keys.
You are using a third-party MFA service while some or all of your users exclusively use Google Cloud services for their work.
You want to use Google’s risk-based login challenges infrastructure for an added level of security protection against malicious access.
If your organization uses a third-party IdP, we recommend you enable this new feature so you can benefit from Google’s strong risk-based assessments and also help reduce operational costs. Risk-based login challenges as well as 2SV are available to all customers of G Suite, GCP, and Cloud Identity at no additional cost.
Key takeaways for Google Cloud account security
Keep these tips in mind as you’re setting up secure infrastructure for your users:
Passwords can be problematic; lean on Google tools to help enforce password hygiene. Also, consider recommending these five simple steps to your users to increase security.
Ensure there’s metadata logged on your users’ accounts—such as a recovery phone or employee ID—so that they can be used if risky logins are detected.
For greater assurance, require 2SV usage for all users.
Any 2SV is better than no 2SV. However, remember that not all 2SV methods are the same.
We recommend the use of security keys for everyone, especially your highest-risk users, such as administrators, privileged GCP users, and executives.
Even if you use your own SAML IdP, you can now benefit from Google’s risk-based login challenges and modern 2SV stack.
Lastly, if you’d like to learn more specific strategies on how to thwart hackers and protect your data in G Suite, register to attend our free Global Digital Conference on December 10, 2019 from 9am - 2pm PT / noon - 5 pm ET.