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).

>They're phishable the same way an OTP token is

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)