The primary purpose of U2F/WebAuthn is to break phishing attacks. Code-based TOTP 2FA, the kind you're probably using now, is already adequate to the task of making sure you're not credential-stuffed.
>TOTP 2FA is already adequate to make sure you're not credential-stuffed.
PAKEs provide defense against both credential stuffing, (some types of) phishing/MITM, CA trust etc without UX cost (a security solution that "Just works" for users with security apathy. U2F defends against compromised user space (PAKEs would fail to protect against a key logger) and require more onerous exfiltration (either physical theft of the device or biasing the U2F keys/functions)
PAKEs are --- in this context --- simply a mechanism to authenticate with a password. They're phishable the same way an OTP token is. More importantly: they're irrelevant. No mainstream web application would be able to deploy them for the foreseeable future.
Nerds like talking about how their login secrets are protected in hardware with Yubikeys, but that's not the reason why big sites deploy U2F tokens. U2F tokens were standardized and adopted as a phishing countermeasure.
100% true. I personally wish the hardware-focused U2F bit didn't predate the WebAuthn spec. I feel, because of that, way too much focus is placed on the "hardware security" bit. I view the main benefit as replacing user selected weak passwords with a non-phishable, non-server-side loggable, non-server-side sensitive secret needed authentication standard that can be implemented entirely by code, largely without user involvement, and that doesn't rely on gross failure-prone heuristics the way password managers do today. Oh, and it is all a better user experience too. It is one of those crazy wins that you just don't get in the security space that often. I really don't care if that takes the form of a hardware security key or as a pure software implementation in the platform browsers. My guess is we will strike a middle ground...with the dominant form of authenticator being hardware based...but that hardware taking the form of the devices you already own (phone, laptop, etc).
Accurate point and why I caveat the malware/phishing point with (some types).
>U2F tokens were standardized and adopted as a phishing countermeasure.
U2F provides benefits over TOTP besides phishing
-TOTP seed generation may be compromised/bad at authentication point, may not be deleted, TOTP-seed may be shared with Eve
-Smaller exfiltration profile: When producing a U2F proof, user space isn't doing computation that could be exploited. TOTP clients generate excessive secret data for the necessary task:
User: Hey computer, I need a TOTP to log into my Vintage-Car forum.
Computer: Ok! I'll go ahead and compute the TOTP secrets to your bank, bitcoin wallet, SSH keys, and literally everything else in addition to your Vintage-Car forum account. Hopefully no one's shoulder surfing you or I don't have malware!
I think it's PAKEs are a huge win for high security-apathy users but there are trade offs:
-User space has to run more code
-All user-space platforms need to be able to run PAKE code, or else all the (non-phishable, non-server-side loggable, non-server-side sensitive..) benefits go away
-Low-entropy password choices can't be prevented server side (guess this functionality could be wrapped into the client-side code)
Autofill of a password manager is a working countermeasure against phishing too: If autofill does not work there is something wrong and you should look closer...
My experience with password managers is that they work great for me, because I understand every sharp edge and can work around them. My experience when advising family to use them is that they invariably fail them and they get frustrated. Password managers rely on pretty gross heuristics to work. They are effectively trying to automate something built for a human (choosing, remembering, and entering a password). WebAuthn gives us a real API built by and for machines. This will make the flow much less error-prone and more secure.
I tend to be a little hesitant to use the browser plugins that do autofill, I think most major vendors have had a vulnerability of some sort at some point. Doesn't mean it's unsafe, it's just the tradeoff I prefer is that I'm more likely to be phished on a single account, but less likely to have my entire DB compromised through a plugin compromise.
Except autofill fails all the time for other reasons. The site has rebranded to a new domain name. They moved the login page or redesigned it. Or it was always badly designed and broke autofill. Or the same credentials are used on multiple domains (think Google, Microsoft).
I can't find a source, but my recollection is that Google developed U2F because autofill didn't work reliably enough, so many users would just paste the password manually anyway.
It doesn't matter whether the technology "works reliably enough" it matters whether the _user_ reliably won't sidestep security by pasting their password in to the phishing site. And that's something we knew the answer to decades ago: No.
Humans are bad at giving up. If there seems to be a way forward for the original plan they will press on, regardless of all indications that this now a bad idea. In fact Google had a security override in Chrome for years that was literally typing the sequence "badidea" in recognition of this. It's not specific to computer security, it happens in incident management, there's a seminal example from years back where a train breaks down, and the incident manager sees that step 1 of the response is to send a recovery train to the location, and literally _hours_ later, with passengers stranded and desperate - that manager was still wrestling with how to get the recovery train to the location so they could proceed to step 2, rather than realising that problems with the recovery train meant they needed to _abandon the entire plan and re-assess_ because humans are not good at that.
Yes and no. Yes, if the attacker controls the DNS, he can return his own server's IP, and your browser will connect to the attacker's server showing the original name in the url bar. Fortunately TLS should save you because the attacker should not have a valid certificate (but it would save you also with OTP). If you disregard the TLS/HTTPS warning, then Webauthn breaks.
