1

The Register has an article on Passkeys, and one of the issues they use to argue that they are unlikely to be widely adopted is:

The process is bootstrapped by getting the user to authenticate using a traditional approach (such as username and password) which remains open to traditional attacks.

if a website adopts passkeys without disallowing subsequent login attempts by password, then the system remains roughly as vulnerable to phishing attacks as it was before.

Practically this seems to be the case, in testing this answer I used github as a test site as it is used in the documentation. I required a password to register, and after providing a passkey I was unable to remove the password option.

There seems no technical reason for this, as both the passkey private key and strong password are stored in the same database, if I lose access to one I lose access to both. From a quick browser of a list of sites that support passkeys this seems common, I have not found one that allows registration with passkey, all I tried require a password to register an account.

Is there a reason that passkey only accounts are not more widely adopted?

1 Answer 1

1

The WebAuthn specification explicitly allows both options: Authentication with WebAuthn credentials alone, and authentication with WebAuthn credentials combined with traditional credentials (like username and password). However, depending on the capabilities on the concrete authenticator (e.g., a USB token), the first option can be both insecure and violate the user's privacy, which is probably the reason why many website still require traditional credentials.

On the one hand, not every authenticator can perform user verification by asking for a PIN or performing biometric checks. Without user verification, the authenticator only represents a single factor (something you have), and anybody who steals it can use all stored credentials. This is obviously a major security concern.

Additionally, not every authenticator supports discoverable credentials (also known as “passkeys”), i.e., it cannot find suitable credentials by itself but needs the Relying Party to explicitly list them. This poses a huge risk of exposing user data..

So website owners face a dilemma: If they want passwordless authentication, they either have to exclude users whose authenticators don't support user verification and discoverable credentials, or they have to accept significant security and privacy risks. Right now, it seems most websites avoid this difficult choice by only allowing WebAuthn credentials in combination with a username and a password. This could change in the future, though. If WebAuthn becomes more widespread, websites might simply expect all users to have sufficiently powerful authenticators, or they could at least enable passwordless authentication for those users who do have such an authenticator.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .