Passkeys - can you turn off the master password verification for sites?

Ask the Community Password Manager
,
41

It’s one thing to not implement user verification; that’s a totally valid position to take if Bitwarden wants to do that. But if you do so, YOU MUST return uv=false in the attestation.

Lying about doing user verification (by always returning true in the attestation) will just lead to Bitwarden’s AAGUID being banned on all major services and enterprise systems. Seeing Bitwarden take a cavalier approach to security to reduce user friction is disappointing.

Ideally, passkeys that require UV should be stored encrypted with an intermediary key that is derived from a UV PIN (set separately than the vault master password or unlock PIN).

Yes, it increases user friction. However, if a service requires user verification, then INFORM THE USER why they are asked to provide a PIN, and do UV according to the spec (with the maximum 30 second timeout imposed by CTAP 2.1).

2 Likes
42

Interesting idea, but there are a few complications:

First, requireUserVerification is an authentication-time parameter, so a site could sometimes require it and sometimes not (e.g. discouraged for login, but required to access account settings).

Second, the spec does not mandate a particular UV method. It is perfectly legal to use something like biometrics that does not provide “secret material” to use in said encryption.

43

As I said, it would be ideal. The scenario you would want to avoid is allowing the user to reset their UV PIN if forgotten while retaining access to all passkeys. That would defeat the purpose of a UV PIN and user verification in general.

And to correct my initial statement about an intermediary key. Passkeys ideally should be encrypted with an intermediary key, and that key be secured by a derived key, derived from the UV PIN.

44

I don’t understand what your problem is? I am a verified user, because I just logged in to my own account - I HAVE BEEN VERIFIED doing it. If I lost control of my vault, I am exposed, additional verification, pins and other methods will not change anything. The password manager is intended to improve security while allowing for a minimum of convenience. Your “user friction” is a very important factor here, not something taken into consideration or not. I will give up using a modern and more secure login method if it forces me to UV every time I use it. This contradicts the whole idea of ​​this solution. It’s like every other password in my vault but without letters, numers and other signs.

This is the opinion of the user for whom these solutions are created, not of the engineer who believes that the user should behave differently.

1 Like
45

The FIDO2 specification specifies that user verification must be done if it hasn’t been done in the last 30 seconds.

This is to prevent attacks where the user leaves his computer unattended, or his computer is compromised with a remote access tool (RAT) while his software passkey is unlocked.

App/website administrators, when requesting UV, expect authenticators to respect that part of the spec to mitigate those attacks. If they don’t, well, their AAGUID will be blacklisted since they don’t respect the spec, and by doing so they put at risk the security of their service.

Passkeys do not exist for your convenience. They exist to remove any human manipulation errors or hubris/bad security hygiene that cause credentials to be stolen/phished.

2 Likes
46

While this makes sense for hardware keys (because a RAT can’t physically push the button on them), if you have a RAT/keylogger with a soft authenticator, it’s probably game over. They either already have your passphrase, and can steal the passkeys with that, or they’ll have it when you type it in because UV forces you to.

47

I understand that FIDO2 has set certain rules that need to be followed, but you also need to understand that PassKey should be a cure for coming up with difficult passwords and subsequent ideas for MFA, which by design had much lighter UV requirements (90 days, etc.), after proper verification. I understand that times are tough and the attack vector is getting wider, but unfortunately we live in times when the vast majority of people have one password for at least a few services, and we as a group are trying to make them aware of the dangers associated with it. I am for increasing awareness and at the same time security, but the stage we are currently at does not allow us to overcomplicate these solutions because we will not reach a wider audience. People who are aware of the threats will cope anyway, and the rest we have to slowly and gently teach security. FIDO2 rules are for engineers and geeks, not people who should have BitWarden as soon as possible.

1 Like
48

@FineWolf & @vitec Welcome to the forum!

@vitec I don’t think that @FineWolf is a member of the FIDO Alliance, nor a Bitwarden representative (please correct me if I’m wrong), so it is probably not fair to direct your ire at them.

Regardless, the points brought up by @FineWolf in this thread are so far are largely correct.

For Bitwarden users, passwordless login with passkeys that do not implement User Verification is less secure than conventional login using username/password/2FA. Thus, if you additionally feel that Bitwarden passkeys are inconvenient, then there is no rational reason to switch from conventional login credentials to passkeys. Simply go to Settings > Notifications and disable the option “Ask to save and use passkeys”, and you will have nothing to worry about.

