Kunzisoft
Asked to select passkey even in passwordless mode
Checks
- [x] I have read the Wiki, searched the open issues, and still think this is a new bug.
Explain the problem clearly and succinctly:
When doing WebAuthn in passwordless mode I am asked to select which passkey to use as if I were in usernameless mode.
Describe what you expected to happen:
KeePassDX would either use the passkey that the service asked for or none at all.
KeePassDX version:
4.2.4
Build:
Libre
Database version:
No response
File provider (content:// URI)
No response
Android version:
No response
Android device:
No response
Additional context:
In WebAuthn passwordless mode the server asks for a specific passkey. There shouldn't be any need to select which passkey to use. KeePassDX will offer me the choice to use any passkey, even ones with names that do not match the request.
Some Passkey Providers like Yubikeys for example will let you store several passkeys with the same name for the same site. Somehow magically passwordless still works whether you have old passkeys (that don't even work anymore) still stored on the Yubikey. Whether this is even possible with phones I don't know because the Passkey Provider isn't in full charge of the authentication ceremony.
In any case in passwordless mode if there is only one passkey with the proper username associated with it for the site in question it should be used outright without asking.
~That's strange, it should work if you have Passkeys settings -> Auto select enabled and if you only have one entry with this relying party in your database.
Because I've tested it several times on my devices and I haven't had any problems. I hope manufacturers don't apply global filters to authentication methods, as this could also affect Autofill and Passkey. What model of phone do you have?
Since this verification is done by the API directly included in the system, you must be right, the AAGUID of KeePassDX is not recognized and it does not accept that the user verification parameter is true.~
I have Auto Select on but I don't have only one passkey saved for the site. I have two: one for my regular user account and one for my admin account. With passwordless login the username that is being requested is passed with the request from the site so the Passkey Provider should know which one to use without me selecting it. Plus if I select the wrong one the site rejects it because it isn't for the user it was requesting.
OK, I just understood what you mean. I don't see why it's a problem to let the user choose the passkey to use. In any case, they can change an entry in their database as they wish, so they can change a relying party or any data in a passkey they own. There is an automatic search that points to the correct relying parties initially, so that should be sufficient. And as I said, if there is only one relying party and the setting is enabled, it connects automatically if the server allows it.
Both the passkeys are valid for the same relying party. There is nothing wrong with the passkeys themselves.
The problem is that when there is only one suitable passkey for the login taking place right now I still have to choose and if I choose the wrong one the site rejects it. Fundamentally KeePassDX always works in usernameless mode even when the site requests passwordless for a specific user.
Usernameless WebAuthn login: The site requests any passkey as long as it is valid for the site and the username is extracted from the passkey.
Passwordless WebAuthn login: The site asks the user for his username fiirst and then asks for a passkey (via WebAuthn) for that specific user. No other passkey is acceptable except one for that specific user.
The difference is where the UI is for the passkey selection: on the website or the Passkey Provider. Now KeePassDX always works in usernameless mode regardless of what the site asked via the WebAuthn ceremony.
Indeed, the username is not specifically requested, only the relying party (It takes a long time to explain the Passwordless context to me :D).
In this case, we need to improve the search system to point only to an entry whose relying party and username match.
However, if several entries have the same combination (relying party/username), it will not be easy to prevent the user from navigating and selecting another entry arbitrarily, as they will be in selection mode in the KeePassDX interface. Another KeePassDX mode will need to be created specifically for this purpose.
In my opinion it is enough that the selection is done automatically when there is only one passkey that matches the request: correct relying party and the correct username (if applicable).
It is good practice anyway to only keep those passkeys saved on your device that actually have a matching counterparty on the RP side. With yubikeys and such that allow you to save many passkeys with the same username for the same RP you can kinda get lazy with this because the login process always just works the same anyway. In my mind it is actually a positive if KeePassDX sort of warns you that something weird is going on by presenting a choice dialog when there usually isn't any. You'd know to delete any old/stale passkeys with the same username for the same RP.
You're right, the dialog box is a good idea; it would allow us to notify the user properly. Let's go with that.
I would be fine without any specific dialog for that. I was merely referring to the dialog that would require you to select the passkey to use for logging in when normally auto selection would select for you. Then you'd see two passkeys with the same username for the same RP and you'd know that you probably need to delete the old/stale one.
Refusing to save a passkey at registration time because it is a duplicate could cause other problems. When someone tries to do that there is probably a need for the new passkey but they just didn't remember to delete the old one. Allowing the registration ceremony to play its course makes sense. After saving the new passkey I suppose you could tell the user that a similar one already exists.
I see. Well, as a first step, I'll make the change to only offer entries that match in Passwordless mode by also searching for the username. An error toast will be displayed if there are no entries in this mode. For a warning dialog box that does not prevent saving, we will see in another issue; it will not be implemented right away anyway.
Technical note : It is necessary to add the allowCredentials parameter to enable retrieval of the PublicKeyCredentialDescriptor.
https://www.w3.org/TR/webauthn-3/#dictdef-publickeycredentialrequestoptions
Linked to https://github.com/Kunzisoft/KeePassDX/issues/2141
Commit Toast error : https://github.com/Kunzisoft/KeePassDX/commit/b64094ed20eca3f582119d3541683a76ca12e787
We'll need to run a few tests because, for some reason, the error toast sometimes appears on WebAuthn.io when it shouldn't, but I don't know where it's coming from because it works fine when I try to debug it afterwards. In any case, the username search works fine (technically done on the credentialId).
I see why. I was just taking the first element. You have to be able to manage a list. I'll modify the code accordingly.
Fixed in https://github.com/Kunzisoft/KeePassDX/commit/ed095ad0a752f3508a12aea71784e090a0b1fd9a