This should be tagged as a security issue as well.

I'm confused why an unlocked database and the user confirm a prompt does not constitute verification. If the user's database is unlocked, showing a prompt to "further unlock/prove access" is rather irrelevant.

Users that desire more security in this aspect can either manually lock their database or set a short timeout for locking. That would require them to use quickunlock (pin/bio) or their full credentials prior to using passkeys.

Confirming a prompt would be User Presence, which is always required. For both UP and UV, WebAuthn requires that the gesture occur during the ceremony itself. A vault could have been unlocked 8 hours ago and the user stepped away after 1 hour.

If the user's database is unlocked, showing a prompt to "further unlock/prove access" is rather irrelevant.

Users are quite used to using their biometric or PIN to authorize a sign in or transaction. This is a standard pattern across the ecosystem.

A vault could have been unlocked 8 hours ago and the user stepped away after 1 hour.

Yet their database is still unlocked. Which means (since you are assuming an attacker scenario here) I can simply copy your passkey data (and everything else) from your database and do an auth on my own terms. After all, this is entirely client side reported compliance, and the RP has absolutely no way to verify/validate this ever happened.

What I am saying is we have a mechanism to do user verification that actually matters, and that involves locking your database when you aren't using it.

This implementation is not spec compliant and has the potential to be blocked by relying parties.

How can relying parties even know? It's just a self reported boolean value.

What I am saying is we have a mechanism to do user verification that actually matters, and that involves locking your database when you aren't using it.

Then you should require its use when passkeys are enabled

How can relying parties even know? It's just a self reported boolean value.

You are identifying yourself to relying parties, and you have a passkey provider that is known to not be spec compliant.

Users are quite used to using their biometric or PIN to authorize a sign in or transaction. This is a standard pattern across the ecosystem.

Do other desktop password managers do this? As far as I know, they are also just confirming these actions with a simple popup.

Do other desktop password managers do this? As far as I know, they are also just confirming these actions with a simple popup.

All native passkey providers behave as defined in the specification w.r.t. to UP and UV, and a majority of third party providers are responding truthfully about UV.

Do other desktop password managers do this? As far as I know, they are also just confirming these actions with a simple popup.

All native passkey providers behave as defined in the specification w.r.t. to UP and UV, and a majority of third party providers are responding truthfully about UV.

This includes all password managers that are using passkeys via their own browser extension, including Dashlane, Bitwarden etc.?

You are identifying yourself to relying parties, and you have a passkey provider that is known to not be spec compliant.

What stops us, or anyone else, from simply changing the self reported, self generated AAGUID? There is no passkey certification process, no signed stamp of approval from on high. RP's blocking arbitrary AAGUIDs doesn't seem like a thing that's going to happen or that can even make a difference. Get blocked change the GUID. Maybe even present a random one every time.

At the end of the day, this is all client side reported information with absolutely zero validation capability by the RP. So, to me, this is a user choice. Do I use keepassxc and accept their security model (lock your database dangit) or use another authenticator.

What stops us, or anyone else, from simply changing the self reported, self generated AAGUID?

AAGUIDs for synced passkey providers are currently only designed to be used for UX in RP account management screens, but nothing is stopping an RP from using it for other restrictions.

There is no passkey certification process

This is currently being defined and is almost complete.

no signed stamp of approval from on high

see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.

RP's blocking arbitrary AAGUIDs doesn't seem like a thing that's going to happen or that can even make a difference

It does happen and will continue to happen because of non-spec compliant implementations and authenticators with poor security posture.

So, to me, this is a user choice.

Sure, I guess it is always a user choice. But as technologists, its important to build products that help users be secure by default and which play nicely in a standards-based ecosystem.

At the end of the day, it is your product. You do you. I've taken a lot of my personal time to point out some things that should be addressed, things that are huge sticking points for the ecosystem over this 3+ year journey.

I want to clarify myself, I am definitely not saying user verification isn't important nor do we not want to support it. We technically do support it with a locked database. I am playing devil's advocate on how the spec is requiring things to happen and there can technically be no way to know that besides this conversation or a very curious user who knows the spec.

I am for an option (perhaps enabled by default) that requires entering the database credentials again, even if the database is unlocked.

Good to hear there will be a cert process, I hope it is not too expensive 😄 I already pay $350 a year for the pleasure of signing my windows builds.

Physical or remote access to an unlocked computer and database, which the scenario presented assumes.

You can read a comprehensive dialog about requiring credentials prior to export or other similar action and why that is total security theatre: #9339

A vault could have been unlocked 8 hours ago and the user stepped away after 1 hour.

Yet their database is still unlocked. Which means (since you are assuming an attacker scenario here) I can simply copy your passkey data (and everything else) from your database and do an auth on my own terms. After all, this is entirely client side reported compliance, and the RP has absolutely no way to verify/validate this ever happened.

What I am saying is we have a mechanism to do user verification that actually matters, and that involves locking your database when you aren't using it.

As a normal user... about unlocked database in KeePassXC... I think you are aware of it, but maybe it is a bit risky, that the user is able to see the passkey data. I also use Bitwarden and I only see "a passkey is there" - and not the data behind it (let alone being able to manipulate the passkey-data itself). But in KeePassXC you could delete part of the passkey, edit parts of the passkey, copy the values... and when my database is unlocked, everyone else could do the same (of course, unlocked databases in and of itself are an error when leaving the computer - and this was and still is the same for every password in the database, so not a new "problem")... But still, I wonder whether this is as secure as it should be. 🤔

We are not in the business of obfuscating or hiding data from the end user. Our users are generally sophisticated and aware of security practices. If they are not, then they won't likely be looking in the advanced tab anyway.

We are not in the business of obfuscating or hiding data from the end user.

@droidmonkey Thanks for your reply! And understandable, too. - But how about some "middleground" in the long run? Not "obfuscating and hiding", but maybe at least require to re-enter your master password to be able to watch/edit/etc. passkey-data? So that there is one more security measure to/before "full passkey-access".

Our users are generally sophisticated and aware of security practices. If they are not, then they won't likely be looking in the advanced tab anyway.

You have not met my father. When something doesn't work, he would open every tab and try a click here and there... ;-)

PS: Ah, and possible re-entering of the master password, not only as a security measure against a "possible stranger", but also for the user itself, so that mistakenly manipulating with the data of a passkey (and rendering it useless thereby "by accident") is less likely... and BTW, I think you can't only think of the experts, only doing what is right at every turn, but also the beginner level user, who can damage a lot by trying silly things and maybe recognizing it four months later, when "something suddenly doesn't work"...

According to this source, at the moment no passkey providers with a browser extension are performing UV in a spec-compliant manner.

According to this source, at the moment no passkey providers with a browser extension are performing UV in a spec-compliant manner.

According to the issue text "This implementation is not spec compliant and has the potential to be blocked by relying parties." maybe all browser extensions providing passkeys will be blocked eventually? ;)

According to this source, at the moment no passkey providers with a browser extension are performing UV in a spec-compliant manner.

According to the issue text "This implementation is not spec compliant and has the potential to be blocked by relying parties." maybe all browser extensions providing passkeys will be blocked eventually? ;)

It may be possible if they do not implement UV despite sending the flag to true. Apart from this, if a platform requires UV it may be great that the password manager does some sort of verification (even a PIN configured in the Extension) may be great.

Personally, I'd rather switch back to username, password, and 2FA token over passkeys if companies start enforcing this. And any sites that don't allow that, I can live without.