1 Like
49

So I implement a PIN of 1111 because this whole process annoys me? Does that make me more secure? So why am I using passkeys if they are so annoying to use? Does the user get a say in how they secure their information? After all are we not responsible for the security of our information?

2 Likes
50

@grb if someone wants to argue for the implemention of passkeys, am I not entitled to also argue for a position? Where does “ire” come from? Is this something you’re projecting?

1 Like
51

FineWolf openly criticizes the rollback of changes supposedly under pressure from people, so I have the right to disagree with him. His approach clearly suggests that he could be one of those people who comes up with this nonsense on Fido’s side, and whether he is someone from Fido or not is of no importance to me. It will not change my opinion that such a zealous approach to PassKey will not work with us… ordinary users.

I am not here to argue who is right, because there will be no such solution here. I appeared here because I was concerned about the change in the behavior of my safe and I want to try to do something about it. If I can’t achieve anything, I will simply give up this login method, but not because someone (@grb) tells me that if I don’t like it, I don’t have to use it. I still consider this method superior to passwords, but not if it is to irritate.

I understand that what I am pasting below may be some kind of banality, but maybe it is some kind of UV method? I don’t want to enter any simple addiction PIN or even more so the master password. In any case, I have to click the login confirmation with PassKey, so maybe in this step it will be possible to implement it?

UVpicture
UVpicture364×562 15.4 KB

Of course it can be many times more complicated. For each button there can be two or even three figures randomly combined before the window is displayed. Only one of them will match, but maybe by increasing the number of possibilities you can increase the number of bad choices before the vault is blocked.

Is this complete stupidity?

52

UVpicture2
UVpicture2364×562 16.3 KB

Every time icons set are scrambled so guesing with is correct (ofc you choose before) is waaaay harder.

53

@vitec @waylandgracelyn @Stavros Do you store your TOTP codes/seeds in Bitwarden and use them for login?

54

@vitec Something like the method you are proposing would probably classify as a User Verification method that is compliant with WebAuthn specifications; however, I believe it would not be able to meet requirements of the CTAP2 standard unless the entropy of the method is increased. To my understanding, Bitwarden is currently only working towards making its passkey implementation WebAuthn-compliant, although CTAP2 compliance is on the roadmap for future improvements.

55

All (especially new forum members):
Please take a few minutes to review the Community Guidelines before posting in the forum.

56

Challenge the idea, not the person. This is what I believe @grb meant when he said “probably not fair to direct your ire at them”. Challenging the idea could have been achieved by omitting the struck-through portions of the above quotes .

The complication with “I HAVE BEEN VERIFIED” is the timing. The spec says the use must “occur within the logical security boundary”. The conservative reading is that it begins when clicking “login with passkey” on the website. If we could show that the spec allows the security boundary to begin earlier (e.g. “30 seconds” , or “at vault login”), Bitwarden would have the freedom to “fix” this on their own. Otherwise this attempt to improve usability/acceptance likely requires an update to the spec by the Alliance.

The one thing I completely agree with @FineWolf and @grb on is that Bitwarden must comply the written spec. Doing otherwise would harm interoperability.

3 Likes
57

The spec allows websites/apps to require user verification. Those user verification guidelines in the spec exist for a reason: to protect accounts against a series of all too real threats, regardless of the security hygiene of the user.

My issue is not with Bitwarden choosing not to do user verification. My issue is with Bitwarden attesting that they did user verification by setting the UV flag to true when they did not (according to the spec), and lying to websites/apps that REQUIRE user verification.

This will only lead to Bitwarden’s AAGUID being banned from major services and entreprise networks for not being compliant.

Regardless of your feelings as a user, the specs do exist for a reason, and the threats they mean to protect against are real. Bitwarden doesn’t have to support user verification to support Passkeys. Bitwarden could choose to not support user verification, not set the UV flag in the attestation, and be standard compliant. That would mean that you wouldn’t be able to use Bitwarden for websites/apps that require UV, but UV preferred or discouraged websites/apps would be no issue. That would be 100% fine.

