Halfpoint - Fotolia
Google's Mark Risher discusses 2FA adoption strategies
Although some types of two-factor authentication have been found to be vulnerable, Google's Mark Risher says 2FA adoption should be the baseline of security for all enterprises.
The narrative around two-factor authentication has become more complicated recently as more stories have come out to expose vulnerabilities in SMS-based 2FA.
Malicious actors can use various techniques from SIM swapping to SS7 vulnerabilities in order to intercept SMS-based 2FA codes. As a result, experts have recommended that enterprises not use SMS in 2FA adoption strategies.
However, Mark Risher, head of account security at Google, is worried these stories may lead some to avoid 2FA adoption under wrong assumptions that all 2FA is insecure. Risher tackles phishing and malware abuse and misuse of Google platforms. He believes the conversation about two-factor authentication has lost necessary nuance and said enterprises and users alike need to better understand the practical tradeoffs with different types of 2FA.
Editor's note: This interview has been edited for length and clarity.
What should be the baseline for 2FA adoption in enterprises? What tools and technologies you think are the best way to move forward?
Mark Risher: For enterprises, two-factor really should be the starting point. That is the baseline, and any enterprise that is relying simply on passwords today really needs to get with the program. Now I recognize it's hard, I'm not unsympathetic. I know that there are expenses, there are legacy technology concerns to contend with, there are human factors and usability aspects that need to be looked at, but truly what recent news has shown is that all enterprises have something to lose. You don't have to be a defense contractor to worry about nation-state attacks, much less organized crime. And being that this is where the line has moved, you are really doing your employees a disservice if you're allowing them the flexibility to continue logging in with these unproven, rather unsecure methods, like password-only authentication or a firewall with private network-only authentication.
We eat our own dog food. Google has required two-factor authentication for all our employees for many, many years, and we've required security keys, which we believe are the strongest and the most secure and most phishing-resistant technology out there, for many years. The result of which has been we've had no cases of password phishing since we deployed them.
That said, I don't want to oversimplify. We are a wealthy, tech-forward company, so I know not every one of your readers can immediately adopt what we have, but we truly believe and practice what we preach. This is the direction that everyone needs to be moving into and needs to have a plan, and executives across these large companies should at least have a migration strategy if not plans that are already underway.
Is it a matter of cost why an enterprise might opt for 2FA adoption using SMS codes rather than physical security keys?
Risher: I think cost is the lowest priority, the least significant obstacle. I think the two bigger impediments are one: a lack of understanding, and two: technical legacy concerns that make integration difficult. If you have a back office payroll system that was last modified six years ago, it may just have limits to what you can do, and that's where things like a bolt-on VPN or a bolt-on SMS-based two-factor might be the easiest options to deploy. That's on us as technology providers to make that easier.
There's always a lot of talk about moving beyond passwords completely. What are your thoughts on that?
Risher: The passwords are terrible. We know that they are too hard for regular people to remember and use and too easy for attackers to remember and use, but the challenges of passwords are also great. They are backward-compatible on systems dating back 40 years, they are a modality that everyone understands, they work across all platforms to some degree, and they have some useful properties. So while there's great enthusiasm around eliminating passwords, the practical concern is always, to replace them with what?
The way we've been approaching this is through what we call federated identity -- that is, linking together different services -- and in the enterprise world this is frequently described alongside single sign-on or SSO, where the general principle is that users should go through one rigorous robust moment that they authenticate themselves to a new device. They take a device from nothing and they put a single account on there -- we'd love for it to be a Google account, but there's many other identity providers -- but then, linking to other services should not require a password because you're not really adding much in that moment. They should instead rely back on that initial authentication.
Consumers are probably familiar with this in some of the open standards that are implemented on consumer-facing sites -- things like Sign In with Google, or to some degree Facebook Connect. Some of these types of features really do evince that principle, but here again, not everyone understands that they're actually improving security. In fact, counter-intuitively, sometimes users think because that was simpler it must be less secure, and to memorize something with capital letters, symbols, numbers, you know, lower case and punctuation, that would be harder for me, therefore it must be harder for the attacker. That's a common fallacy: that what's hard for you is hard for attackers and vice versa, and awareness and understanding is the biggest thing holding us back.
What is your core advice for those looking at 2FA adoption?
Risher: If you're just using a password you should definitely have a second factor of authentication. At Google we do this automatically wherever possible, so people don't need to enroll; if we see you coming from a suspicious new device we generally will automatically challenge and require a second factor. That said, people may be afraid or hesitant to jump all the way to the Advanced Protection Program, and I want to reassure them.
I work here. Obviously, I understand how this works, but at the same time as a Google employee I am constantly testing new devices. I'm constantly moving to new firm factors and types of hardware as we're inventing and building new things at Google. It's not been an impediment. It's not this clunky system that people remember from when they were first issued their RSA token back in 1998. It is very elegant, it's very smooth, it works now with mobile devices, it works over Bluetooth, NFC and USB, and USB-C, and this is not a big hardship. I don't want to scare people away and make them feel that they need to do the equivalent of driving around in an armored car just to get some peace of mind.
Having a second factor is definitely better than not [having one], so if you're just relying on passwords and you simply add the weakest, which is this code sent to your cellphone, you're still way better off than just relying on the password. If your second factor is not a code but is instead a security key, you've now moved way further to a place where really, it becomes a local attack, and the number of people that have access to my keychain right now while I'm talking to you is just me. I'm alone in this room.