That's not how 2FA works
shkspr.mobi
shkspr.mobi
Yes, 2FA won't protect you from being phished by a site if you aren't careful. 2FA absolutely will protect you from a phishing site using the password it stole.
So no, when someone says "Use 2FA if you might be phished" you shouldn't be replying "That's not how 2FA works", you should reply "That's right! But let me explain why you are still at risk of password theft and should still be careful."
The page mocking the login page where you need to answer the 2FA will simply phish your 2FA then, after a little delay pretending there's some lag, would say "wrong code, please try again". Now the person enters a second 2FA (which, due to the delay, would be different than the first one).
As I've just commented in a top-level comment: I've seen sites using a 72 hours delay before any destructive change can be made, coupled with the sending of an email containing a link allowing to unilaterally prevent the change.
I've also seen sites using two 2FA (TOTP style), one for login, one for any setup/destructive change. And there are sites using both techniques.
It's not 100% foolproof but it's better than "one 2FA phished and it's game over".
The author is pointing out that they will steal both the password and your 2FA token.
2FA (at least the simple OTP variants) don't protect against phishing, they just protect against sloppy phishing attempts.
In fact the phishing toolkits have been doing TOTP passthrough/relay for a few years now. For the attacker, it's a nice feature: victim could be using SMS, authenticator app or even an out-of-band delivered token book - they are all captured and passed along equally well.
U2F and FIDO2 with hardware keys are the only realistic safeguards. On the other hand, I do subscribe to the stated problem, because for most people they are a usability snag. The NFC variant has the potential to address this, though: instead of plugging a key in and touching the blinky button, you just wave your keyring next to the device. Too bad NFC readers are not universally available on phones, tablets or laptops.
That's assuming one used a different password for the email or mobile provider.
I don't use SMS, deprecated it 10 years ago in favor of e-mail, and would never use SMS for 2FA. I still have a virtual SMS number that forwards to my e-mail for the idiot sites that still insist on it.
For most people, SMS is hackable, tied to a single battery-powered device, easy to steal (after which for most people in the default phone configuration the SMS verification codes will happily pop-up on the lock screen without unlocking the phone), and hugely inconvenient if you are in front of a desktop computer all day and have to go find your phone (at home for example I pretty much never have my phone next to me). SMS also famously locks people out of their accounts when they go to another country and have to use a different SIM card. Also, if you have a giant desktop in front of you, it's ridiculous to not use that as your 2FA device. You should NEVER have to pick up a 6" handheld device for 2FA when you have a massive immobile, hard-to-steal device in front of you that in my case is also physically locked down to furniture.
Yubikeys and other U2F keys do exactly this.
The article is wrong about one thing:
"But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom."
No. My preferred way to use Yubikeys is to buy one for each immobile device (home/office desktops) that stays plugged in, and ONE mobile key that lives in my wallet. Register all keys with critical services. If any device gets stolen (highly unlikely for the immobile devices, the mobile device is the only one I need to worry about really), go home, log in with another key and remotely disable it.
My main gripe is websites that don't allow multiple Yubikeys. AWS is at the top of my hall of shame.
Unfortunately most of the sites I use do not have anything to do with them.
Really? How? Last time I tried to do this it turned out that apps/sites would not send to these virtual SMS numbers.
B. Find a different virtual SMS number. Try other countries as well. Sometimes it costs a small monthly fee but I don't want to give in to their idiotic game.
Not if it also steals the 2nd factor. My response would be more like "2FA is good but not for this problem." This problem is about going to the wrong site. The solution is to go only to the right site.
This is necessary as you would else wise be permanently be locked out if you lose your U2F key.
That is assuming you can't reset your U2F key using mail password recovery. But your mail being a single point of failure is something U2F normally tries to prevent.
Through I guess for not relevant services. I would still want U2F but allow mail recovery and maybe even U2F _only_ login (or FIDO login without PIN).
Given that people have different opinions about what is important I guess this should be an option for fallback recovery, maybe with some warning around it.
The "workaround" to have no fallback for U2F is to generate recovery keys and then not store them anywhere ;=). But I would not recommend this, except if they have a insecure mail based password/U2F recovery anyway.
Since when?
Sure, but isn't that the point? There's now a second thing they have to steal, and if they only get the first it's pretty worthless, especially if there's monitoring/alerting in place that prompts a password change and/or locks your accounts pre-emptively.
So, in case of phishing that's not the point. If you're actively logging in yourself a second factor doesn't prevent the attacker from gaining access.
In Webauthn/u2f the 2nd factor is a proof that is unique against the particular site. So stealing the 2nd factor is significantly more difficult since it requires compromise of the computer/endpoint used to access the site to pass the wrong site to the hardware token, or cloning the physical device which should be tamper resistant (but not totally unheard of to clone some devices).
Your statement is true for HOTP/TOTP based 2nd factor like google authenticator on a phone, although the stolen credentials shouldn't provide persistent access.
And password re-use is still a problem if every service isn't covered by Fido2, but we need to start somewhere.
Given a successful login and session, perhaps on some sites this is enough for passwords reassign via some backend (likely intended for mobile apps) API?
i.e. blame the victim. This generalizes to: the solution to user error is for the user not to make errors.
So no, that is not the solution.
No. That is never the real solution. At best it is a necessary evil, but generally resorting to this is a reflection of a failure of imagination.
The reverse authentication problem in particular is easily solved by the right UI design plus some improved infrastructure behind the scenes. Certificate pinning, for example, would help a lot. The hard part is not coming up with a solution, or even implementing it, but convincing everyone to adopt the solution because it doesn't help unless it is widely deployed.
Unless you have a 100% vendor controlled system, (more than Apple + ChromeOS combine) you have to rely on the user not breaking their own security.
- Your solution is not sufficiently great as to be self-evidently great.
- People (i.e. the victim) must be faulted (i.e. blamed) for their inability to be convinced of its inherent majesty.
- Given convincing's similarity and overlap both with educating and with training, you are having a failure of imagination. (Source: Your comment.)
There may be viable solutions that include still going to the wrong site, but I know for a fact that going to the wrong site does not happen if you go to the right site. It's a tautology just like your disingenuous Twitter-style reductionist accusatory re-interpretation of my comment suggests. Speaking of which, if you want to blame the victim, go right ahead (that was your idea), but I don't think the computer cares who gets blamed, unless and until it affects what gets typed in or clicked.
Mainly U2F incorporates the domain and (should) only work if an TLS connection with a valid certificate for given domain is used. Furthermore it uses a key exchange. This means:
- The attacker needs a valid certificate for the applications login domain, which wrt. web security is normally assumed to not be possible but tbh. might be possible in case of an state actor or similar.
- The attack needs to be live in the sense that password and 2FA auth needs to be directly forwarded to the attacked web-application and there it needs to trick any bot detection to make it believe it's not a bot. This also means even if they phish your authentication they only can use it once at the moment they phished you. But to e.g. then to disable U2F they often need to enter another password, so they need to phish you twice in a row, which is harder, but only slightly harder, tbh.
- Alternatively they might hack the service and get their hands on the private webcertificate and clients private key if the service doesn't use a HSM for that. But that is normally much harder and for many attacks unfeasible (and there is normally little reason to phish if you can hack a server that deeply).
The second half of the article goes into detail about the shortcomings of U2F (using "Yubikeys" as it's terminology)
So that leaves ease of setup and support. Since setup only has to be done once per site, and I only bother with important sites, that’s not a major deal for me either.
For either of those methods, stealing two SMS/TOTP codes isn't that much harder than stealing the first one - you just display a fake error saying that it failed, and try again.
For all but the most attentive folks - getting a "Whoops, try again" error when authenticating is probably going to be a semi-regular occurrence anyhow, so adding a fake one in there probably won't trigger any mental alarms.
All they have to do to achieve this is to use the phished credentials to immediately login with the original site, trigger 2FA and then show a field to capture it and pass along. Then capture all the cookies.
The best defense against phishing is to use a password manager that does domain matching.
In addition to that, now I noticed that in the blog post:
> 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
WebAuthn keys--physical dongles you plug into the USB port--are indeed problematic for the reasons the author notes. (A small--but user-visible--cost; the requirement for a spare USB port of the right form factor; loss.)
However, authenticators that are built into the client device (e.g. Apple's support for a TouchID-verified WebAuthn authenticator) solve these problems, to varying degrees: the user doesn't see a marginal cost (it's built into the computer!) and doesn't have to worry about loss, USB ports, etc.
The principle challenge with using (as an example) Safari's WebAuthn support is what how the relying party should support loss of the device. (If you lose your Safari--or claim to--how does your bank authenticate you?)
Ultimately, the lost-device--or new-device bootstrapping--problem is currently what stands in the way of a truly secure ecosystem, but with platform providers increasingly supporting WebAuthn, we can at least reduce phishing risk to "phishing of the platform provider credential." Your iCloud password might get stolen, but at least that's the _only_ thing an attacker can steal to gain access to your other accounts.
For most services, delegating authentication (and anti-phishing) to someone like Apple is a big plus.
Apple, Microsoft, and Android all support WebAuth (https://blog.mozilla.org/security/2019/03/19/passwordless-we..., https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-..., https://docs.microsoft.com/en-us/windows/security/identity-p..., https://developers.google.com/identity/fido/android/native-a...), so most (??) users are in fact covered.
eBay, for example, offers a passwordless experience using WebAuthn--so it can be done, even on a major consumer site.
The problem is really that until relying parties can trust that
1. Platforms will backup and restore key material from authenticators 2. Users will figure out how to use those backups (including if they e.g. switch from Mac to Windows)
they will have to provide some fallback. (Realistically, that means "for the foreseeable future.")
This relegates WebAuthn, unfortunately, to a "neat trick"--eBay's "passwordless option"--and not a security guarantee. (Phishers can always downgrade the user to passwords or similar.)
What's needed in the interregnum is probably a way to make that fallback option more secure by, at minimum, conveying to users that it's not _normal_--so that phishing attempts targeting that phishable backup are less likely to succeed.
Unfortunately this requires a lot of good UX design and unilateral action on part of the relying parties, which I think is tough.
TOTP and U2F actually has achieved pretty wide adoption, so I have hopes for WebAuthn.
[0] https://krypt.co
I do think (as I said elsewhere here) that ultimately people will adopt WebAuthn via their browser/OS vendor. Support is widespread! But for relying parties, there are still challenges to solve.
Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero trust" of Krypt.co, it still requires complete trust of Apple or Google.
Perhaps completely trusting one of those companies is already the reality for nearly everyone, in terms of using a mobile device to access online data, but hopefully WebAuthn-supporting sites don't put extra restrictions on the devices you can use, via the "feature" of attestation:
https://www.imperialviolet.org/2019/01/01/zkattestation.html
Also, a lot of people who use Krypton don't know that SSH keys actually don't use the secure enclave because it doesn't support rsa or ed25519: https://github.com/kryptco/krypton-ios/issues/73#issuecommen...
Vanguard, for example, only trusts Yubico keys, and it's a pain in the ass.
That said, your complaint about Secure Enclave/Keystore trust doesn't make sense to me. Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no?
I was trying to draw a distinction between the OS (which could in principal be built from a trusted set of source code) and the firmware controlling the tamper-proof SE/Keystore.
In the case where the SE/Keystore is controlled by something like the Intel Management Engine, that distinction might be meaningful, but you're probably right that in general if you don't trust the device manufacturer then it doesn't matter how the SE/Keystore is implemented or managed.
Moreover, I suppose if you trust the OS to be doing what it's supposed to, the only things a malicious SE/Keystore can do are cause a denial of service or fail to keep your secrets (in the worst case by broadcasting them with a hidden antenna).
I mean, in the extreme, yeah, malicious hardware can exfiltrate secrets. A hidden antenna, as you say—or more subtle attacks (e.g. https://dl.acm.org/doi/10.5555/1267336.1267341, though this would require more than just the Secure Enclave to be malicious).
But yeah, I think for the ordinary consumer this is not a useful distinction. For vendors who are thinking about supply chain attacks, for sure this is a real consideration.
I much rather have Yubikey over all other forms of security because it simply forces the attacker to be physically present. Why is that important? Because even if your laptop is stolen with your Yubikey at a local Starbucks, you’re more likely to catch that person versus a completely remote attack. Security isn’t just about attacks. You also need to think about mitigation and recovery following the attack.
Realistically, you're probably not going to catch a mugger. Otherwise robberies like that wouldn't occur. Snatching a laptop with a key physically plugged in it is probably easier than snatching a laptop and a separate phone.
Regardless of my opinions on tech, if you think being mugged is "user error" then may I suggest spending a couple of days volunteering for a local Victim Support charity.
Edit: your comment also gave me an idea. Perhaps there should be a phone-based service that you can dial that locks out your account for a predetermined time period? Or it could even be tied to someone else that you can trust.
Your take is just not my experience at all. Tapping a blinking light it is much easier than fussing with a 2FA app and works when someone's phone is dead. Yubikeys in particular are near indestructible. They even work after you soak them in acetone overnight and melt the plastic off. I tried.
When it says "plug in your device" you plug it in. When it says tap you tap.
Also the mugger comment is not part of a typical threat profile. Yubikeys and similar devices are meant to protect you from remote attackers which is the class of attack 99.9999% of people need to defend against.
If a mugger points a gun at you, no form of 2FA is going to save you.
Also my Yubikey has a pin enabled and fingerprint enabled WebAuthn devices exist. I have several. If you are carrying things so valuable you are worried about being mugged, you can probably afford a higher end model with a fingerprint or pin.
Edit: yes I know random muggings happen, but a hit and run mugger that knows what a Yubikey is and already has your password is a hiiiiighly targeted attack. -That- pretty much never happens unless you are walking around with a $1,000,000 in Bitcoin in which case it has happened a total of 5 times that are public.
Two (three?) jobs back I had to set a bunch of people up on one time passcodes. Those seem pretty easy right? Still had to go there in person and show them.
Serious question; never understood how that works.
You either have other 2FA devices or backup codes.
Then there are those where you can register another 2nd factor, e.g. another Fido-Key, SMS-Codes or recovery email. Those might be better or might be worse, depending on the method and circumstances. E.g. SMS is vulnerable to all kinds of SIM-Cloning and redirection stuff, email is vulnerable to whatever your email might be vulnerable to.
The only thing I would accept as really idiot-proof and secure is "go someplace, show a government-issued hard-to-fake ID" (like a passport, not your drivers license...) like banks do. But that only works with physically present businesses and accounts that are strictly tied to one person. And even there, "Joe Smith" might impersonate "Joe Smith"...
If I somehow manage to lose both, I assume I’ll have to talk to a customer support rep or something.
However, a good solution for this issue is finally in the works: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
(1) Store their backup key in a more convenient, but less secure location (likely their home), putting them at risk of losing both the primary and backup key to the same event.
(2) Enroll only their primary key when an account is created, putting them at risk of locking themself out if they forget to add the backup at some point.
(3) Only use security keys for the highest value accounts, which tend to be a small enough number that you have a chance of actually remembering to add the backup key every time you set one up.
Of these, #3 is the only one that doesn't pose what I consider an unacceptable risk of lockout to the average person, so that's what I recommend.
The location doesn't need to be "secure" in the military sense of the term. Mainly you want it "secure" in the sense that if you lose the one key, you won't have lost the other key at the same time.
In the end, the two keys are equivalent from a risk profile if they are compromised, and for most people, the one they carry with them is going to be the weak link in the chain, so additional security on the other key isn't really accomplishing much.
In truth, if your home isn't secured, there's enough holes in most people's online security that someone in your home could find a way to compromise much of your online security (and from there, most of the rest).
Just keeping the other key tucked away in a drawer has some risk, but is pretty decent for most people. Keeping it locked in a fireproof safe in their home along with other important documents/keys/bits is a better choice and not terribly inconvenient.
If you want to be more thorough, you can always have a third key that you keep locked away in a bank vault, and you do "wing it" with just two keys for a period of time on new accounts.
What you don't want to do is "wing it" with one key (though AWS seems to think that's the way to do things). That can lead to disaster. What you also don't want to do is only use it for a subset of your accounts, because in practice most people are terrible at risk compartmentalization, so invariably a compromise of some of your accounts quickly becomes a compromise in all of them.
In my experience #1 is the right way for most people to go. There are disaster scenarios where you lose both keys, but usually that's a disaster severe enough that recovering your online access is the least of your worries, and it does a great job of mitigating the much larger risk of mismanaging the security of accounts that aren't secured with the key.
I _really_ don't agree that if one of those things happen I will no longer care about accessing my digital possessions/accounts. If anything I need that access more than I did before it happened.
And home isn't really convenient enough for many people: I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2.
You might care, but most people would have bigger problems at that point.
> I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
Yes, that's the use case where they are working to extend the protocol for using backup keys: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
Again, most people aren't on the road a lot, and most of those that do already follow so many other bad security practices when they do so that creating new accounts in that context will already be fraught with peril regardless of the mechanism you use... and they'd probably be increasing their exposure if they used a password manager. I'd advise them to not do it, or to create a temporary account using some low-security, low-tech compartmentalized mechanism (like writing the passwords on a piece of paper ;-) and then delete the whole thing and create a new one from scratch when they get home, because that's probably less likely to be a problem. ;-)
"For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2."
I do use a YubiKey secured password manager for services that do not currently support U2F/Webauthn, so I agree that is really the only practical solution for certain cases. There's an in between space where you can use the SmartCard protocol or hardware based OTP, but... My observation has been that for "most people" the non Webauthn cases are a) not necessary and b) actually far more difficult for them to manage, leading to them simply not using the password manager for a lot of cases.
It turns out the typical person's needs are surprisingly limited, but the risk is enormous as is the number of "pathways to failure".
- you can still have TOTP enabled on the site as a backup 2FA method - you can configure multiple yubi keys for a single site - so I have one on my keychain that does NFC + USB-C for my MBP, and another “Nano” key that is left in my home imac - they are both registered with most of the sites I’ve configured
If my keychain is lost/stolen then I can still login from home or with my TOTP code as a fallback.
Please try being less condescending.
Losing the keys, due to whatever reason, means losing one factor. If the user loses the key, the "mugger" still needs to get the users' passwords.
2FA = something you know + something you own. Having one factor compromised should not compromise your accounts if the service you are using is configured correctly.
That's not exactly correct. Another factor is something you are, such as a fingerprint or eye. There are three classes of factors from which drawing any two is called 2FA.
There is also a 1.5 factor auth, used for example by many banks, in which there is a server challenge for the very vulnerability stated in the article.
The "I left my keys in my coat" problem you have seems like it has a pretty obvious solution: don't keep your YubiKey on your key chain. Do you have a wallet or cell phone that you carry with you at all times? Put it in the wallet or cell phone case.
Also, if a user can't learn how to operate a Yubikey after 10 minutes I don't think there is anything that can keep them safe online.
Also, the use of a PIN or fingerprint[1] to authenticate the yubikey itself and not sent over the network, mitigates the stolen key scenario. [2]
[1] https://www.yubico.com/blog/getting-a-biometric-security-key... [2] https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...
This adds some convenience, though it also does add some risks e.g. in case of breach you can't tell which token was misused, you can't invalidate a lost key without invalidating others at the same time.
It’s an accident of circumstance you even need to buy a yubikey - your iPhone, iPad, laptop, android whatever can do everything a yubikey does. There just needs to be enough demand and time for OS and hardware vendors to come around to shipping and integrating this stuff by default. Suddenly you’ll own 3 or 4 yubikey equivalents without buying any special auth devices.
25 years into the web and our login tools remain pretty barbaric. Maybe in 25 years we’ll have it sorted out. But change is coming. Call it 2fa, webauthn, whatever - regardless of the details username/password auth (on its own) is dead.
The best second factors are separate devices with their own screens that indicate what you are authenticating to/for before you provide your authentication.
Of course, nothing ever stops a user from deputizing malware.
(though it might be tough for chimeras who have 2 sets of dna)
>Cost. The average YubiKey is £50...
If that's too expensive for ensuring your internet security, then either you underestimate the risks, or undervalue your information. If a Yubikey cost 10 times more it would still be a bargain.
>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.
Pressing the button at the right tight was a joke, right? Although, I admit it may be challenging for people with disabilities. Websites making it hard to find 2FA settings is not a Yubikey's problem, it's a website problem. Setting up a Yubikey is rather straight forward too. The main issue is the inability to clone a Yubikey programmatically, but that's the price of security.
>Convenience. My YubiKey is on my keyring. My keys are in my coat...
That's can't be serious too. I won't even elaborate on this.
>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.
That's actually the only valid point I somewhat agree with. Again, this is largely mitigated by developing the right habits. You don't leave your car keys hanging in your car's lock after leaving the car in a parking lot, right? Then why do it with Yubikey? If developing a new minor habit represents a problem, then either you underestimate the risks, or undervalue your information.
An additional password/fingerprint protection would be nice though. I agree on that.
>Support. WebAuthn is a great standard – but only a few sites support it...
Again, this is not a Yubikey's problem. It's a website problem.
I don't know if the author of the blog post means something else but if you're using 2FA tokens (i.e. Yubikey Authenticator) you can put password protection for additional security.
https://docs.microsoft.com/en-us/azure/active-directory/user...
This is different from typical U2F operations, though, where website asks for a password ("know") and a hardware token ("have"). For those, password is the secret part already.
If someone phished someone's password AND stole one's Yubikey - well, this is a very peculiar situation, where, indeed, the scenario fails. If someone steals a laptop with Yubikey plugged in - they (hopefully) don't have passwords. Unless someone had set it up to login and open their password manager with just a touch of the said Yubikey, without anything extra. Which is, again, quite a peculiar situation.
Usability is important if you want adoption outside of the HN crowd.
Even the "the key is in my coat" is not a joke at all -- I've had clients who got compromised by a malicious insider because some admin wrote passwords on a sticky note simply because "password managers are cumbersome".
I get what you're saying on each point, but understand that security is as much about discipline as the actual security you implement. You can have the best of the best, but it doesn't mean anything without the discipline to use it, and I suppose that's what the author is trying to convey.
You even touch on it in your response about developing the right habits, and that's the author's port -- without discipline, the Yubikey means nothing.
>Again, this is not a Yubikey's problem. It's a website problem.
On this point I can't really agree at all; Yubikey might have a solid solution for a problem, but if no one is implementing it, then it's a solution looking for a problem. The mythical "average user" won't be persuaded to drop any amount of money on a dongle that does nothing; if it doesn't work for a large majority of their most common sites, then it's just a waste of money.
I'd suggest it __is__ Yubikey's problem as they're not promoting their value to sites in a way that implementation is a no-brainer. Checking on their compatibility list fo common chat-applications, common forums, common message boards/imageboards, and common shops world-wide, the adoption is very limited. Surely the admins of popular sites are aware of Yubikey, but at some point there was a decision not to add functionality -- Yubikey needs to make the efforts to promote adoption and figure out where there resistance comes from.
Of my daily sites that I might expect to be aware of/implement some hardware security, only reddit is on the list of "works with Yubikey", and I pretty rarely use reddit. Listing sites my friends and family use on a day to day basis, only Google Accounts comes up.
That's what the post is talking about. Yubikey does not have the penetration to be viable to "average users", and even for tech persons, the device is useless without the discipline to adjust habits in the first place, which most people just don't have.
Totally agree on that. The author's main ranting about Yubikey is that it requires developing new habits, but that's exactly the point.
>they're not promoting their value to sites in a way that implementation is a no-brainer.
That's a good point. Although, poor adoption of hardware tokens even by banks (e.g. no bank in Canada supports Yubikey) is surely not because it's hard to implement. It's a "chicken-or-egg" problem. Organizations don't support hardware tokens because few people use them, and few people use tokens because many organizations don't support them anyway. Yubikey and other hardware token vendors could've done a better job promoting and simplifying using hardware tokens.
First of all you can get WebAuthn devices for as little as $10 now.
Second, there is no app to configure. You plug it in when it says register and tap it. Done.
Third, if the WebAuthn device gets stolen the attacker presumably lacks a password. You can't use the device by itself. Also the vast majority of attacks are remote, not IRL.
Fourth: fingerprint or pin authenticated WebAuthn devices exist if your threat model worries about physical access.
IRL attacks are a radically different threat profile.
I can't even with this article.
Looking at Amazon UK - https://amzn.to/3oWGYe4 - the cheapest appears to be about £30. Unless I want to risk my security to some no-name brand with zero customer support.
When I got my YubiKey, it told me I had to download an Android app to make it work. So, perhaps better documentation is needed?
I'm sorry you didn't like my post, I'll try to do better in future.
https://www.kickstarter.com/projects/conorpatrick/solo-the-f...
I have a few U2F Zeros and they have been working fine for years. These are simple devices. You don't need to overpay for them.
Edit: Conor was building the U2F Zero tokens for $2.26 USD per unit. Read more here:
In answer to the expense question, two Solo keys appear to set you back 38 quid at the current exchange rate. I don't know how they compare with HYPERFIDO, which I don't think I'd come across before.
From an economic perspective, unfortunately, it's really hard to focus on reducing the cost, there's simply no incentive.
First, consider that the biggest cost in the customer getting a security key is basically shipping + packaging. Imagine a key that costs <$3... even packaging with a polybag + printed label + padded envelop gets to a cost that has a significant % of the production cost.
Next, it's features. To stay on par with competition, people expect the same features (see, e.g., openpgp mentioned above - the code currently doesn't fit in the stm32l4 flash), both firmware and hardware. As a result we have to look at the latest & greatest micro, but of course that alone has a significant cost.
And finally, there's the overall viability. We all know that open source projects die without a business model. The numbers in the U2FZero review simply don't add up, that was clearly unsustainable and that's why we made SoloKeys. A business has expenses other than manufacturing and if you don't account for that, the business dies together with your dream project.
Anyway, thank you both (and all others) for the great support. One step at a time, we'll get to a stronger and eventually also cheaper product!
Integrated in to the laptop it would be great, like an Apple Watch allows https://support.apple.com/guide/imac/unlock-and-approve-with...
* https://solokeys.com/collections/all/products/somu-tiny-secu...
The stm32 used in v1 was 3x3mm, while the new nxp lpc55s6x used in v2 is 5x5mm. Plus we added 2mb of flash, though it's optional.
If anyone wants to try to packing the components into a somu v2, that'd be a nice addition to the *omu family [1] and we'd be more than happy to help with manufacturing. Same for a somu for usb-c.
[1] https://tomu.im
It is sad that with PGP being so horribly broken, it still casts its shadow over security products.
PGP should have been dead and buried eons ago.
How is ssh with a PGP key horribly broken? There's no shadow over Solo/Somu from where I'm standing.
[0]: https://www.amazon.co.uk/HYPERFIDO-MINI-FIDO2-HOTP-Security/...
If I had a corporate budget to spend maybe I'd order trays of Yubico Security Keys or Google's Feitian rebrand. But I just wanted to have more than one vendor so I have this product (well not this one, but it's the same product under different branding) and it works fine.
To give future security devices along the same vain a better chance at gaining popularity and being widely adopted (which will hopefully bringing us a more stable, less stressful society), the designs of these new devices must solve or workaround the issues the author describes.
It’s really annoying when individuals such as yourself respond so very negatively and unconstructively while others are trying to discuss the issues with existing designs — an act necessary for us (collectively) to develop new designs.
The author may not provide strong evidence for their claims, but neither do you provide strong evidence (or extensive reasoning) for yours. The net gain here is negligible, expect for showing that contrary opinions exist, but that’s not particularly helpful as for every opinion held it is inevitable that someone holds the polar opposite.
I’m not a moderator, but I ask you to please try to better further the discussion with future comments.
Nobody wants to re-setup every site ever because they lost their laptop that they kept it plugged into, so they won't. either this means using their backup until they lose it without even revoking the original and then swearing off the entire concept while telling all their friends to do the same, or just not using hardware tokens after the first lost of keys.
Also the "back up code" they will also get, guess where thats going! save as -> downloads or print2pdf -> downloads.
When it comes to personal account security by end users, hardware tokens will never take off, and this is why they get so much hate.
There is a real problem here that really needs to be really solved, wrt to end users and phishing/hack resistant credentials, and as long as we legitimize the lie that yubikey solves it, we gimp progress towards actually solving it.
There are other solutions. Being able to make one key a proxy for another is one. That allows you to keep your master identity in a bank vault, and then use it to "sign" the one you keep on you during the day. Should you lose your daily driver, just sign another one. This still suffers from the "one true name" problem though - if someone steals that bank vault ID, you're gone.
Another approach is servers allowing a client to register multiple ID's, and later delete them. Since there are multiple ID's, there isn't one true name any more. If one is lost you cancel it, and replace it with another. The approach is already built into the FIDO2 protocol, so they've already thought about your concerns and solved them, and IMHO solved them in a better way than you propose.
A more robust approach still would be a combination of the idea above: FIDO2 multiple ID's solution, plus proxies. One key could then provide multiple ID's to every server you log into, signed by different masters that are stored in different places. Keys can't be copied, but a lost key can be replaced by signing it with the master. A compromised master can be have all it's ID's dropped by logging in with an ID proxying other master. You could think of it as RAID for 2FA's.
Yes, clonable tokens. Exactly.
When people ask for clonable tokens. This is an acceptable solution.
(But skip the bank vault. This is for avg Joe, not Jeff bezos. The closest safe will do)
A modern iPhone or high-end Android phone already does WebAuthn secured with your fingerprint or (on some iPhone models) facial recognition, like your lock screen or contactless payments.
I honestly think Yubikey type devices' largest problems are - 1. Marketing. People simply do not know they exist or how they work (simple or not). 2. Support - Many websites do not support Webauthn yet. We really need developers and businesses to consider this a priority.
I have bought some keys for my family members and they love them once I demonstrate how they work.
The expense is that the security world hasn't converged on anything remotely approaching a single standard. So, a key has to support ... PGP, OpenSSH, FIDO, FIDO2, U2F ...
For example, you couldn't use some of the older YubiKeys with AWS because AWS only supported time-based TOTP.
That's a LOT of software work, and you can't be "Startup Sloppy" with your code or someone will break it.
Please don't go there. You're both adding to the discussion, maybe some strong words here and there, but this turn of phrase you used is a huge conversation destroyer.
As for the U2F devices, the idea of just leaving them in, the small yubikeys and all that, seem to just be a bad idea from the get-go.
What u2f app is this referring to? I've never needed anything more than chrome to use u2f on windows or ubuntu. Also seems weird to complain about setting up an app, when a few sentences before that they recommend installing a password manager...
Should I not have?
The "problem" is the expensive Yubikeys that you were whining about has lots of extra functionality that has nothing to do with U2F, and that's what the extra applications are all about.
I happen to use a Yubikey because I want that extra functionality, including using it to secure the keys I use for ssh and for digitally signing git tags so I can securely push git pull requests. But that's because I'm a developer, and it's why I'm happy to purchase multiple Yubikeys (one for my desktop, one for laptop, backups including one that is on a keychain, etc.) Perhaps you were reading web sites that was giving advice for developers as opposed to for consumers?
Whereas if you have RSA keys on the "full fat" Yubikey, they can be used regardless.
2FA is designed to authenticate that this is you logging in. Wrong off the bat.
The "they just use your login token" is akin to "they just hacked the CIA's database". Just.
I also don't see how the author thinks that the same users who struggle with yubikey won't simply search for the github.com login on githud.com in their password manager. Bitwarden and co are great but the default domain creates a problem where login.signup.domain.com does not match login.domain.com and so users are used to searching.
The bit that completely lost me was the lamenting of convenience with the YubiKey.
Security and convenience are polar opposites.
Coupled with the "tech bros" comment, I am not sure this is in good faith at all
He's saying that they can basically MITM you, which is true. GitHub asks attacker for token, attacker asks you, attacker gives token to GitHub on the spot, presto.
That said: I remain unconvinced that 2FA is a trivial thing to beat. Now we're talking about an active attempt to impersonate you, as opposed to a general catch-all-the-2fa-less-logins
Put another way: If you ran this phishing site, would you focus your time on the logins with 2FA enabled (which if I've understood correctly means you'd have to catch them in the window the token is valid for) or the logins without?
This obviously does have its own downsides (you have to maintain a login infrastructure, as well as your phishing infrastructure), but this was even seen before 2FA became common to detect if an incorrect password was entered into the phishing site.
It is definitely an improvement, but TOTP doesn't provide much protection from phishing, and as it becomes more popular more phishers will need to accomodate for them in their campaigns, further reducing their effectiveness here.
Pretty sure you are in agreement with the post here. IOW, 2FA isn't to authenticate the site.
Most of 2FA I use won't help you assuming the credentials I just gave the phishing site are immediately forwarded to the real thing. I will see a login verification, just like I expected, from the site I expected it to come from. Maybe, just maybe, I might notice that the login location is not where I am, for 2FA implementations that tell you that.
I suppose if they AlSO have protections against proxying (forbid more than X login/login attempts from a given IP) it might help - but certainly not against spearphishing. Honestly don’t see how you can protect against even moderate level spearphishing reasonably.
Some banks have a “word” or picture you select that they’ll show you durning login - never understood how this can’t just be proxied.
Certificate based authentication in theory allows both sides to Authenticate the Other.
It can, simple as that. Some make it moderately more difficult by showing you, say, 9 pictures and asking you to pick the one that's yours. But, again, dead easy to proxy.
It is my understanding that U2F and Webauthn can't be proxied either, but I forgot the specifics and would appeciate if someone could enlighten me.
Conceptually, you just have to generate a keypair using Diffie-Hellman, and sign a challenge after the session has been opened, so that the server can double-check you have the right key (it already has your public key).
There are two tricks involved. Firstly, your web browser is co-opted to do this work. It knows this is news.ycombinator.com much better than you do. If this wasn't in fact news.ycombinator.com, but looked correct and behaved as expected, you likely would not notice, but the browser checks the name matches for every single individual HTTP transaction.
So if the site fakebank.example tries to do a WebAuthn validation for realbank.example it just plain doesn't work.
Next, for a Security Key or similar FIDO1 device, where you can enroll an unlimited number of sites on a single authenticator since they aren't actually stored on the authenticator - the keys used are encrypted with that FQDN. So if bad guys stole your real authentication database enties at Real Bank (maybe from a backup) they not only can't use them, they can't even play them back to you and have you use them - they only work at all on the real site they were for, they're just random garbage on any other site.
This relies on a two encryption technologies. 1. Public Key Signatures (mostly using elliptic curves but that isn't essential). I can pick two related numbers, tell you one, and then in future you can challenge me to prove I know the other one on different occasions, and you'll know I do even though you don't learn the number. Your Security Key can prove to GitHub that it is still the same Security Key that visited before, despite GitHub not knowing which one that is.
2. AEAD Authenticated Encryption. Modern symmetric encryption not only keeps your data confidential, it can also simultaneously authenticate it, your Security Key knows when given back an encrypted "ID" that it's a real one it issued to this web site, because random IDs will fail the authentication step.
Either of these tricks would arguably achieve our basic security goals, but they are both adding further strengths to the system, so why not have both.
[Edited to clarify some details]
WebAuthn. The article author dismisses it as basically too inconvenient (they apparently keep their Security Key somewhere out of reach and they struggle to remember the complicated user interaction of... pressing a button)
But WebAuthn is completely effective against phishing.
The closest to plausible attacks are: The bad guys take over the target servers (no reason to phish you); The bad guys persuade you to physically send them your authentication device (truly not everybody can be helped...); The bad guys persuade you to install software under their control on a general purpose PC (this won't work on a Phone) and then you follow their bad instructions to "use" your authenticator with their software to get them in.
Mutually authenticated TLS is in principle viable, and I have used it in machine-to-machine systems, but the UX is atrocious and it has grave privacy problems.
How can you be completely confident that this isn't an attacker?
In almost all cases these were just about vanity (e.g. the university where I studied and had some of my first jobs renamed itself and gave every web site new URLs, purely out of vanity, at considerable cost with no benefit) and so when they discover it can't be done technically they just give up and continue to use the old name for authentication, meaning your security posture is intact. In the few other cases you're now going to have to have a conversation with your users about why you broke everything and need to begin over. I sure hope the gain to your organisation was worth it.
Recently Ameritrade and Charles Schwab Corp. merged ...
Any successful attack against your browser (or any other application on your workstation) allows the attacker use existing and future browsing sessions.
The attacker can simply wait until you log onto your bank account and remotely control your browser.
But if the site just captures your credentials and puts them in a database of site/username/passwords, they are useless later, even if they also store your 2nd factor of the moment. The next time someone tries to authenticate with your stolen username and password, and the MFA challenge comes up, they will be stuck. The factor they captured phishing has long expired, and the site has no ability to provide the correct value for your 2nd factor at a later time.
So in other words, 2FA does provide additional protection in this scenario, unless the malicious party has programmed the system to also hijack your session.
I honestly can't say for sure how often the phishing sites use session hijacking vs. just collecting for later use. If the first scenario is most common then no, 2FA doesn't help much. If the second scenario is typical, then 2FA provides significant additional protection over just username/password.
This is why FIDO claims protection against phishing.
What the author says is that the attacker, when you're using a FIDO security key, can simply say it's not working and force the user to switch to a different 2FA method, therefore in the end phishing the user.
Security is hard. And features make it porous.
> The top result on Google is invariably an advert for a scam site.
No, use an adblocker. It's the modern antivirus and you should use one.
I leave my YubiKey plugged in all the time. It's basically a permanent part of the computer.
Even if your device is stolen 1) it's unlikely by a technically savvy bad actor (and if you're at risk, you probably have had special data security training anyway) 2) you're still only stealing one factor. Your device should also be encrypted with a password which would protect any passwords [managers] on the device
Here is what I suggest. Let there be a field <input type=pake challenge=blah />. Whatever is typed into that field is unavailable to the front-end code. Instead, the browser computes a one-way function of the password, challenge and origin, and makes that available to the front-end.
The devil is in the details, but I'm pretty sure that a robust security analysis could eventually produce a solution that allows any user to type any password in a "super-password" field, and rest assured that the phishers are out.
The next issues would be: - How to prevent "downgrade" attacks, i.e., the user should immediately notice if a legacy password field is used. - How to convince the Internet to adopt this.
The key is only the second factor. You need to lose the key *and* have your password stolen in order to have your accounts compromised. At that point, think about what you're doing wrong as a user.
A wide variety of sites support them. I'd estimate around 1/3rd of the services I use daily (both personally and for work) support them. (That said, I got mine for $30 by signing up for a magazine subscription, and wouldn't have paid significantly more. And, of course, some of my services have been chosen because they differentiated themelves from the competition by Yubikey support.)
> 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.
Except, with U2F, that's not true. It's just "buy a device, plug it in, find the place on the website, wait for a prompt, press a button".
> Convenience. My YubiKey is on my keyring. My keys are in my coat.
That's a pretty personal problem. For me, my keys are either on my belt loop or on my desk, which means it's always handy. Of course, you can also get one of the models which is designed to stay plugged in, if that is compliant with your threat model.
> Risk. YubiKeys have no password lock of their own. ... if you’ve stolen my laptop and the YubiKey is plugged in
True, which is why they're not generally suitable for standalone use; only as a second credential. Also, if your threat model has you worried about them being stolen together, simply don't leave them plugged in together.
> Support. WebAuthn is a great standard – but only a few sites support it.
That's still as false it was when it was your first point.
> 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?
At the very least, it would probably cause me to double-check that I was on a legit site.
Overall: I don't think you give enough credence to the fact that it's real, secure, convenient 2FA. No more digging your phone out of your pocket, unlocking it, navigating to the app, and then setting your phone down so you can type in the code. And then locking your phone and putting it back away.
Personally, my Yubikey goes into my laptop at the start of the work day (the first time I use it), and it doesn't come out until I'm done working (well, or if I need to use my keys). All I have to do is tap the button after I put my password in.
With that even if your password manager get hacked you still have a secure account as they didn't got the U2F at the same time a password manager is a must have as it's prevents a lot of phishing attacks from even getting any chance and is quite convenient, too.
The problem with hardware keys is that for many people they are not so easy:
- You MUST generate and safely store recovery keys, storing them in your password manager is suboptimal, but better then not having them. (Not having them means potentially losing account access permanently.)
- You often need to enable it.
- You should store it with your keys, which dependent on habit might not be around your PC (in my case they always are in my pocket so :=) ).
- If your site doesn't support U2F/FIDO you might need an additional phone + app, or laptop app to get the numbers out of your key.
So while I think it's a must have for every developer to have a hardware security token lie a Yubikey it's not something I could convince e.g. my Dad or Sisters to use.
Of course if it's a 6-digit code or something, then they are able to stole my it like they did with the password.
> Then the fake site uses your real token and logs in as you. > > Game Over.
Depending on how the site's security work, it's not totally game over. I've seen sites, optionally (you still have to turn the feature on), requiring a 72 hours delay before any setup change is taken into account (like, say, a password change). During this time a warning is sent by email and you can at any time during these 72 hours, unilaterally, prevent the change from happening.
So it may be "game over" in that the attacker can login and see all you account/activity/data (which, yes, is really bad) but it's not totally "game over" as in it doesn't mean "logged out of your account" (unless the attacker also compromised your email ofc, but now we're talking about something else).
Most sites that support U2F support enrolling multiple tokens, so just have one in each machine.
Theft of a machine still needs your password to access the accounts, so it's not "keys to the kingdom" as the article suggests.
I feel that this article is... wrong.
For many websites the Cert is owned by Cloudflare and shows Cloudflare as the Organization and not the website owner. In that case there is no way for me to figure out whether I'm on the actual site or a phished site.
For example see this (it is the Visa opt-out website that was posted a few days ago on HN): https://marketingreportoptout.visa.com/OPTOUT/request.do
Supposedly the above it authentic, but the Cert is showing Cloudflare as the Organization. Now unless the claim is that Cloudflare will never serve phished websites, which I doubt unless Cloudflare is doing a human validation for each client, this is a problem.
Even so, I’ll expect financial institutions to have that.
Note: I’m not saying the above is a Cloudflare issue, perhaps someone at Visa was being stingy - I’m just saying it’s an issue and would be bad if that becomes the mainstream.
For added protection, you can prompt the user to select which nonce is correct to force them to verify it is correct. The Microsoft authenticator does this sometimes.
The downside of this approach is that it requires a constant connection between the second factor the service. It also relies on the fact that the service authenticates itself via TLS or some other means, though that is a relatively minor issue.
To take the OP's example, if by mistake you are tricked into visting githud.com or something, they can get your password (bad!) but if they try and MITM the FIDO, they'll send a digitally signed message for githud.com on to github.com. This will not work as intended (except for the user, because their github account isn't compromised yet.)
Indeed the point of FIDO as I see it is that it's less security critical for the end user to validate the identity of the site, which optimistically speaking about 95% of users will fail at anyway.
Interestingly, copying the credentials between Yubikeys will not result in an accepted yubikey OTP. The serial seems to be used somewhere in the calculation.
A yubikey, using the CLI tool, can have TOTP credentials stored inside. This can be used in conjunction with grep and sed for any CLI scripts that may interactively request a TOTP.
does anyone know if its posible to reuse these fips pki tokens? they are cheap enough.....
I was looking for the punchline but it seems like there isn't one. Complaining about hardware tokens and then saying they are the future doesn't contribute much...
2FA is used to prevent or mitigate the impact of phishing or other attacks where a password is compromised (password reuse, random guessing, keylogger, etc.). The author does bring up one hypothetical attack -- a man-in-the-middle attack -- where someone can trick a user into providing their 2FA or triggering an authorization (like with a Duo push). This requires the ability to execute a real-time attack.
FIDO/U2F/Webauthn (I still haven't figured out exactly what you're supposed to call them) security tokens solve that use case by allowing the website to authenticate directly to the token. That can't be phished -- even if you're tricked into a fake website and given a fake webauthn prompt, AFAIK there's no known way to proxy or otherwise intercept that second factor authentication to allow a phishing attack to succeed.
His complaint that the token doesn't have a password is largely pointless -- the token is the second factor, the password on the site is the first. If you're using passwordless FIDO2 logins, then it does have a PIN.
Long story short, this guy is full of crap.
If you could trust users with "always check for this personal code in the emails, ignore emails without it" we could also trust them with "your bank will never email you a login link"
I like the feature `From: <> via <>` in the view, maybe this tipped her off - "palette.cloud" is an unlikely envelope-sender for github mail. Reactivating an old gmail account, I can't see how to enable the feature.
In a muttrc, you can get context with showing you more headers.
ignore *
unignore from: to: cc: date: subject: user-agent: x-mailer: return-path: authentication-results:
hdr_order date: from: return-path: to: subject: user-agent: x-mailer: authentication-results:
However, stateful 2FA like sending an SMS to your phone, or popping up a notification on your banking app is much harder to spoof, and would have protected the user here.
It is tied to the site keys and not the address nor even the CAs.
It forces you to check and think before doing your thing.
And It is easier to use than 2FA, since it is one factor, open your key one time, the key auths you as long as you want.
A password manager won't offer to auto-complete if the protocol/domain does not match with what you've saved. This is an immediate red-flag that something fishy is up.
Wait what now?
Instead it's "in theory" and "can help". No, it totally addresses the issue of phishing your 2FA token and it does so in practice.
The pricepoint mentioned is over twice what the cheapest Yubikey is - $24.99 [0]. The author states the "average" cost is £50 and "there are a few around £30". Again, 24.99USD for USB + NFC yubikeys that support U2F/webauthn.
'usability' and 'convenience' are the same thing but split into two points, which give the impression that there's a whole other issue, but it's really the same thing.
> 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
So for TOTP it's install the app, configure it, find the setting on the website, enable it. So Yubikey adds the one additional step of "buy it", all of the others are the same for all other forms of 2FA. "Press the button at the right time" come on... as opposed to "find the TOTP and type it in on time" ?
The 24.99 USB Yubikey also supports NFC, so like, "has USB or NFC" is the requirement - I'm seriously struggling to think of a device that doesn't meet this requirement.
The author states that leaving the yubikey in the laptop increases risk. I find this to be a mixing of threat models personally - we've solved credential phishing with the 2FA token, but now you're talking about a threat where the attacker has unfettered physical access? I just don't see why that's relevant, sorry.
And for support, I think it's important to note that most sites are not sensitive. But a couple of important sites are. The most important is probably email, since email is effectively an auth mechanism for most other sites via account recovery. So just by protecting email you're protecting every other site. That's really important.
IMO,
Yes, Yubikeys should get cheaper. I certainly hope they do. At my company I give every employee 2 Yubikeys and they are theirs to keep - they're free to use them for personal accounts. I hope more companies do this in the future, essentially distributed U2F to the workforce.
But, otherwise, I really think that the benefits are being drastically undersold and I think that the criticisms are really not particularly fair.
[0] https://www.yubico.com/product/security-key-nfc-by-yubico/
That's correct. On the first visit (or enrolment).
All subsequent visits (many more!) do identify the site, or rather they tell you that you're logging in to the same site as all those times before.
I don't understand what you mean. Something about 2FA does this? How?
The details are complicated, but basically: If you register the key at github.com and later get phished to visit githubverification.com, then the authentication will fail no matter what the phisher does.
* Spew random crap claiming it is your githubverification.com key ID, ask you to sign in with this ID. Your authenticator won't recognise this ID and it doesn't work
* Proxy your real ID from github.com and present that from githubverification.com asking you to sign in. Your authenticator won't recognise this ID because it's for the wrong site, though it doesn't know that's why. It doesn't work.
* Proxy the ID from github.com and insist this is github.com. Your browser says "Er, no? This isn't github.com fool" and the UX doesn't fire.
Notice that the attacker not only doesn't get working credentials for signing into GitHub, they don't even get broken failed credentials that don't work, they just get a Javascript error at best.
This leaves a human to try to make deductions about whether githubverification.com is github.com which is something humans are terrible at, so game over.
If you have WebAuthn then your browser also takes responsibility for only letting you use your github.com credentials on github.com and not even bothering you with any other possibilities that you might think could be safe and are not. That's why WebAuthn prevents phishing.
In this exact form, this is a feature that's absent from mainstream browsers today. Because browsers do not have this, people instead turn to all sorts of other signals to judge the site's identity, but each one of those signals is designed for another purpose, and ought to not to be used directly by the user to make such determination. But no other signals are available, so they get used nonetheless.
Some people look at the URL before clicking it, or the URL bar in the browser after they've already navigated to the site, and try to judge from the URL whether the site belongs to the entity they intended to visit. This is fallible for a bunch of reasons, including: (1) people often read visually instead of comparing codepoint-by-codepoint, so reading errors or homoglyph attacks are possible, and browsers can only meaningfully mitigate against the latter; (2) very few people keep a computerized allow-list, so they check against expectations in their head; and (3) some organizations will make use of domain names that greatly differ from their own name, which works contrary to the instinct of a URL-judging user who consider themselves 'cautious', and it's difficult to stay aware of all this.
Some people look at the TLS certificate, and try to judge from the information displayed by the browser about the cert whether the site belongs to the entity they intended to visit. This is fallible for a bunch of reasons, including (1) DV certs only prove that someone (i.e. anyone) had control of the domain at the time near the cert's issuance, so its value as a trust signal to the user ought to be zero and immediately reduce to the prior case of mentally validating the URL by its character content; (2) EV certs validate against a legal entity in some jurisdiction, but as the 'stripe.ian.sh' stunt has demonstrated, jurisdiction-by-juristiction registries of legal entities are a tool for a different use-case and were never intended to collectively ensure globally unique Organization names; and (3) in their rush to ensure widespread TLS deployment on all sites, and their involvement with efforts to bring short-lived cost-free DV certs to everyone, browser-makers began de-emphasizing the UI distinctions between DV certs and EV certs some time before the true shortcomings of EV as a user-facing trust signal were widely demonstrated.
Some people look for the visual design of the website. This is trivial to fake.
Some people will rely on browser-resident bookmarks, browser history, or 'top sites' tiles to navigate to common sites they've visited before (or to sites the browser-maker pre-loaded into the listing). This is a great way to preserve the trust chain and reduce the likelihood that the user arrives at an unintended site by mistake. But these features do not directly address the case of a person navigating to a URL they were linked or provided from an arbitrary source, such as the example raised in the article.
Building blocks exist today that could be used by publishers and browser-makers to aid users in judging URLs. Some of these will require past UX decisions to be undone.
For example, top sites could become their own Root Certificate Authorities [1] and be listed in browser trust stores; these companies would be expected to issue certs for sites associated to themselves. This would eventually reshape the cert landscape so that a parent-child relationship between issuer and subject could be meaningfully distinguished from a 'provider and customer' relationship. Companies that provide services to others, such as payment processors, could also become root CAs and sign for their customers. These changes, and a browser UX that once again shows the cert issuer, would go a long way towards reducing the likelihood that users are fooled by sites trying to impersonate top sites.
If this were to come to pass, other CAs would be expected to pivot to minting certs that play the role of a trustmark, by conferring a degree of ongoing assurance that's useful to the user (which, in fairness, was the original point behind EV certs). They would do this by establishing strong brands around their trustmark, issue certs for a short lifetime, and monitor the site on an ongoing basis to see if it's still deserving of their trustmark. This would result in a business model similar to those of EV certs, but a trust model that's based on the user's trust in the CA's exercise of good judgment befitting their brand.
Um... no?
There are loads of copycat websites which appear in the top slot - especially for government site. https://www.which.co.uk/consumer-rights/advice/how-to-spot-a...
It's particularly prevalent in the UK, where you see companies proxying legitimate services and charging premium rate for phone calls - https://www.theguardian.com/money/2017/feb/04/beware-call-co...
I got 3 results on the screen
CanadianTravel - ETA Ad·www.canadaonlineapplication.org/
CanadianTravel - ETA Ad·www.canadatravelvisa.com/
CanadaETA - for UK citiziens - canadian-etavisas.com Ad·www.canadian-etavisas.com/
Which all look the same, and seem to charge $99 for the 'service' of filling in a form the Canadian government charges $7 for.
After that there is a wikipage for the Spanish terrorist group, two more wiki pages, then finally
The official site: Electronic Travel Authorization (eTA): How to apply - Canada.ca
Searching google for "Canada ETA" gives the above 3 adverts and also a link to https://www.etatocanada.com/ which charges £69 for the service.
These is just competing businesses / orgs vying for your custom, where one org (the govt) is charging $0, so you should totally use them, but won't if you're foolish.
Regardless, one tiny example of all google results (goverment form services) is... the vast minority of google search results. It is certainly not "invariably" a scam.
Here's an example:
[change name deed poll]
https://www.google.co.uk/search?sxsrf=ALeKk00J9KQR_SH1ZlvHgi...
For me the top four links are clearly marked ads. (Although some people may miss that [ad] marker). After the ads there are two links to the proper gov.uk website. Then there's a link to a commercial site called "Deed Poll Office", who charge for a services that's free.
In the past that TheDeedPollOffice link ranked higher.
Similar things used to happen for passports and tax self assessment.
Apparently they aren't so enforced.
Good thing that Google is still going after you if your website has nudity on it it, however. — 'tis very important.