Ask HN: WebAuthn – Replace Password or Second Factor?
I'm wondering should we be thinking about WebAuthn as a method to replace passwords or should we be thinking of WebAuthn as a easier second factor in the authentication flow?
There have been two main problems with WebAuthn as a primary factor. The first is that the UX experience of WebAuthn as a primary factor - either for "passwordless" or "usernameless" scenarios - has been pretty rough. The WebAuthn W3C group has put together a document that goes into far more detail [1]. One of the items out of that discussion was a standards change [2] that was merged in a few months ago. Now it's up to browser vendors to implement that change over the coming months and years.
The second problem with WebAuthn is that device based authentication has been historically risky for consumer users long-term. It's unreasonable to expect an individual to have access to their phone, yubikey, or laptop over a period of years. In the B2B space, this isn't as big of a deal. Getting an IT admin that works for your company to reset your access and issue a new credential is not a complex problem. Not so in the B2C space. Devices get lost or stolen, and then the service operator needs to build out an alternative recovery method that needs to be as secure as WebAuthn (ideally, without infringing on the user's privacy via KYC methods). New developments like Apple's PassKeys are super interesting and have the potential to really be a game changer for B2C WebAuthn adoption.
In summary, WebAuthn probably can't replace the password for your application today, unless your users are tech savvy and OK with the lock-out risk. However, the space going through some exciting changes and it may be much more feasible in a few years!
[1] https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Con... [2] https://github.com/w3c/webauthn/pull/1576
Note that passkeys come out of the collaboration of many industry partners within FIDO and WebAuthn. I.e. it's not "Apple PassKeys" -- just "passkeys".
See for example https://fidoalliance.org/passkeys/
(disclaimer/context: I work on passkeys at Google)
I like this explanation in Ruby [1] [2] of all the process between the server and the browser. It also has an example you can try on your browser to see if your devices/OS are supported. Look at the bottom the distinction between Passwordless and 2FA.
I'm making a proof of concept of WebAuthn the only login option, for a toy project in PHP [0] with this library [1] It has been an interesting exercise to understand the tricky parts of it.
[0] https://webauthn.lubu.ch/_test/client.html
[1] https://betterprogramming.pub/implement-a-passwordless-authe... [2] https://archive.ph/SyaEW
[2] https://eapl.mx/twtxt/ [3] https://github.com/lbuchs/WebAuthn
1. WebAuthn as second factor
2. Passwordless login using WebAuthn as first factor
3. Usernameless login using WebAuthn residential keys. AFAIK this is what the new "passkeys" thing is also doing.
Think of it like logging in using a SSH-key.
However, one could potentially allow users to add 1-N credentials.
For example, a PassKey (WebAuthn) synced across devices, and then a WebAuthn credential stored on a Yubikey.
That way, you'd still need two factors, and hacking the computer alone isn't enough. But there is no "traditional" password involved.
That said, the key thing to consider here is security vs ease of use. The more you opt for ease of use (like writing down your password or saving your password in your browser or WebAuthn passkey or using a password manager), the more you sacrifice security with varying degree (as the risk of password leaking increases). I'd say the proposed passkeys is definitely one of the worse option here (akin to saving your password in your browser) as anyone with access to your device will be able to access all your accounts without even needing to know your credentials.
It would also be nice to have a way to quickly de-register a lost key. Having a back-up is great, but it's still a pain to go de-register the thing on each individual provider's platform. And if I miss one provider it could easily be game over. I'm not a huge fan of centralization but a single registry for dead keys would make a lot of sense for the different providers to cooperate on.
Most of the places where I've been able to use my Yubikeys (FIDO2) also offer a very clear list of enrolled/registered keys, along with either a hash or serial number of the key. It makes revoking a key pretty easy in my experience.
I'm less keen on the idea of centralized repo for dead keys - each key is unique to the site in question, so there will be no need to share the existence of that revoked key's identifer with other providers - the data is meaningless to anyone else.
I opted not to use WAN for now because it feels like a lot of hassle to setup and most users aren’t going to bother enrolling. Who here loves getting non-technical users setup with SSH keys? I don’t.
When people are more used to WAN it’s going to be great. Is anyone using it today? I’ve never seen it used in production.
MS AzureAD / Office 365 supports it.
You don't want to; add more layers to a work flow, or implement a system where the user can lock themselves out of their account trying to set up a new authentication process.
The people that want to explain why the above is bad security are not representative of the average computer user.
Either someone successfully passes an authentication challenge, and you trust them, or they don't pass the challenge, and you don't trust them. And when you don't trust someone who claims to have legitimate access, you must find an alternative way to verify their identity outside of your normal authentication flow.
I don't think this is a workaround as much as it will be the default use case. Password managers are in a perfect position to keep custody of your private keys across devices, which provides acceptable security for the average person.
Even the password-less-ness of it is not actually entirely free from passwords. Both your iPhone cold booting and your password manager will require a master passphrase/password/pin to unlock your vault (and then use pin/face id for subsequent auth). The difference against a regular pw is that an attacker can replay an intercepted password for session renewal but a public key challenge cannot be replayed. It also means that you need a pw manager integrated all the way into the app/browser, and can't copy paste passwords. This is probably the biggest challenge.
There's a very simple answer to that: "Just say no!". I've told multiple employers over the years I will not put anything remotely close to spyware on my personal phone. If they provide a phone & plan, that's acceptable.
If you're too timid to tell people no, just lie and say you only have a dumb phone or no phone.
Just a quick tap.
All of the flavors of "type in this code from your app or that we texted you" are a huge pain by comparison.