That's not how 2FA works
By @edent
· 2fa security usability yubikey · 23 comments · 700 words · read ~31,833 times.
Another day, another high-profile website cloned to phish credentials.
Is this a phishing attempt? Goes to "https://t.co/7b0EaPdGZR" and asks for username and pw
(if so, it nearly got me!)
/cc @github pic.twitter.com/jgt4oNvjF2
— Tess Rinearson (@_tessr) January 16, 2021
In the replies, you’ll see lots of techbros saying “this is why you should switch on 2FA people!!!”
Except, and I hate to bring accuracy to a technical discussion, that’s not how 2FA works!
A second factor allows a site to better authenticate you. It does not help you identify the site.
If you log on to fake-bank.com, the scammers will immediately take your username and password and send it to real-bank.com – the fake bank will then ask you for your 2FA token. That could come via SMS, email, an authenticator app, or even post. Then the fake site uses your real token and logs in as you.
Game Over.
There is almost nothing you can do to authenticate that a site is legitimate.
- Any information that you can request from the real site can be proxied to the fake site.
- The green SSL padlock means nothing for validity. Anyone can get one.
- The top result on Google is invariably an advert for a scam site.
Realistically the only thing you can do is look for “out of band” verification. What’s the URL stamped on your credit card? What’s written on the welcome letter sent by snail mail?
None of these are infallible – and they can all be manipulated by a suitably determined attacker.
The best defence is to use a password manager. I recommend the open source Bit Warden.
A password manager stores your passwords. But it also stores the web address of site’s login page. If you visit githud, the password manager won’t prompt you to use the login details for github.
Defence in depth. Use 2FA to prevent attackers masquerading as you. And use a password manager to prevent fake sites masquerading as real sites.
What About YubiKeys?
No. I'm not a big fan of YubiKeys. In theory, a hardware token can help with this. You register the token with the device and it spits out a code only to the correct site.
But it has significant downsides.
- Cost. The average YubiKey is £50. There are a few around the £30 price point. That’s a huge expense given the small number of sites that support them.
- Usability. Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time. Take 10 minutes to watch a normal user try to set one up - then tell me if you think this is a good solution.
- Convenience. My YubiKey is on my keyring. My keys are in my coat. My laptop is not near my coat. Given how often I need to log into things, it means adopting a significant change of habit. Or leaving my YubiKey plugged in all the time. Which leads to…
- Risk. YubiKeys have no password lock of their own. At least my crumby Android has a fingerprint lock to prevent people getting my 2FA tokens. But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom.
- Support. WebAuthn is a great standard – but only a few sites support it. While it is good at protecting a handful of sites, I encounter it so infrequently that I regularly forget how it works.
While a WebAuthn request can't be proxied - there's nothing stopping a fake site from asking for your token, then rejecting it and asking for a separate factor.
If fake-github.com said "Hmmm we're having problems with our WebAuthn backend - please use a one-time code from your authenticator app for added security" would you be fooled?
WebAuthn and hardware tokens are probably the future. And they’re probably the best way we have to verify site legitimacy. But they’re also currently a poorly supported usability disaster.
Stay safe out there.
Mastodon
Twitter
Facebook
LinkedIn
Reddit
HackerNews
Lobsters
Pocket
WhatsApp
Telegram
For what it's worth, on macOS (at least with Chrome), Touch ID works automatically as a WebAuthN provider with no additional setup needed. I assume it has the same attestation features as U2F, but you are then stuck with only being able to log in on one computer.
Which is really frustrating. It feels like Apple with their tight integration could store the actual key against an iCloud account, then use biometrics to unlock the key, making it available across all devices. (There may be glaring security holes I’m missing here)
Biometrics is the equivalent of a username, not the equivalent of a password. It’s madness to unlock everything just by receiving the correct username :-/
That's not how 2FA works
Link: shkspr.mobi/blog/2021/01/t…
Comments: news.ycombinator.com/item?id=258102…
"If you visit githud, the password manager won’t prompt you to use the login details for github."
I guess you're talking about password managers like 1Password circa 2015 when they did an affordable lifetime license. Yeah that was a quaint feature. Now with the monthly fees, I have no idea what they're doing and it irks me to no end. I mostly must search for the site on my own and let it fill in the credentials, leaving me wide open to attacks like this. Massive regression.
As I say in the post - use https://bitwarden.com/ - it is free and open source.
Or indeed KeePassXC which is similarly open source and browser compatible.
@Edent thats why I never click on links in mails, especially if I did not request the mail myself
Sounds like you could use a YubiKey implant. (joke)
And to the surprise of nobody, someone's registered githud dot com.
Techbros who understand like a third of the thing they're talking about, insisting a very non-trivial problem is actually really simple and basically solved already is one of my biggest pet peeves.
This is a great example.
While I feel with your frustration here and I love that you increase awareness about this common misconception, but I would think twice before dismissing WebAuthn like this. I do not mean to insult you, but it looks like your knowledge might be a bit outdated, as there was A LOT of updates in the past 3 years. I would definitely recommend giving it another try (or even an updated blog ;-)).
With mainstream OS (Windows Hello / Mac), you get a built-in WebAuthn authenticator that is biometrically protected for free. Even without a backup security key, using it as a primary factor would arguably provide a substantial improvement both in 2FA UX and the security of users.
I also disagree here as your laptop is hopefully encrypted (if it's not, then you have bigger problems than yubi in it). This makes it basically an equivalent of stealing a yubikey itself, e.g. on keychain.
The rest of the points are well described in https://news.ycombinator.com/item?id=25810985.
Hell yes. I’ve been advocating password managers as an anti-phishing tool forever. Glad to see that movement is gaining steam!
(And U2F/WebAuthn have real promise, but you’re right, they are still early.)
This is not correct. Yubikey 5 series doesn't have a password in OTP mode, but they do support it in PIV (max 8 characters) and FIDO2/U2F mode (max 128 characters). It's up the user to configure the password or tap policy. The next generation Yubikey will also feature a fingerprint sensor.
https://support.yubico.com/hc/en-us/articles/360016614900-YubiKey-5-Series-Technical-Manual
That’s not how 2FA works shkspr.mobi/blog/2021/01/t… (reddit.com/r/programming/…)
Would the websites (like Medium, others) that have you enter your email and send you a direct link (no password required) fix this problem?
A little. But if you visit a bad site, and give them your address, they can email you a link back to the fake site.
I feel an important point is slightly overlooked here, MFA helps with non-repudiability (the credentials used for logging in, are likely from the person that owns them) and increasing the barrier by making most attacks "live" where credentials are ephemeral and aren't repeatable in future.
"Good" MFA in your given example would have prevented the attacker from gaining access to the account, a username and password would have been acquired, sure (which is usually bad as we all know about password re-use) but the session wouldn't have been able to be completed to gain access.
A password manager, such as Bit Warden, doesn't prevent where a sites legitimate hostname is used (employer TLS stripping, dodgy internet/WiFi connection, DNS altering/spoofing with trusted certificate if HTTPS etc. etc.)
If I create a dodgy site that steals someone's username, password and MFA (TOTP token, as is most common) - I can use that within a short window (typically a couple of minutes, max) to login as them and steal the session, but unless that service has a rolling session, I'm going to get logged out, and I can't in future log back in.
Of course, if the service is a little rubbish and at that point allows removal or modification of the MFA without another token/authentication, then an adversary could do just that, remove the MFA (replace with their own) and change the password.
WebAuthn definitely has merit in this space, it's quite usable on a single device where the OS can use the underlying TPMs etc. It has functionality built-in to stop masquerading websites and even protections where legitimate websites may be proxied (employer TLS stripping or dodgy WiFi hotspot). The GitHub implementation (strictly U2F, not WebAuthn) with YubiKeys is fantastic - I have two configured in my account, one in a safe and one I keep on my keys. The U2F prevents a site from masquerading as GitHub and stealing my session - of course you are right in that a site could say it's unavailable and get me to use another method, but then how is that site going to use that info to get into my GitHub if I've only enabled U2F? They can't, AFAIK.
Where WebAuthn falls down a little is where you want to use multiple devices - like, if I register and log into a service on my mobile and store the 'credentials' in that device, how do I log in on my laptop, do I need to open a link on my mobile..?
I'd definitely recommend service teams use activities like threat modelling to help think like an attacker to surface nuanced behaviours and what-if scenarios.
Great thought-provoking article as always!
The “rogue proxy” (githud.com) could simply use your credentials in real time to issue some sort of long lived token on your account e.g. by using something like a headless browser to add an app with full account permissions etc.
Mise au point sur la double authentification (2FA) : utile mais pas non plus un remède miracle contre le phishing shkspr.mobi/blog/2021/01/t…. Utilisez un gestionnaire de mot de passe. Bitwarden en est un excellent (et libre)
SQRL is something that sadly nobody knows about, or bothers to implement, but it's something that is literally the solution to all of these problems
it's like a combination of 2fa AND password manager, you can confirm on the same device, or on a different device, so you can log in on fishy public computers, without the computer ever getting the data (either with a QR code, or with a special url)
the verification is tied to the URL, so it cannot be proxied, if siteA tries to proxy it to siteB, then the challenge siteB sends won't correspond to siteA's url, and will error
the site never gets your info, it's sorta like public key cryptography, so they can't impersonate you easily either
each site gets a unique identifier, so you're not inherently tying everything to a single identifier like email or username (though you can always add those too, if the service allows, via your profile settings or something)
there is an oauth implementation, which lets you plug it right into many existing pieces of software
it's completely public, and designed to be simple enough, yet secure
you only ever need ONE sqrl account, and can then generate as many logins as you need
there's already clients for android, windows, mac, linux, browsers, etc
there's only two possible tricky bits: there's no identifiers in it, so if the site doesn't provide a way to set up recovery info, and a way to set up your "name", then you'll show up as a random string of characters, so it's pretty much impossible for you to know/verify who the other users are, and, there's no username/password thingies or anything, so you need to have some sort of SQRL identifier integration set up for it to work (but as I said, there is an oauth-compatible implementation, which would work fine if you don't want to figure out a custom integration)
While SQRL is technically interesting - it doesn't solve this problem. The webpage literally says Obtain a SQRL app... Create the one SQRL identity you will probably use for the rest of your life.
So we're back to the same problem. What happens if you lose access to the phone with the app? If you can back up your credentials - how do you do so in a way that is easy to use and robust?