As noted by @nothanco, Bitwarden’s URI matching still provides protection against phishing, so the security benefit of Bitwarden-hosted passkeys has always been marginal (at least for users who are unlikely to to fall for social engineering schemes that require disclosure of a password and/or TOTP code through other channels).
Thus, for me, use of Bitwarden-hosted passkeys is primarily about convenience (if I need extra security from a passkey, I use a Yubikey). The convenience of Bitwarden-hosted passkeys is now completely negated when sites require UV. Thus, I will no longer use Bitwarden passkeys for such sites (e.g. GitHub).
I already agreed, that I don’t like the way, UV is implemented at the moment.
And I was a bit hesitant, to answer here again, because the pro’s and con’s of passkeys are not the real issue here, but UV implementation.
But then again, here some comments.
I know of that advantage - and it is valuable! (though, as you alluded to I think, one can circumvent it by manually copying… which is an advantage of the passkey, again, because they can’t be circumvented like that by clever users…)
I find that argument a bit difficult to make, because if you think that through, you could also be saying - as (synced) passkeys always need to have to be stored in a wallet - that to store conventional passwords and 2FA in that wallet would be more or less equal and therefore, nobody needs passkeys. And we can stay with passwords and 2FA.
That reminds me of an observation I had a few feeks ago. I saw some videos from the FIDO alliance (some of the latest videos from about two months ago - https://www.youtube.com/@TheFIDOAlliance) - and of course there may be a bias for passkeys - as it is “selling their product”… but almost everyone there argued, that a passkey, because it is almost not phishable, is always better as something phishable.
And new to me was the thought, that we may have to re-think “2FA/MFA”, because having (I simplify and exagerrate now a bit) more factors is not a goal in itself - the most important thing, and the biggest problem, is phishing or rather avoid phishing.
… But, as I stated above, I don’t know if it makes so much sense now, to not discuss the real topic: UV…
I know what you mean - but why the harsh language? “Completely” is a bit harsh, as it is not that bad for those, who use a (unsecure or secure) PIN or biometrics. From a practical point of view (I know you raised already more important issues surrounding the whole problem) the biggest problem is for those, who use the master password…
I agree, so I’ve split this discussion into a separate thread to avoid diluting the discussion of Bitwarden’s UV implementation in the original feature request thread.
Feel free to return to the previous thread to post just the above comment!
That is what I was implying. For security-conscious users who only use auto-fill, who use strict URI match detection rules, and who know better than to disclose shared secrets via channels other than a legitimate (URI-matched) login form, they can safely stay with username/password credentials.
I already conceded in this comment that users who lock their vaults with biometrics or very weak PINs are the only ones who will not be significantly affected by Bitwarden’s current UV implementation.
[Note: Any follow-up discussion of this last point should probably be made in the original feature request thread instead of in this side discussion thread.]
Depends upon the attack vector. If a homonym web site, then either auto-fill or passkeys form an effective defense. If due to DNS hijacking, auto-fill is ineffective, but passkeys remain so. If due to website compromise, neither is effective.
Bottom line is that risk analysis/acceptance is a cost vs benefit discussion. “Which is better” is only 1/3 the discussion. One also must also consider “how likely” and “at what cost”.
Amen. Most defenses are a means to an end, not a goal unto themself.
I wrote that, because lately I got the impression, that many people feel safer with, e.g., passwords and their TOTP codes both in different places (which is fine in a way)… instead of e.g. “only” a passkey for a given service. - Now I don’t want to repeat myself too much, but here it seems to me that having more factors becomes sometime a goal in itself, and the possibly more secure variant (passkey) is seen as less secure, because “it’s not more factors”. Whereas the FIDO Alliance seems to go more into the direction “more factors is not that important as it was - phishing resistance is more important”.
Great, now it even asks for the master password when I want to use any passkeys, even when I’m logged in. (which is >100chars, and I’m not confortable having it on clipboard more than necessary)
I understand why.
What a useless standard, I’m going back to passwords.
Logged in to where? Regardless, you are not asked for User Verification when using “any passkey” — only when using passkeys on websites that demand User Verification for passkey authentication.
Regardless, Bitwarden will soon be rolling back the master password requirement and work on development of a more user-friendly implementation of User Verification.
Also, the Feature Request thread where you had posted is about the User Presence prompt, not about User Verification, so I have moved these comments to a more relevant thread.
That was introduced with the latest release (2024.6.x) so it seems you just updated… As @grb said, this will be rolled back probably with the next release - but until then: if you would only unlock your vault with a PIN or biometrics, you would get asked that as UV for passkey-usage.
I think we all agree, that the current implementation of UV for passkeys is/was unfortunate - and hope for a better implementation, maybe in a few months.