What is 2 Step Authentication?
2 Step Authentication, or 2SA for short, is an authentication strategy which requires a user to enter a second code, following their password, in order to authenticate. Generally, these codes come in the form of a number which changes quickly, or may be sent via SMS to you. There are many forms of 2SA, but for the purposes of this post, we’ll be covering 2SA provided by Google in the G Suite platform.
Why should I care about 2SA?
Today, businesses small and large should be paying attention to 2SA. One of the most common online scams involves sending an email to users requesting their password. This could be cleverly disguised as a help desk email, a system password reset request, or something else. The point is, many of these emails are believable to the average end user. These attacks are called ‘Phishing’ attacks, and they are precisely what happened to John Podesta recently.
When a user has 2SA enabled, their account remains secure even if the password has been compromised, because any person trying to login is required to enter the security code to complete the authentication. This makes ‘Phishing’ attacks much harder (or impossible) for the attacker, and thereby protects your data.
What is Google 2SA and how can it help?
G Suite has a built in product called Google 2 Step Authentication. When enabled, users will be prompted for a security code when attempting to login. While Google 2FA doesn’t work with a third party single sign on (SSO) solution, if you are using Google to authenticate your users, Google 2SA is included with every version of G Suite.
Once enabled, users can choose a variety of ways to get these codes to log in. SMS texts can be sent to their registered phone whenever a login is attempted, or you can generate codes at any time using the Google Authenticator mobile app. In addition, you can take this one step further and set up a physical security key. We’ll cover more on these keys in the next section.
Google 2SA can be enabled at the OU level in the admin console under ‘Security>Basic Settings>Go to advanced settings to Enforce 2Step Verification.’ This means that you could selectively enable or enforce 2SA for groups of users who are high risk, such as finance.
A note on Security Keys and 2FA
While receiving a 2SA code via SMS or using the Authenticator App increases the security of your account dramatically, it is important to note one shortcoming of this approach. If a particular user’s computer was compromised, say infected with malware or some kind of keylogger, it is possible that a code could be captured, transmitted, and used before the 30 second window of expiration is completed. The difference between 2SA and 2FA is rooted in this problem. For 2SA, an attacker would only have to complete one type of compromise to impact the account, for instance retrieve two pieces of information you know (your password and your security code). However, with 2FA, the attacker has to compromise two distinctly separate types of data, something you know, and something you have (your security key). Security keys, such as the ones issued by Yubikey, provide a transport level hardware handshake that all but ensures that the device connecting is the device which is intended. A keylogger or malware would be hard pressed to emulate the hardware verifications happening, and the handshake removes the opportunity for a man-in-the-middle type attack. For your most sensitive users, keys are the way to go. They are cost effective, easy to use, and protect your data from exposure the best way possible, provided by Google. Finally, with the Google Enterprise SKU, you can enforce 2FA, or key usage, as a step above 2SA codes. This helps to continue to enable the organization to apply the correct level of protection to each group in the business.
A word about enabling 2SA or 2FA
While turning on 2SA or 2FA is technically fairly straightforward, there are a few points of caution to consider when enabling it for the business.
First, you shouldn’t enforce on day one. If you do, this will lock out any user who does not already have 2SA enabled. This can be a real mess. Instead use the ‘enforce by date’ option. This will activate some communications to your users which will prompt them repeatedly to set up 2SA for their account. If they don’t, then they will be locked out on the enforcement date, but at least you will have given them warning. This applies for 2FA Key enforcement as well with the G Suite Enterprise SKU. We always recommend supplemental communications around this effort, as it helps users understand why this is a necessary step in protecting the business.
Second, when onboarding users, you’ll want to modify your provisioning process to include a staging OU that does not have 2SA enforced. This is commonly overlooked, but is necessary to avoid lockouts. An example of how this would look is as follows: A new user is onboarded, and their account is created. If you’re using Active Directory sync, you’ll want to ensure the user is synced to the staging OU where 2SA is enabled but not enforced. If you are provisioning directly to Google, create the user directly in the OU. As part of the New Hire process, ensure the user received instructions for setting up 2SA. At the end of the first week, move the user to the intended steady state OU where 2SA is enforced. This puts them into compliance, but gives them a chance to set up before being locked out.
In closing, for any organization using Google as their authentication method, enabling 2SA through Google is an important part of a thoughtful and holistic security posture. You can further leverage this security by enabling other apps to take advantage of this authentication method through SAML (with Google as the IDP, covered in another post) and using security keys with 2FA. By leveraging these G Suite features, you can take advantage of an extremely sophisticated authentication system without breaking the bank. We encourage everyone to enable 2 Factor Authentication for their users.