Does Bitwarden need to do User Verification anew for each authentication ceremony?

Ask the Community Password Manager
,
1

A side discussion arose in the Feature Request thread “Passkey User Verification Independent of Vault Unlock Method”, about whether it is even necessary for Bitwarden to require a new User Verification (UV) each time that a passkey is used for authenticating to a Relying Party (RP) that has specified that UV is required.

To avoid diluting the actual feature proposal in that Feature Request thread (to make the UV method separate from the vault unlock method, given that Bitwarden is going to require UV when the RP specifies it), I have created this new topic for purposes of discussing the larger issue.

For now, I will leave the off-topic comments in the Feature Request thread instead of moving them into this discussion thread, but I have copied a selection of those comments in a post below, to provide context.

The real question is:

Does the WebAUthn standard actually require authenticators to perform User Verification for each individual authentication ceremony (when the Relying Party has required User Verification)?

  • If the answer is “No”, then it would make sense for Bitwarden not to unnecessarily require User Verification (e.g., requiring the master password to be input each time a passkey is used on a site that mandates UV), instead using the most recent vault unlock event as a type of “user verification” that is valid for all passkey uses that occur while the vault is unlocked.

  • On the other hand, if the answer is “Yes”, then an improved approach to implementing passkey User Verification in Bitwarden will be necessary (as proposed in the Feature Request thread “Passkey User Verification Independent of Vault Unlock Method”).

1 Like
2

 

 

 

1 Like
3

In addition to the above discussion in the Feature Request forum, @bwuser10000 raised the following objections in their recent Ask the Community thread (“Passkeys - can you turn off the master password verification for sites?”):

2 Likes
4

I already want to “throw in” something to if the answer is “No”:

But first, let me say I don’t want to kill the conversation. But as I understand it, if the answer is “No”, then that has major complications, at least for now. Mainly two things could be the result of that:

  1. Bitwarden would remain non-spec compliant with passkeys. I can only again refer to an official site (from W3C and “members of the FIDO alliance”) https://passkeys.dev/docs/reference/known-issues/ where it is called a known issue, that User Verification is not implemented properly (= as it was with Bitwarden until now, UV was already there, but set to always true by Bitwarden with every passkey authentication usage, so to speak…). The question would be, what that means, if Bitwarden wouldn’t implement the specs in a spec-compliant way (for us users, for services that offer/use passkeys, for Bitwarden as a company, for the FIDO alliance, …)

  2. The “insurrection” is that big (“world-wide”), that the passkeys specs eliminate UV or at least change it / it’s requirements / what is seen as right/wrong implemented… - Maybe that changes anyway in the next decades, but the hope for a soon-to-be-there-change would be small, I think.

So, from the thoughts of the possible alternatives if the answer is “No”… I tend to the answer is “Yes” - because I like the alternatives and practical implications of the answer is “No” even less.

PS: Addition to my first point: I have the impression, that all major password managers (at least those, that are associated with the FIDO Alliance) work on implementations of UV (see the “Known Issues” site…) - the interesting thing for us may be now, how other password managers implement UV (in a spec-compliant way).

And all that again makes me think the feature request of a change of the UV makes absolute sense.

5

@Nail1684

Perhaps I didn’t express the question clearly. I think that the discussion that arose in the other threads is precisely about what do the specifications require?

Only if a rigorous reading of the published specifications actually require UV to be done during each authentication ceremony (as opposed to being able to “inherit” some form of UV that was done prior to the passkey authentication ceremony).

So this is exactly what the debate is: what do the standards actually require?

In the other thread, I wrote:

@DenBesten then responded:

[Edited to Add:] …the above exchange is an example of the debate at hand (which I’m hoping can be resolved in this thread).

 

Personally, I’m fairly certain that the WebAuthn standard does require UV to occur contemporaneously, during each individual passkey authentication ceremony — and I believe that you (@Nail1684) are of this opinion as well, based on what you have posted.*

I plan to post some sources for my assertion in this thread, which will either settle the question, or lead to additional discussion…

 

