WebAuthn – Replace Password or Second Factor?

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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