(if so, it nearly got me!)
/cc @github pic.x.com/jgt4oNvjF2
That's not how 2FA works
Another day, another high-profile website cloned to phish credentials.
Is this a phishing attempt? Goes to "
githubverification.com" and asks for username and pw
(if so, it nearly got me!)
/cc @github pic.x.com/jgt4oNvjF2
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.
| Reply to original comment on twitter.com
| Reply to original comment on twitter.com
Lee says:
Link: shkspr.mobi/blog/2021/01/t…
Comments: news.ycombinator.com/item?id=258102…
| Reply to original comment on twitter.com
justin says:
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.
@edent says:
Phil Ashby says:
| Reply to original comment on social.linux.pizza
| Reply to original comment on twitter.com
| Reply to original comment on twitter.com
This is a great example.
| Reply to original comment on twitter.com
WebAuthn fan says:
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.
(And U2F/WebAuthn have real promise, but you’re right, they are still early.)
| Reply to original comment on snarfed.org
José Franco Campos says:
| Reply to original comment on twitter.com
drrjv says:
@edent says:
"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!
| Reply to original comment on theoverspill.blog
| Reply to original comment on twitter.com
SQRL fanboy 6 says:
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)
@edent says:
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?