Beyond Passwords: 2FA, U2F and Google Advanced Protection

[nir]

Last week I wrote a couple of different pieces on passwords, firstly about why we're going to be stuck with them for a long time yet and then secondly, about how we all bear some responsibility for making good password choices. A few people took some of the points I made in those posts as being contentious, although on reflection I suspect it was more a case of lamenting that we shouldn't be in a position where we're still dependent on passwords and people needing to understand good password management practices in order for them to work properly.

 

This week, I wanted to focus on going beyond passwords and talk about 2FA. Per the title, not just any old 2FA but U2F and in particular, Google's Advanced Protection Program. This post will be partly about 2FA in general, but also specifically about Google's program because of the masses of people dependent on them for Gmail. Your email address is the skeleton key to your life (not just "online" life) so protecting that is absolutely paramount.

 

Let's start with defining some terms because they tend to be used a little interchangeably. Before I do that, a caveat: every single time I see discussion on what these terms mean, it descends into arguments about the true meaning and mechanics of each. Let's not get bogged down in that and instead focus on the practical implications of each.

2FA, MFA, 2-Step

They may all be familiar, but there are important differences that warrant explanation and we'll start with the acronym we most commonly see:

 

2FA is two-factor authentication. For some quick perspective, a password alone is 1FA in that when you authenticate merely by entering a secret, all you require is one factor - "something that you know". If someone obtains the thing that you know then it's (probably) game over and they have access to your account. Adding a second factor typically means either requiring "something that you have" or "something that you are". The former is a physical device, for example I had one of these old RSA tokens more than a decade ago back in corporate land:

When I logged onto the work VPN, I needed to enter not just my Active Directory credentials but also the 6-digit number shown in the token above known as a time-based one-time password (TOTP). The bars on the left of the LCD screen would count down after which the digits would be rotated and I'd need to enter a different TOTP when authenticating. This was a pretty solid way of doing auth, albeit a bit clunky and still not foolproof. For every good security solution, someone will always find a way of screwing it up:

When it comes to "something you are", we're talking biometrics so think fingerprints, face, etc. Requiring, for example, both a password and a fingerprint would be a 2FA implementation.

 

Here's a very consumer-friendly way of describing 2FA: withdrawing money from an ATM requires two factors being your bank card (something you have) and your PIN (something you know). The bank card alone is useless as is the PIN; it's only a combination of the 2 that is usable.

 

MFA is multi-factor authentication. Strictly speaking, 2FA is MFA in that obviously, it's more than one factor. It's a subset of MFA. In consumer-facing implementations, most MFA is 2FA such as the RSA token example above. Same again with verification via SMS (don't lose your minds just yet, I'll come back to this). But, of course, MFA could also be 3FA and combine all the above factors, or even 4FA using an additional factor such as physical location.

 

2-Step authentication does not necessarily require 2 discrete factors. Entering 2 different passwords, for example, might be 2-step but is entirely predicated on "something you know". Let me draw from an excellent Security Stack Exchange explanation of this:

A good example of this is the two-step authentication required by Gmail. After providing the password you've memorized, you're required to also provide the one-time password displayed on your phone. While the phone may appear to be "something you have", from a security perspective it's still "something you know". This is because the key to the authentication isn't the device itself, but rather information stored on the device which could in theory be copied by an attacker. So, by copying both your memorized password and the OTP configuration, an attacker could successfully impersonate you without actually stealing anything physical.

You'll also regularly see arguments stating that what many consider to be 2FA is really just 2-step. For example, if you physically have someone's mobile phone in your hand and it's unlocked, you could login to an account by initiating a password reset, receiving the email in their email client then entering the "2nd factor" token sent via SMS or generated by a soft token app on the device. Using a soft token generated on your phone per the Stack Exchange explanation is, strictly speaking, not 2FA. 1Password has a great explanation of this (it's worth reading the entire "Second factor? No" section of that page):

We need to make the distinction between one time passwords and second factor security. One time passwords are often part of second factor security systems, but using one time passwords doesn’t automatically give you second factor security. Indeed, when you store your TOTP secret in the same place that you keep your password for a site, you do not have second factor security.

That's not to say that this model is "bad" and by any reasonable definition, it's a massive improvement over 1FA that would prevent the vast majority of account takeover attacks I see today. But many arguments have already been had about these definitions and as I said earlier, I don't want to get bogged down in that, let's talk specifics instead. Let's talk about what makes for good authentication practices.

The Hierarchy of Auth

I want to go through 5 separate levels of auth using common approaches, explain briefly how they work and then some common threats they're at risk of. Let's start somewhere familiar:

 

