- From: Arshad Noor <arshad.noor@strongkey.com>
- Date: Sun, 28 Oct 2018 17:00:46 -0700
- To: public-webauthn@w3.org, "FIDO Dev (fido-dev)" <fido-dev@fidoalliance.org>
As someone who has been working with PKI for two decades, its frustrating to watch people new to FIDO reinventing problems that made PKI unacceptable for consumers (and extraordinarily expensive for businesses and government use-cases). Time and again, I notice FIDO marching down the same path as PKI; account recovery is another area where the same issue has resurfaced. This problem is not a new problem. It has been debated, discussed and hashed many times over; and companies/agencies have learned that in the end, it boils down to the need for security or convenience - you cannot have both. The last 20 years of web-computing have shown what convenience has wrought: thousands of known breaches with billions of user records compromised (https://www.privacyrights.org/data-breaches). It doesn't matter what you use: OTP, TOTP, SMS, KYC, blah... any authentication scheme based on a shared secret almost certainly leads to a scalable attack and compromise. The tendency of some of the largest companies in the world to treat their users as idiots is at the root of this problem. However, if you stop to think about it, humans have managed pretty well over the years dealing with the complexity of self-service machines: vending machines, gas-pumps, ATMs, blood-pressure testing machines, ticketing machines and now grocery checkout machines and even immigration counters. Humans can be trained to deal with complexity if we choose to address it as an industry. IMO, the PKI industry did not solve the account recovery problem (cost-effectively), and it is unlikely the FIDO industry will do it either. It is far easier to educate users to register two separate Authenticators to their account and lock one up for safekeeping, to be used to recover their accounts. This is also an opportunity for Authenticator manufacturers to partner with smartphone/tablet/laptop manufacturers and bundle a USB/NFC/BLE Authenticator with each new FIDO-enabled platform device, and for Relying Parties (RPs) to have a registration flow that prompts - and repeatedly encourages/reminds - users to register their backup Authenticator when they register their first key and have not registered a second key. With the inclusion of extensions and the RSA algorithm in FIDO2/WebAuthn, things have gotten muddied enough as it is. Lets not kill this goose with complexity before its starts delivering its golden eggs - you only have to learn the history of consumer-focused PKI to understand why it failed. Arshad Noor StrongKey On 10/28/2018 07:12 AM, Jonathan Underwood via GitHub wrote: >> That seems outside the scope of WebAuthn. > > While I agree that the WebAuthn spec should not require anything in > regards to key loss, I think that a place to discuss implementation > details like this is useful to increasing adoption. > > Nothing prevents me from implementing it. But your assumption tells me > you agree that adding a reset code feature is recommended? I am > impartial to the idea, and am just open to new ideas from other > implementations... maybe someone thought of new implications that > WebAuthn introduces (considering the fact that it is much broader than > the current "norms" of 2FA which is restricted usually to a TOTP based > app on a smartphone in most implementations). > > ie. UX design around auth will now have to account for "this could be > biometrics tied to a device" or "this could be a USB key with NFC on it > so it can be used with multiple devices."... So if you activate > password-less login and disable password login, and the only device > registered is a Yubikey, you can login with any device that accepts > input from a Yubikey, but if it's an iPhone TouchID, then that user can > only login with one device now... unless we add some way to have the > WebAuthn auth from the iPhone allow the user to login on another device > through push notifications and native apps on our backend etc. > > When designing an auth system using WebAuthn... it feels like 99% of > people look at it as a drop in replacement for passwords|TOTP|SMS > whatever it may be... but after talking to our designers and UX guys > after reading into the spec, it's a lot more complicated than that IMO. > > Again, to bring things back in for a moment: Is there a place where > people who are implementing are gathering that I might be able to > lurk/participate in? >
Received on Tuesday, 30 October 2018 08:16:44 UTC