We all think we’re smart enough to not be tricked by a phishing attempt, right? Unfortunately, I know for certain that I’m not, because I entered my GitHub password into a lookalike phishing website a year or two ago. Oops! Fortunately, I noticed right away, so I simply changed my unique, never-reused password and moved on. But if the attacker were smarter, I might have never noticed. (This particular attack website was relatively unsophisticated and proxied only an unauthenticated view of GitHub, a big clue that something was wrong. Update: I want to be clear that it would have been very easy for the attacker to simply redirect me to the real github.com after stealing my credentials, in which case I would not have noticed the attack and would not have known to change my password.)
You might think multifactor authentication is the best defense against phishing. Nope. Although multifactor authentication is a major security improvement over passwords alone, and the particular attack that tricked me did not attempt to subvert multifactor authentication, it’s actually unfortunately pretty easy for phishers to defeat most multifactor authentication if they wish to do so:
- Multifactor authentication based on SMS is extremely insecure (because SS7 is insecure)
- Multifactor authentication based on phone calls is also insecure (because SIM swapping isn’t going away; determined attackers will steal your phone number if it’s an obstacle to them)
- Multifactor authentication based on authenticator apps (using TOTP or HOTP) is much better in general, but still fails against phishing. When you paste your one-time access code into a phishing website, the phishing website can simply “proxy” the access code you kindly provided to them by submitting it to the real website. This only allows authenticating once, but once is usually enough.
Fortunately, there is a solution: passkeys. Based on FIDO2 and WebAuthn, passkeys resist phishing because the authentication process depends on the domain of the service that you’re actually connecting to. If you think you’re visiting https://example.com, but you’re actually visiting a copycat website with a Cyrillic а instead of Latin a, then no worries: the authentication will fail, and the frustrated attacker will have achieved nothing.
The most popular form of passkey is local biometric authentication running on your phone, but any hardware security key (e.g. YubiKey) is also a good bet.
target.com Is More Secure than Your Bank!
I am not joking when I say that target.com is more secure than your bank (which is probably still relying on SMS or phone calls, and maybe even allows you to authenticate using easily-guessable security questions):
Good job for supporting passkeys, Target.
It’s probably perfectly fine for Target to support passkeys alongside passwords indefinitely. Higher-security websites that want to resist phishing (e.g. your employer’s SSO service) should consider eventually allowing only passkeys.
No Passkeys in WebKitGTK
Unfortunately for GNOME users, WebKitGTK does not yet support WebAuthn, so passkeys will not work in GNOME Web (Epiphany). That’s my browser of choice, so I’ve never touched a passkey before and don’t actually know how well they work in practice. Maybe do as I say and not as I do? If you require high security, you will unfortunately need to use Firefox or Chrome instead, at least for the time being.
Why Was Michael Visiting a Fake github.com?
The fake github.com appeared higher than the real github.com in the DuckDuckGo search results for whatever I was looking for at the time. :(
> The most popular form of passkey is local biometric authentication running on your phone, but any hardware security key (e.g. YubiKey) is also a good bet.
I agree passkeys are great. What I don’t get is why browser vendors are making the barrier to entry so high. There’s no inherent reason that the passkey concept should be tied to any kind of hardware security module — if my browser has an entirely software-only passkey implementation, that still completely fixes phishing!
It is less secure against malware infection, of course. But it also drastically reduces the barrier to adopting pass keys so I don’t understand why passkey deployment is done the way it is…
And of course there is . Seems like passkey might soon only work if you let Google or Apple handle all your authentication, and not work with YubiKeys any more. :(
Or maybe I am misunderstanding what the post is about?
No one is going to take out support for physical keys like Yubi.
And there is no reason to open up the vulnerabilities of non-hw backed passkeys. They already implemented a way to sync TPM/etc keys across devices (via MS/Apple/Google accounts, we need an OSS/independent service for this…), while keeping at least some of the protections of hw-backed security (though personally I don’t understand all the details and will keep my yubikeys thank you very much)
> so I’ve never touched a passkey before and don’t actually know how well they work in practice.
They are great, I use yubikey with desktop and phone (Firefox). Though I wish some ‘low value’ sites like random forums would start implementing pure-passkey auth, no need to have a username/password, just go to the site and hit the yubikey button
Another thing that can help, even without two factor auth or passkeys, is using a browser-integrated password manager to log into sites. It’s a strong sign that you’re on a phishing site instead of the real deal if the password manager doesn’t show any passwords that match the site.
Last I tried, tho, the Bitwarden extension wasn’t working with GNOME Web’s WebExtension support.
I use Epiphany’s built-in password manager. I think I actually _was_ surprised that my GitHub password did not autofill on the phishing site, but the autofill logic is complicated and doesn’t work on various websites, so instead of setting off my alarm bells, I would have just assumed it was broken. Password autofill is surprisingly complicated and although I’ve fixed many bugs over the years, it’s still not reliable.
https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/
TLDR
Google and Apple try to control it and therefore it is already looking bad. Honsetly I don’t understand why the Author doesn’t like “resident keys”. Limited storage capacity is a problem of the device.
Passkeys are not only secure, they’re the most convenient and private authentication method. No need to remember or type in anything, no need to link to social media accounts and of course you get the fancy unlock UI provided by the OS. I wish more websites would support passkeys. On Linux it seems passkey support is hinged on xdg-credential-portal, so hopefully that comes along sooner rather than later…