Bitwarden is creating backup eligible passkeys and backing them up without setting backup eligible flag during registration

[aseigler]

Steps To Reproduce

1. Have two systems with Bitwarden browser extension installed, logged into the same account
2. On one system, register a passkey with a relying party whose policy does not allow backup eligible passkeys
3. Note that the credential was created successfully, and that backup eligible flag was not set in authenticator data
4. From second system, attempt to login to the same relying party

Expected Result

Bitwarden should be setting the backup eligible flag in authenticator data to indicate the credential is eligible for backup, allowing the relying party to determine if backed up credentials are acceptable to the relying party.

Actual Result

Bitwarden is creating backup eligible credentials and backing them up without sending the appropriate flags to the relying party.

Screenshots or Videos

No response

Additional Context

Operating system and browser versions supplied are what I happened to use at the time to test, but I have no reason to believe this would be any different with any other browser or operating system.

The big issue here is about trust, particularly in the enterprise space (where I first noted this issue). A provider (authenticator) that is creating backup eligible credentials and backing up credentials without setting the proper flags is either intentionally or accidentally misleading relying parties, allowing end users to violate company policy, and as such may result in retaliation or discrimination against the provider.

Operating System

Windows

Operating System Version

11

Web Browser

Firefox

Browser Version

122

Build Version

2024.1.1

Issue Tracking Info

• [X] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[Greenderella]

Hi there,

This report has been escalated for further investigation. If you have more information that can help us, please add it below.

Thanks!

[aseigler]

Looks like this is probably getting handled via #7947.

[djsmith85]

@aseigler Indeed, I checked with @coroiu and this is solved by #7947

Closing this now, as the changes will be included in the next clients release.

[aseigler]

Any insight when that clients release might be? I need to send communications out to a bunch of people that I am administratively removing some of their credentials due to this issue.

[coroiu]

Next release is scheduled in 2 weeks!

Also just a quick note: these flags are still part of a Working Draft so you may encounter situations in the future where these flags are not accurately set (from other providers). We do our best to keep up to date with the L3 spec, but in some cases we might only be L2 compliant. That said, feedback like this from the community is very helpful in prioritizing that!

[aseigler]

Great job turning this around in such a short amount of time! I figured as soon as this got in front of the right set of eyes it would be a very simple fix. The problem now is the cleanup, and I can't be the only enterprise customer in this conundrum.

For what it's worth, with a sample size of 10k+ users running all sorts of various password/passkey managers, the only provider we observed employees registering non-device bound passkey credentials from was Bitwarden. I did also note that the Samsung Pass provider looked like it might be doing the same thing, but I haven't been able to verify myself (yet) that those passkeys were not device bound.