This is part two of my two-part series on two-factor authentication. If you haven’t read part one, you can read it here. I think it’s altogether more fun to read part one first before you read part two.
In part one, “2FA: You might be better off without it”, I talked about all the flaws with SMS OTP and TOTP as second factors of authentication, and why you might not even want to use 2FA at all if those are your options. This time, we’ll take a closer look at the other two authentication methods I briefly mentioned: Push Notification Authentication and the Universal Second Factor (U2F). Both of these methods are relatively new and far more secure than SMS OTP and TOTP, but they’re not perfect either and still have room for improvement.
Push Notification Authentication
If you don’t know what push notification authentication is, it’s simple: a login attempt is made to an account you own, and you get a remote push notification on your phone to allow or deny the login attempt. It’s kind of like SMS OTP, just with push notifications that come over the internet instead of insecure SMS’s that come over cellular networks, and with buttons for you to Allow or Deny a login attempt instead of an annoying 6-digit OTP you have to type in.
ʕ·ᴥ·ʔ: Sounds great!
Indeed, it is. It’s also real two-factor authentication, in that nobody can just SIM Swap your phone number or hack some secret from a database; they really need your actual phone to log in. It’s fast, convenient, and simple to use.
It still can’t protect you from phishing, MITM attacks, or malware infections, but it’s leaps and bounds better than the two OTP methods in both security and usability.
ʕ·ᴥ·ʔ: What’s the status on this thing? Is it gaining traction?
Well, it has been. Gartner said in 2017 that “50 percent of enterprises” would be using “mobile push as their main authentication method by 2020, compared to the 10 percent that are using it today.” That was 3 years ago. Well it’s–
ʕ º ᴥ ºʔ: It’s late 2020! That means it’s only a matter of time before I’m getting it, and soon! And with all this work-from-home stuff going on right now, it’s only gonna’ come to me FASTER, right?!
Well, I was going to say that it’s late 2020, and they’re not saying that anymore.
ʕಠᴥಠʔ: WHAT?!
Yeah, they don’t really talk about that “by 2020” prediction anymore. The closest thing they did to mentioning it was predicting in June this year that:
“By 2023, 60% of large and global enterprises, and 80% of MSEs, will deploy MFA capabilities.”
Gartner, 2020
Yeah, “MFA capabilities.” Not quite “mobile push”, eh?
ʕ·ᴥ·ʔ: Why? What happened?
Well, things changed; people weren’t adopting it; and the future is notoriously difficult to predict, as we should all know by now deep into 2020.
First of all, as I mentioned in my last post, phishing attacks got more sophisticated at finding ways to bypass 2FA. And as I mentioned earlier, push notification authentication doesn’t stop you from typing your username and password into a phishing page, and then hitting “Allow” on the push notification to let the hacker’s login attempt succeed. And that’s important, because phishing has been the number one cybersecurity threat in recent years.
Two-factor authentication – including the weak SMS OTP and TOTP kinds – was kind of implied (or misunderstood) to be the solution to phishing. Naturally, it didn’t live up to that perception. And companies are really cheap with their cash. If it can’t stop the number one cybersecurity threat, they’re reluctant to spend money on setting it up and keeping it running. They already did that when they invested in TOTP (you can thank Google for being the trendsetter here), so they weren’t about to switch over to a new investment in just a few short years to something else that also doesn’t solve the phishing problem, even if it is extremely convenient for users compared to OTP’s.
And then there were the people behind push notification authentication. Or rather, the people who weren’t behind it. Push notification authentication was part of the Universal Authentication Framework (UAF). UAF was started in 2014, but as late as right now, 6 years later, web browsers still don’t support the framework in any way, shape, or form.
The reasons for this are unclear, but it probably has something to do with certain unnecessary and undesirable features included in the framework. For example, in this blog post by StrongKey, the following features are apparently included in the UAF standard:
UAF allows the web application to specify a policy in the protocol, requiring the Authenticator to meet specified requirements before continuing with the Registration or Authentication, or otherwise reject the transaction. The policy may specify things like:
StrongKey, 2018
• The type of biometric capability that must be used to authenticate the human locally to the Authenticator device: finger, iris, voice, etc.
• The number of local authentications to perform before generating/unlocking keys: PIN, password, pattern, biometric, etc.
• The acceptable global positioning system (GPS) location of the user
So UAF might have required biometric authentication, and location restrictions too? I just want a simple second factor of authentication by possession of my phone; I don’t want any of these other complications! I don’t like it, I don’t approve of it, and I reckon that a lot of other people didn’t as well.
Since push notification authentication first arose as part of the UAF standard, the lack of support for UAF probably didn’t help push notification authentication’s adoption.
On top of all that, something that does solve the phishing problem showed up very soon after push notification authentication was introduced: U2F.
Universal Second Factor (U2F)
You might have heard of YubiKeys, currently the most popular implementation of U2F. They’re these USB-flash-drive-looking things that you plug into your device and use for 2FA. You attempt to log in to an account as normal, and then when it asks you for a second authentication factor, you press a button on the plugged-in YubiKey to provide it as the second factor.
It can’t be SIM swapped, can’t be stolen from a database, is simple and easy to use, and fast. Best of all, it can protect against phishing, MITM attacks, and even malware infections.
ʕ·ᴥ·ʔ: You’re not joking? This isn’t just some marketing gimmick?
No, it really can defend against all of those things. It does so with asymmetric cryptography.
So let’s say you’re registering a YubiKey to be your second factor of authentication to your email account. What it does during the registration process is key (pun totally unintended). When you register:
- The YubiKey will generate a new public-private key pair for your email account and send the public key to your computer/phone
- Your computer/phone then forwards the public key to your email provider
- And your email provider keeps the public key stored on its database
The private key, meanwhile, never leaves your YubiKey; you are the only one in the world with that private key as long as you have your YubiKey.
And with that private key, you authenticate yourself to your email provider every time you log in to your email account. The (simplified) log in process will look like this:
- Your email provider sends a “challenge” to your computer/phone, and your computer/phone forwards the challenge to your YubiKey (The challenge is just a random string of characters)
- Your YubiKey uses the private key to encrypt the challenge, and sends it back to your computer/phone, which sends it back to your email provider
- Your email provider then attempts to decrypt the challenge with the public key that it kept for your email account when you registered your YubiKey for 2FA. If it successfully decrypts the challenge (by seeing the exact same random string of characters they sent you earlier), then your email provider can be sure that the challenge was encrypted with your private key. So you must be you, and they finally let you log in to your email account.
ʕ·ᴥ·ʔ: Okay, but how does that protect me from phishing, MITM attacks, and malware?
Since your YubiKey generates a new public-private key pair for each account, each account will have its own public-private key pair. So, for example, your Gmail account will have it’s own public-private key pair, your Outlook account will have its own different public-private key pair, and another different one for your Facebook account, and another one for your Twitter account, and so on. So when you log in to, say, your Twitter account, how does your YubiKey know which private key to use to encrypt the challenge with? If it uses your Gmail account’s private key, Twitter will fail to decrypt the challenge and won’t let you log in to your Twitter account.
ʕ·ᴥ·ʔ: Hm, yeah. Can the YubiKey talk to Twitter so that Twitter can say something like: “This is for Kuma’s Twitter account?”
No, Twitter can’t talk to the YubiKey directly, but Twitter can and does talk to your computer/phone, and your computer/phone can then tell your YubiKey: “Hey, this is for Kuma’s account on twitter.com.”
ʕ·ᴥ·ʔ: Okay, but I still fail to see how this protects me from phishing and other stuff.
Oh, simple. Let’s say you’re trying to log in to your Twitter account, but you don’t know that the webpage you’re about to log in to is actually a phishing page pretending to be Twitter. Well, the address twitter.com really is Twitter, so the phishing page can’t use that, but maybe it can use twittter.com. (Side note: It can’t. Twitter already bought twittter.com just to prevent things like this. But for the sake of a simple example, let’s pretend they didn’t do that.) So you type in twittter.com accidentally, or maybe you got a phishing email that asked you to log in to your Twitter account by clicking on a link that leads to twittter.com instead. It’s a pretty small detail that’s hard to spot if you ain’t paying close attention.
ʕ·ᴥ·ʔ: Yeah, I woulda’ totally clicked on that link and tried to log in.
Yeah, and then you would have typed in your username and password. But once you get to the 2FA YubiKey part, your computer/phone would tell your YubiKey: “So, hey, this is for Kuma’s account on twittter.com.”
ʕ º ᴥ ºʔ: …
And the YubiKey would–
ʕ º ᴥ ºʔ: And the YubiKey would say something like: “I don’t have any key for Kuma’s account on a ‘twittter.com’. Whatchu’ talkin’ about?!”
Yes, exactly, and–
ʕ º ᴥ ºʔ: And this would protect against MITM attacks too!
No.
ʕಠᴥಠʔ
No, it wouldn’t.
ʕ·ᴥ·ʔ: But didn’t you say it would?
I said it can. But not necessarily that it would, right now, every single time. It can (and does) protect against phishing attacks, definitely. But MITM attacks are a little more complicated.
First of all, if you have the correct address in the URL and you’re connected via HTTPS, then you’re already pretty safe from MITM attacks. But let’s say you forgot about that, and some hacker actually managed to MITM your connection to the real twitter.com. Well, in that case, your computer/phone would say, “This is for twitter.com.” And it would say that in all honesty, to the best of its knowledge. It would even show twitter.com in the URL. But it’s not the real one. What you’d actually be connected to is the hacker’s IP address, not Twitter’s IP address. This is why the green padlock icon in the address bar is so important; it tells you whether you’re connected to the real address in the URL or not.
U2F is still a developing standard; they’re still adding more things on top of it and improving it. And one of the things that they’re working on adding to U2F is something that can protect against MITM attacks, using even more asymmetric cryptography. So yes, U2F can protect against MITM attacks. It can even protect against them right now – it has the functionality to do so already – it’s just not being implemented yet because it’s still a work in progress.
ʕ·ᴥ·ʔ: Okay, but tell me about malware. How does it protect against malware infections?
Oh, that’s simple, literally. The YubiKey is a really simple device. It just has a small chip for cryptographic operations, a little memory to perform small cryptographic operations, can read short strings of characters like “twitter.com”, and a USB plug. Some are more complicated than that, but the basic design is just that. And that’s a good thing, because a simple device like that with very limited functionality is really, really hard to infect with malware. It’s like trying to teach a dumb bear to rob a bank. Humans are smart and complicated; they can do that. Bears are too simple-minded – too dumb; they can’t rob banks!
ʕ·ᴥ·ʔ: Haha. Yeah, bears are dumb.
So the YubiKey is kind of immune to malware, and that means–
ʕ º ᴥ ºʔ: That means I’m immune to malware!
No, no it does not.
ʕಠᴥಠʔ: … Why not?
Well, the YubiKey might be immune to malware, but your computer and your phone certainly aren’t. Malware installed on your computer or phone can still wreak havoc, like telling your YubiKey that you’re logging in to twitter.com even though you’re actually connected to 1337hackerman.com. Or stealing your already-logged-in session cookies and sending them to the hacker. Or just using your computer/phone directly to send Tweets and DM’s containing more malware to all your friends and family. Or–
ʕಠᴥಠʔ: Okay, okay! When malware is involved, all bets are still off! I should have known it was just a marketing gimmick.
Haha! Yes, it was. Always read between the lines.
Unfortunately, a device won’t protect you if it’s also trying to harm you. And though the YubiKey might not ever be trying to harm you, you still need a very complicated and very smart computer/phone to log in, whether you plug a YubiKey in or not. And that smart computer/phone is smart enough to harm you if somebody can just program it to.
ʕ·ᴥ·ʔ: In other words…
We’ve got a long way to go
Two-factor authentication is still far from perfect. Push notification authentication and U2F are great; but push notification authentication has not and will not catch on; while U2F, which is part of the WebAuthn protocol under the FIDO Alliance, still has lots of room for improvement.
Having said all that, my assessments of both push notification authentication and U2F aren’t like my assessments of SMS OTP and TOTP. I think push notification authentication and U2F are good enough that everyone would benefit greatly from implementing either one into their authentication procedures.
But most of the time, you can’t. Unfortunately, most service providers still don’t support U2F, and almost none support push notification authentication other than Google and Microsoft. (Yes, not even Apple.) You might be using push notification authentication for work because your company decided to implement it with the help of Authy or Duo Mobile or some other similar company. But other than that, we’re pretty much stuck with passwords and OTP’s.
I’ll repeat what I said last time in my previous article: Passwords are here to stay. So you better be ready to continue using them for a while longer until U2F takes the world by storm (and I think it will, eventually). Until then, keep your passwords strong, unique, and safely stored in an encrypted password manager that you have copies of in multiple locations.
If you liked this two-part series, consider adding your email address to my mailing list to be notified of new articles. Just enter your email address down below. This is still a pretty new website, but I believe in quality over quantity, and I’m just doing this as a hobby, so I probably won’t post more frequently than once a month. And no, I ain’t sharing your email address with anybody. You don’t have to trust me, though; you can subscribe to my RSS feed in the site menu if email ain’t your thing.