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?
38 comments
As usual - it depends.
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
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
> New developments like Apple's PassKeys
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)
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)
Ah yes, good call out! Didn't mean to exclude Google's contributions to this step forward in auth. I was super excited to read those additional details in Google announcement earlier this week. For those that haven't seen it: https://android-developers.googleblog.com/2022/10/bringing-p...
Something overwhelming of WebAuthn/U2F/FIDO2/Passkeys is that it has many different modes and settings [0]
So, my understanding is that you need to find the settings to 'upgrade' the modes from 2FA to a Passwordless alternative. Not all devices are supported.
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
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
There are 3 modes:
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.
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.
In my opinion you should think of WebAuthn as the first factor. If you want additional second factors (of whatever nature they may be) you can still add these of course.
Think of it like logging in using a SSH-key.
Think of it like logging in using a SSH-key.
Thanks, I was thinking of it this way as well... for SSH keys I us a second factor as a hardware device but I can also use a hardware key for WebAuthn so that is where i was thinking maybe it's a 2nd factor... but for the web, I think it makes sense as a alternative to the password.
You set a pin/password to unlock the webauth storage. That's the first "first password". For example if you use ios it kay require your phone faceID or pin to "login" into services just like they do on appstore installs
I think eventually, a lot of auth on the web will move to WebAuthn (when SSO isn't used).
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.
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.
Apple's method of 2FA, where they display the code on one of your Apple devices for secondary confirmation, would be somewhat akin to the scenario of how WebAuthn could work as 2FA by asking for confirmation on supported devices. I find this quite annoying as I don't use an iPhone (a mobile phone is one of the few devices that you always keep with you).
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.
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.
WebAuthn is not at all like saving your password in your browser. Passkeys (i.e.private keys) are stored in a virtually impregnable Trusted Platform Module and not available. Even if someone steals your device, they cannot access your passkeys.
WebAuthn should negate the need for a 2nd factor in the traditional sense (you can't steal/extract the WebAuthn private-key). I suppose you could bolt on some kind of WebAuthn after a user/pass login, but I don't see why you wouldn't want it as the first-class citizen replacing the password entirely.
Overall I agree with this, but I think there's a genuine need for a general self-destruct mechanism. Having a key confiscated or taken by force should be preventable in some way, and even if I have a backup key, there needs to be a low-friction way to make a key unusable and unrecoverable.
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.
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.
Agree completely with your concerns with regards to lost/stolen keys.
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.
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 agree that revocation is important, but it's a little tricky. Make it too easy, and the attacker can steal a key and then immediately use it revoke your other keys, locking you out permanently.
Passkeys cannot be taken or stolen by force.
You can Set a PIN for the Token.
WAN will usually require a password and second factor to get to the point where you can enroll your device. For example, if you lose your WAN device or need to login a second one, you’ll need credentials (username/password+second factor) to prove who you are to enroll new devices.
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.
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.
Using an acronym no-one else in the thread is using, is not in common usage (this comment is 5:th for a google search for "WAN WebAuthN" and the other results do not use the acronym) and without defining it at the first usage is a bit confusing.
> Is anyone using it today? I’ve never seen it used in production
MS AzureAD / Office 365 supports it.
MS AzureAD / Office 365 supports it.
Neither. If you want adoption then it needs to be; a parallel option to a password, and more convenient than a password.
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.
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.
WebAuthn is two-factor. In order to login, you have to provide 'something you have' (your device) and 'something you are' (your face, fingerprint, etc.)
It's fine for services that use the web. But please don't try forcing it into non-web protocols like the megacorps are doing with their unique OAuth2 implementations and imap.
Passwords were a bad idea to begin with, they were just the least-bad option at the time. WebAuthn should be the first factor.
What is the recovery story with these 2fa, because it seems to be either but a second that you now also have to secure, or tough luck, have fun with 20+ support teams retaining access if you lose it and it's the first factor for login.
Recovery processes aren’t really affected by what you choose as an authentication factor.
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.
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, personally, will not be using WebAuthn by choice. I have a password manager that provides similar benefits, with universal compatibility. If forced, I will find a password manager that provides a simulated WebAuthn device.
> If forced, I will find a password manager that provides a simulated WebAuthn device.
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.
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.
2FA is so overused and makes just all workflows taking longer teams/outlook/jira takes 5 minutes to log on and finally starting work. Meanwhile everyone is on slack with no 2FA and on their servers which can/has been breached.
Would also be great to not use my private phone for this. Companies already all push their 50 required apps on your private phone...
> Companies already all push their 50 required apps on your private phone...
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.
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.
Next employer I will just tell them I only own a nokia 6810 or something haha
Yubikeys are so much faster than other 2FA options.
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.
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.
True, the typing of codes in small timespan is pretty anoying