Allowing users to bypass a UV required policy however because “they don’t like it” or don’t feel it applies to them would make UV policies completely useless. My issue is only with Bitwarden lying about the UV flag.

By not being standards compliant right now, they risk being banned from major SSO/CIAM services (Microsoft Entra ID [Bitwarden’s AAGUID is already banned there], AWS Cognito, Okta, Auth0, etc.) which will dramatically reduce the amount of places you can use Bitwarden’s passkey support (as most websites/services use the same handful of IAM providers). And, as a Bitwarden user, that would suck. But I also understand, as someone who is in charge of defining security policies for SaaS software and corporate networks, that by not following the specification, this is ultimately what’s going to happen, because allowing users (which may have privileged access) to enroll a passkey from an authenticator that allows them to bypass user verification is a huge risk.

2 Likes
58

Unrelatedly, what attacks is the UV flag supposed to mitigate in a software authenticator?

59

Now quoting myself :crazy_face: , because after @grb 's post, I wanted to explain what I was aiming at here.

Apart from the question “UV or not UV in Bitwarden” (of course it’s more complex than that, as e.g. @FineWolf expressed recently, but that’s the offending object) or “which future form of UV may be more user-friendly”, I would suggest, maybe viewing UV from a different point of view (though I can understand everyone’s frustration with the current/former implementation in Bitwarden):

First case: you don’t store your TOTP seeds in Bitwarden because of security reasons.

In this case, you (theoretically) wouldn’t want to store any passkeys in Bitwarden without user verification, as it would be the same as having stored your passwords + TOTP seeds in Bitwarden. Because any passkey in Bitwarden would make it possible to login to a service without additional 2FA/MFA.

In this case - at least I understand it like this - only having UV (but implemented in a user-friendly manner!) would allow such a security-cautious person to store and use passkeys in Bitwarden at all.

Second case: you do store your TOTP seeds in Bitwarden because it is more convenient.

In this case, you at least don’t see a problem in storing your passkeys in Bitwarden (as it equals storing your passwords and TOTP seeds alongside in Bitwarden). And using a passkey replaces using (additional to the passwords) TOTP codes or other forms of 2FA/MFA. Therefore, with passkey-UV, you get a new form of user-friction - okay, point taken. But at the same time you (possibly / for most services - there are always exceptions) get rid of the old inconvenience of using TOTP codes or other forms of 2FA/MFA, because it is now “contained” in the passkey and it’s UV.

In a way, you would be replacing your TOTP codes / other forms of 2FA/MFA with the UV of the passkey. (and have the additional advantage of having a phishing-resistant login method)

(Maybe unfair :sweat_smile: but of course - this advantage of getting rid of other 2FA-/MFA-inconveniences would be true also for those, who don’t store their TOTP codes/seeds in Bitwarden (or use other forms of 2FA/MFA) by using passkey + UV with Bitwarden…))

So regardless of how you have done it before (stored TOTP codes or didn’t store TOTP codes in Bitwarden) - it’s maybe not that bad of a change, having user-friendly UV with Bitwarden’s passkeys.

Maybe not the “solution” you are looking for… But maybe at least consider, if a more user-friendly UV than we experienced this last month with Bitwarden is not that bad in the long run - and helps get rid of other inconveniences (having to open your mobile phone, searching for TOTP codes… or other 2FA/MFA).

BTW, in a way - as I understand it - the UV can be seen as the MFA-part of a passkey. So in general, without UV, the passkeys in Bitwarden would lose their 2FA/MFA-quality. So at least, I guess I want to say, don’t see UV only as an inconvenience, as it has it’s general purpose per design…

I’m looking forward to possible answers from others about possible attack vectors. I just want to add my understanding of the UV in general: in the passkey-design, the UV is a very powerful mechanism, as I understand it, as it allows (or disallows) access to the private key to answer the challenge from the relying party. So the UV ultimately protects the private key, so to say. So the UV is not a trivial part of the passkey authentication process, but a part of the security architecture (and as written in the paragraph above, it’s more or less the 2FA/MFA-feature of a passkey, if I understand it correctly).

1 Like
60

It protects against unfettered use of your passkeys by an adversary in case your vault (or any of its caches or backups) are ever compromised — including physical or remote access to a device that has an unlocked vault (or plaintext export), or cracking of encrypted vault data.