*However, I’m confused about your interpretation of what I had described as “the answer [being] `No’” vs. “Yes” — in the above context, “yes” means that to be compliant with all specifications, Bitwarden must require contemporaneous UV (as they’ve started doing since version 2024.6.0); conversely, “no” means that the new behavior is not required by the specs, and that the old (pre-2024.6.0) behavior was in fact already compliant with the specifications and standards.
6

Here is my best evidence that Bitwarden is in fact bound by published specifications when requiring User Verification to be synchronous with the passkey authentication ceremony (ruling out the possibility of representing to Relying Parties that a prior, asynchronous vault unlock event “counts” as User Verification).

From the publication Web Authentication: An API for accessing Public Key Credentials. Level 2. W3C Recommendation, 8 April 2021, under §4 Terminology:

Authentication Ceremony

The ceremony where a user, and the user’s client (containing at least one authenticator) work in concert to cryptographically prove to a Relying Party that the user controls the credential private key of a previously-registered public key credential (see Registration). Note that this includes a test of user presence or user verification.

[emphasis added to the last sentence]

This makes it clear that User Verification is done during each authentication ceremony. Section §7.2 (Verifying an Authentication Assertion) defines the requirements of the authentication ceremony. There, we find:

In order to perform an authentication ceremony, the Relying Party MUST proceed as follows:
…
17. If user verification is required for this assertion, verify that the User Verified bit of the flags in authData is set.

The UV bit is set by the authenticator (e.g., Bitwarden) during the ceremony.

As an additional data point, it is clear that Bitwarden does consider the new behavior (synchronous UV during each authentication ceremony) to be be required by the specification, as evidenced by a recent Reddit comment by @kspearrin:

They [1Password] ignore the specification’s requirement to prompt for user verification, which we were previously doing as well for the sake of UX.

See also comments by timcapalli in this thread on the KeePassXC GitHub repo, as well as the assessment by passkeys.dev that was previously linked by @Nail1684.

7

TLDR, my position is “Do what the specifications require”, with the real question being “who has the most authoritative specification?”.

My understanding as to the communication is that the RP (“web server”) starts by announcing its user verification (UV) preference as required (please do it), preferred (it if you want to) or discouraged (please don’t ask). After having done its thing, the IdP (“Authenticator/vault”) responds by either setting or clearing a user-verified flag. This flag is merely a true/false attestation based on the IdP’s judgement. From this, I have two take aways.

First, the IdP is free to never perform UV if it wants, but if taking this path, it then needs to return “UV=false” even if the RP said “required”. The RP can then decide how to handle the fact that it did not get what it wanted (with all due respect to Mick), perhaps TOTP or failing the authentication. Remaining truthful in setting the flag is the important bit to me as it plays directly into maintaining corporate reputation. Therefore, I would strongly object to any proposal calling for the IdP to lie.

Second, I have no objections to Bitwarden interpreting the specification loosely – provided they stay in bounds. If the spec says UV MUST be contemporaneous with the passkey exchange then that is what they must do. If the spec uses a vague term (i.e. “security boundary”) without defining it or they use wiggle words like SHOULD, the implementer (Bitwarden) has substantial freedom, such as basing their UV on the fact that the vault is currently unlocked.

Making things more complicated, even the word contemporaneous has a bit of wiggle room. For example, if I authenticated to my vault for the express purpose of participating in the passkey auth ceremony, that auth should “count”, but if I unlocked moments before deciding to use the passkey, it should not. Unfortunately, distinguishing between these scenarios is not automatable.

Please do realize that my comment “cite please” is not intended to be confrontational (as some maliciously use it), but rather it is my attempt to figure out which horse to back. And as always, I remain open to being swayed by a compelling argument.

1 Like
8

@DenBesten apologies for perhaps causing some confusion in my previous comment, which I have now revised to make more clear.
That comment was a response addressed to @Nail1684 , in which I cited your response to me from the other thread as an example of the debate that I am hoping to settle here (instead of cluttering up the feature request thread). But when I wrote “…I believe that you are of this opinion as well…”, I was addressing @Nail1684, not you. It is clear that you are/were not convinced that the standards do require synchronous UV.

Now to the substance of your comment :

I fully agree, and I think that the changed UV behavior since version 2024.6.0 is expressly for the purpose of ending the lies.

In my reading of the specifications, they do say so. The authentication ceremony is the full process of interactions between the user, authenticator, client, and RP which cause the passkey authentication to happen. The official definition of Authentication Ceremony clearly states that the ceremony “includes…user verification”, and a step-by-step specification of what happens during the authentication ceremony explicitly mentions the UV flag that is returned by the authenticator.

Did not take it as such. Have I moved the needle at all for you with the information provided above?

1 Like
9

Thanks for the references.

Here is the path that leads to my being unconvinced.

§6.1 demands truthfulness in setting the UV flag:

The UV flag SHALL be set if and only if the authenticator performed user verification.

§6.2.3 discusses the ceremony itself and uses the verb to “used”, as opposed to the earlier “performed”, raising the possibility of “performed earlier, used now”.

The Relying Party can therefore use the UV flag to verify that additional authentication factors were used in a registration or authentication ceremony.

And then in §4, “User Verification”, the undefined term “logical security boundary” is introduced. If they had instead used “authentication ceremony”, it would be clear that they intended UV to occur during the ceremony.

… user verification and use of credential private keys must all occur within the logical security boundary defining the authenticator.

That said, I do believe the intent is “during the ceremony”, but with ambiguity, comes uncertainty. And with uncertainty, one is unable to declare an implementation compliant or non-compliant.

There is a newer “editor’s draft” of the specification, but as far as I can tell, none of the above references have received an update. Here’s hoping they clarify their intent, perhaps by changing §6.2.3 from “factors were used in” to “UV was performed during”, and hopefully to allow UV immediately prior to the ceremony since it does not work to unlock the vault after the ceremony starts.

Slightly changing topics, I do note the UV definition includes this interesting tidbit, which opens a whole new can of worms:

The same user might not always be the same natural person, however, if multiple natural persons share access to the same authenticator.

1 Like
10

@grb Okay, seems I got something wrong. :sweat_smile: On the technical details I’m out then - so I leave my previous comment as it is. (for whatever purpose)

@DenBesten As I just wrote, the technical side is not my field of expertise… But if you are right with your interpretation, then please explain,

  1. how Bitwarden could change it from spec-compliant (previous implementation - as you see it) to now non-spec-compliant? Then that would not only be an unfortunate change to the authentication-flow, but additionally completely nonsensical, wouldn’t it?

  2. and why the previous implementation of Bitwarden’s UV is assessed (on https://passkeys.dev/docs/reference/known-issues/) as non-compliant? This is as W3C and the FIDO Alliance assess UV, or doesn’t it?

Screenshot from this link:

image
image943×191 13.5 KB

image
image906×221 21.9 KB

image
image935×134 7.95 KB

To me it seems, whether there is room for interpretation or not - there seems to be common ground with W3C and the FIDO Alliance, on how UV-implementation should be interpreted, or isn’t it? (“always replies True” is clearly marked as non-spec-compliant - and “Handles request without UV” seems to mean, that the user is not confronted with UV, that he actually had to “handle” to be spec-compliant → or is there any other way to interpret the info in this chart?)

Or is the whole W3C and FIDO Alliance wrong about their own standards?

(as you wrote before, “not confrontational” - but questions, that arise with your interpretations :wink: as I see it)

1 Like
11

And more layman’s speculation from me - the headline could be:

Doesn’t have the UV also to do with the passkey in Bitwarden being/having MFA (still, or again)?

The whole discussion if I should or should not store TOTP codes in my password manager circles around keeping two factors separate or not. If a passkey in Bitwarden can manage a complete login process to a service, without additional factors, then it would be the same as saving my password and TOTP codes in Bitwarden.

You can do that of course. But many people don’t want it. And without UV it would be the same with a stored passkey (equalling storing a password AND TOTP code along, both in Bitwarden). And I think I can remember, that was a sentiment, that was expressed with the first passkey support of the browser extension - and I too was considering, if I should store passkeys at all in Bitwarden, because there was no master password/PIN/biometrics request (= UV)… and question was more “should I/should we wait until UV is there, so that we then can safely use and store passkeys in Bitwarden?”. Interesting, how this whole argument turned around 180 degress now. :wink:

So, I guess, having UV for every authentication process with a passkey in Bitwarden is not only about whether the user is present or not and if I already unlocked my vault or not, but it is also about making sure, that the stored passkeys remain “with 2FA/MFA”.

This quote is mainly for device-bound passkeys one could think - but isn’t it true for any synced passkey, as I tried to reason above?:

image
image1100×335 15.3 KB

(Source: https://fidoalliance.org/faqs/#PasskeysFAQs)

PS: … but if one wants to prevent “if someone got access to my Bitwarden account, they would have all my passwords AND TOTP” or rather with passkeys then: “… all my passkeys in Bitwarden”, then that would also mean that the 2FA/MFA-component of the stored passkeys (via UV, as I argued), shouldn’t be circumvented with an easy export of the vault. Because then again, an “intruder” could get my passkeys and therefore all factors inherent in my stored passkeys / associated with the stored passkeys. :thinking:

PPS: Sorry @grb, I just wonder, if you consider this post as off-topic - but I think it has to do with the question, whether UV is required with each authentication ceremony - or rather why it also may be required: because of 2FA/MFA-considerations.

12

Maybe :wink: …but it doesn’t matter so much in a thread that is not a feature request. :peace_symbol:

1 Like
13

My interpretation of “logical security boundary” is that it is not a reference to temporal relationships, but rather a definition of the boundaries of the WebAuthn Authenticator — in the case of a hardware key, the authenticator would have physical boundaries, and the requirement that you have quoted says that verification of the user’s PIN (or biometrics) must happen inside the physical key; in contrast, for a software authenticator, there are no physical boundaries, but one can identify “logical” boundaries (perhaps circumscribing the process memory and code).

In my opinion, the fact that the definition of “Authentication Ceremony” specifically says that the ceremony “includes a test of user presence or user verification”, is sufficiently convincing.

I agree, to a certain extent. However, evidently, the FIDO Alliance is planning to introduce a certification mechanism in the near future, and at that point, Relying Parties can reasonably be expected not to accept passkeys from non-certified authenticators. Thus, what really matters is whether the certifying body deems an authenticator to be compliant vs. non-compliant — not whether it is theoretically possible to argue one way or another. I believe that it is this impending certification requirement that is driving the changes in Bitwarden’s implementation of UV.

14

I too suspect the same thing, but without a definition (§4, or “Websters”) we can not move beyond “interpretation” and into certainty.

Without question, that would be a good thing, but at the same time, if the certification authority is forced into subjective decisions, we are in the undesirable position of “legislating from the bench”. It is the legislator’s job to write the rules clearly, with self-consistency and in unambiguous language, such that the certification authority can live solely in the objective world.

The fact that you and I both are hunting down indications of intent in the “definitions” section, which is typically an “informative” section is a good indicator that the “normative” sections are lacking. This is why I am hoping for an update that clarifies.

I do find it interesting that we hold basically the same position, but really are debating if ambiguity should benefit the defense or the prosecution.

2 Likes
15

tl;dr

Some could argue that “user verification” is already satisfied by being logged into the addon,
since at that point anyone could take over any site using usr/pwd listed in BW.

(this would be important to simplify passkey filling)

If in doubt then please add a user option to achieve this.

16

A more accurate TL;DR of this thread would be:

Although some may argue that “User Verification” is already satisfied by unlocking the Bitwarden vault, a careful reading of the published specifications reveal that it is not so simple.

17

I understand your concern about the standard, but from user perspective if vault is unlocked anyone could take full access to every site, bypassing all the requirements FIDO demands, replacing all the passkeys with compromised ones (no point protecting those).

So at very least we could add a new settings “consider unlocked vault as UV” to make user’s life easier.

1 Like
18

I think that is a good argument for protecting every passkey-action (usage, deletion, export, …) with User Verification (or more / or other forms of protection).

I think here you are only considering “the vault” - for the services/accounts, the consideration is also, that (ideally) no one enters their services except the users who should.

As others already tried to explain, this is not a decision by Bitwarden alone. Or it could be - but then this may have consequences / unintended side effects (like Bitwarden’s passkeys wouldn’t be accepted by services, because they require FIDO2 compliance).

1 Like
19

I’m a bit confused about why I need to be FIDO compliant.

I just want the same security as a max complexity password, and a unique username, but without having to generate a password or a username. I see max security without the need to remember a password, as the key value of a passkey.

If I work at an organization the requires double verification of the passkey, sure give me an option to turn that on; but for my everyday life, just let me use a passkey as better password. i.e. one password to rule them all, and only ask me for once until I lock my vault again, or restart my browser/computer/whatever.

20

@marlen Welcome to the forum!

I moved your comment into a more appropriate thread.

The issue is that if Bitwarden provides its more lackadaisical/rebellious users an option to skirt the WebAuthn requirements, then Bitwarden’s passkey authenticator is itself not compliant with the WebAuthn standards (to be compliant, the required/expected behavior has to be enforced every time).

Certification of passkey authenticator platforms will become a reality in the near future, and certification will not be granted if an authenticator platform is non-compliant with the published specifications.

That then opens the door for Relying Parties (the websites that you wish to log in to) to refuse login attempts made using passkeys stored in non-certified passkey authenticator platforms.

Long story short, if Bitwarden were to relax the rules like this, then Bitwarden users would soon find that the passkeys stored in their vaults would no longer work on the vast majority of websites.