0

I am thinking of allowing users to login using passkeys. As far as I understand it a login flow of a user logging in with passkeys typically works like this:

  • Login screen separates between a screen where the user enters his user-id (often an e-mail address) and a second screen where the user enters his password (when doing a password login)
  • If the user has passkeys enabled, instead of asking for a password on the second screen the users gets asked for his passkey or can click a link to fall back to a different login type (like passwords)

Example Login on Google

If a login is allowed like this, doesn't this allow for user enumeration attacks? After entering the user-id of an existing user with passkeys enabled, I get a different second page compared to using a non-existent user-id. How do I prevent this?

Matthias Wimmer
  • 3,789
  • 2
  • 22
  • 41

2 Answers2

1

There is a conditional mediation feature (auto-fill with passkey) to allow for you to accept passkeys and traditional passwords in one screen. So, you can leverage that feature by returning empty allow credential for the passkey authentication for all users without checking whether the users are protected by passkeys or not.

In this case, the attacker cannot know whether the user accounts are protected by passkeys or not since there is no differences regarding the screen and response from the service. The browsers will handle the user device has passkeys for the site instead of the service (relying party) or ask customers to use another devices (cross device authentication with passkey or secret keys). Or, the browser might auto-fill the users' passwords or users simply put their passwords in the password field if the service allows to do so.

On the other hand, the service might have some magical way of checking user enumeration attacks by checking cookie or any other information so that it might block such attempts from the attackers.

Ki-Eun Shin
  • 36
  • 1
1

Having probably evaluated all possible ways to integrate passkeys into login and registration flows, we tend not to follow the way Google has implemented it. One (important) reason is username enumeration. The other reason is that there is no way to accurately predict whether a passkey is actually present on the user's device, and therefore any automatic passkey trigger after the user is known (and has a passkey) may lead to a bad UX.

  • Conditional UI is a good solution and should be used
  • There's also the option to put a "Sign in with a passkey" button on the login page
  • Any form of "magic" after entering the username should be avoided, especially if there is even the slightest change it may mislead the user
FlxMgdnz
  • 384
  • 2
  • 7
  • 1
    Thank you, this was also very helpful to read. Indeed I think now it's probably not the best way to follow how Google has implemented it. In other aspects I often considered the authentication implemented by Google as a role model, but it might not be the case here. – Matthias Wimmer May 13 '23 at 11:48