Password alone: This constitutes a single factor of auth and if someone else gets hold of it then there's a very good chance you're going to have a bad day. Passwords suffer from all the problems you're probably already aware of: they're often weak, they're regularly reused and they're also readily obtainable through attacks such as social engineering (phishing, smishing, vishing, etc.)

 

Password and SMS: I see a lot of derogatory comments about this pattern but let's be clear about one thing: a password and an SMS is always going to be better than a password alone. Those derogatory comments often relate to the prevalence of SIM porting where the attacker manages to port the victim's number to their own device and are subsequently able to receive SMSs destined for the victim. It's most damaging when account recovery can be facilitated via SMS alone (i.e. forgot password so recovery instructions can be sent via email or SMS).

 

Password and soft token: A very popular approach these days and it leverages an app such as Google Authenticator or Authy to generate the TOTP. The SIM porting risk is avoided (if you configure it properly), plus there's not the dedicated hardware dependency of the likes of an RSA token and consequently not the financial burden of acquiring hardware devices. This is probably the best balance of security, usability and cost we have going for us today.

 

Password and hard token: A similar situation to soft tokens but it requires a physical device which meets even a strict definition of 2FA. It addresses weaknesses with how many people configure soft tokens but it also introduces a cost barrier and requires you to have it physically present. It's also not immune to phishing: if a victim enters their first factor (password) into a malicious page and the attacker then requests the TOTP and (quickly) uses those on the target site, you've got a problem. Oh - you're still laughing about the webcam pointed at the tokens from earlier, so here's another one complete with instructions on how to set it up and even OCR the digits on the token:

Password and U2F: This is where I want to focus on the remainder of this blog because it solves all the problems raised above with the other approaches. Let's drop straight into understanding what U2F does and why you want it.

Understanding U2F

U2F is Universal 2nd Factor and according to Wikipedia:

is an open authentication standard that strengthens and simplifies two-factor authentication (2FA) using specialized Universal Serial Bus (USB) or near-field communication (NFC) devices based on similar security technology found in smart cards.

I suspect a word that's more familiar to most people is YubiKey:

YubiKey is a popular implementation of U2F and per the Wikipedia piece above, both Yubico and Google were responsible for the original development of it. The standard is now managed by the FIDO Alliance (Fast IDentity Online) and you'll see that name appear again as we progress. FIDO has released protocols that not only allow U2F devices like the one above to communicate over USB, but also over Bluetooth and NFC.

 

The value proposition of a U2F device like the YubiKey is that not only must you have it present ("something that you have"), it's not subject to the TOTP being disclosed like with tokens that require the user to enter a password into a third-party service which could still be a phishing page. (You also don't get very far by pointing a webcam at it!) There's a lot more to them than that, but for the purposes of this post it solves the phishing problem.

 

All of this so far has just been to establish the problem with various means of authentication and to talk about the solution that is U2F. Let's move onto Google's use of it.

Google Advanced Protection Program

There was actually an incident that led to this journey down the U2F path and it relates to this:

 

Troy Hunt

✔ @troyhunt

Can any friends at Google assist with an account recovery? A relative has lost access to their Gmail and recovery account and has run into a bit of a dead end options wise.

7:55 PM - Oct 28, 2018

 

This genuinely was a relative (no, not "a friend"!) and they'd been locked out of their account and no longer had access to the old email address that was used for recovery. At about that time, they received a notification saying that their Google password had been changed and they subsequently lost access to their Gmail. On the face of it, things looked bad and whilst I'd be inclined to reach the same conclusion that you probably already have in reading this, they also had SMS-based 2FA turned on and still had access to their mobile account. I assumed it was then either a case of someone phishing the TOTP sent via SMS or.... they'd inadvertently changed the password and locked themselves out. It turned out to be the latter, but it really got me thinking more about Google account security.

 

During the process of recovering their account, I spent a bit of time reading about Google's Advanced Protection Program which goes beyond SMS-based 2FA (or 2-step or whichever term you wish to use) all the way to U2F. The 2-minute video below is a pretty good summary of what it's about:

 

 

I decided to go through the process myself, putting myself in the shoes of the normal everyday consumer who'd be interested in turning on a feature like this so in other words, simply following their instructions (more on alternatives later on). Also, just to be clear, Google's Advanced Protection goes beyond just 2FA via U2F; there are also controls it turns on around the types of apps that can interact with your account and changes to the way account recovery works should you ever need to go down that path.

 

First up, you'll need 2 U2F keys where one will act as a primary and the other a backup. Plus, one will slot into a USB socket whilst the other will connect to a mobile device. Google linked me straight through to a 2-in-1 bundled offering on Amazon by Feitian for $40:

Feitian is a Chinese company that builds a bunch of different hardware security products. The white key above is their MultiPass FIDO unit in that it works across multiple communication protocols: USB, NFC and Bluetooth. The black key is their ePass FIDO and whilst compact, only supports USB so you're never going to be using this on, say, an iPhone (at least not without an additional dongle). You can use other keys but again, I wanted to go down the "follow the instructions" consumer route and experience the process as a normal everyday non-techie would. I'll ultimately be using these on both PCs and iOS devices so the Feitian route also aligns with Google's FAQ on keys:

I ended up needing to order them via eBay instead of Google's recommended Amazon item (thanks screwy Aussie GST laws), but it's the same product and a week later, it was on my doorstep:

So let's get into it! Kicking off on the enrolment page, first, you have to (re)auth to Google:

And just as a reminder, you need the keys:

Clicking the "enrol" button, it's now on (and I also get an email confirming this), but the keys themselves have yet to be enrolled:

I already have the keys so let's register them:

For the first key:

Key goes in and I tap:

Chrome then pops up and asks for access to the key:

The key is registered so now give it a name:

Job done! I add the second key in the same fashion, albeit at the end of the provided micro USB cable:

I name that one appropriately:

Both keys are now successfully registered:

Now we turn it on:

And just in case you got all this was by accident, are you really really sure?

And we're done!

In case anyone wants to read through that how to sign in with a security key link, I've linked to it so you can read it in your own time.

I'm well and truly signed out, both on google.com and in Chrome which now shows a status of "Paused":

I click the sign in link and fill the password from 1Password after which I'm faced with the second factor challenge:

I insert the ePass key, tap the button and wait:

And I'm back in!

I repeat the process for my two laptops, no dramas. This is actually much easier than either SMS or TOTP solutions which require you to re-enter a number into the page whilst the clock is counting down. One of those rare moments where more security also means more usability! Seriously, signing in once this is setup is dead simple, but that's just the PCs so far, let's do the mobile things.

Over on the iPhone, I've been signed out of the YouTube app so let's use that as a starting point:

Once I attempt to sign in, the Google Smart Lock app makes an appearance:

At least on iOS, auth'ing back into your Google account requires the Google app. No biggy, grab the app and begin the pairing:

Now because this is an iPhone without a USB socket, I'll be using the MultiPass unit with Bluetooth to auth the phone so I grab that and follow the instructions:

Once the key is in pairing mode, it shows up in the Google app with its 6-character identifier:

This same identifier is on the back of the key. Speaking of which:

And then finally, Apple pops up a native challenge that identifies the key via the same 6-letter name as before and asks for the PIN:

And we're done!

The sign-in over in the YouTube app can now use Google Smart Lock and I'm back into the account. Repeat the same thing on the iPad and all the mobile devices are now successfully auth'd.

 

Google's implementation is just lovely. It's fast, easy and for most people, something they're going to do very infrequently anyway. Gmail users are the big winners out of all this: as I said earlier, email is the skeleton key to your life and at least for tech folks who understand the importance of protecting accounts, this seems like a no-brainer. I wouldn't want to have to go through account recovery because I get the distinct impression that it wouldn't be a fun experience, but that's also kinda the idea: gaining access to an account without sufficient identity proof should be hard! This is why the SMS porting thing is a real problem; the number alone should never be used for account recovery because being in control of just a phone number simply isn't enough to verify identity with any reasonable degree of confidence.

 

There's an increasing array of other services out there that enable 2FA using U2F too, including:

1. Dropbox
2. Twitter
3. Facebook
4. GitHub

As I mentioned earlier, this was really "the consumer" path to U2F on Google. There are other U2F keys out there and I mentioned YubiKey earlier on. They've just launched the 5 series which is a pretty slick implementation that includes iPhone / iPad compatible NFC and supports FIDO2. But it's also $45 for one key and you're still going to need another one to enrol in Google's U2F program.

 

Lastly, let me leave you with anecdote related to going beyond 1FA: I recently had someone contact me and complain that GitHub was warning them about their choice of passwords following their integration with my Pwned Passwords service. "I should be able to use any password I want", he lamented. "I've got 2FA turned on so what does it matter?!" Now, hopefully the problem here is already self-evident but let's just be crystal clear anyway: adding a second step to authentication should not be seen as an excuse to weaken the first step. I'm hesitant to call this guy's approach 2FA (if it's true MFA at all), it's more like 1.5FA or something thereabouts. The point is, use the approaches above as additional security controls, not as an excuse to weaken existing ones!

 

Source