Bitwarden Beta does not present Passkey, but Bitwarden Legacy does.

[BJReplay]

Bitwarden Beta

• I'm using the new native Bitwarden Beta app and I'm aware that legacy .NET app bugs should be reported in bitwarden/mobile

Steps To Reproduce

1. Go to Settings
2. Click on Autofill Services
3. Click on Passkey management
4. Choose to Continue to device Settings
5. Ensure that Bitwarden Beta is set to the Preferred service
6. Ensure that Bitwarden Beta is enabled
7. Note that Bitwarden is still enabled, as without it, I am unable to log into my bank due to this issue.

Then open the banking app that will prompt for a Passkey

1. Open the Banking App
2. Expect to see both Bitwarden and Bitwarden Beta presented as Passkey Holding Apps

Expected Result

Bitwarden Beta should be presented as holding the Passkey for the banking app.

Actual Result

Only Bitwarden is displayed as holding the Passkey for the banking app.

Screenshots or Videos

This screen recording shows the About Screen (confirming the latest beta), confirms that Passkey settings are set with Bitwarden Beta set as preferred, and shows the banking app being opened, but only Bitwarden is offering the passkey.

Screen_Recording_20240905_171137_Bitwarden.Beta.1.mp4

The screenshot shows the cipher showing the passkey.

The cipher is the same cipher that is available to both the Bitwarden Beta and Bitwarden apps.

Additional Context

Note that I have already raised an issue under bitwarden/mobile (see bitwarden/mobile#3377) as Bitwarden displays the Username rather than the Display Name - however, when attempting to determine whether that issue now exists under Bitwarden mobile, I encountered this issue instead - Bitwarden Android Native simply doesn't appear.

Build Version

2024.8.1 (19099)

Environment Details

Samsung Galaxy S22 Ultra
S908EXXSAEXGD
A14
1 August 2024 Google Play System Update

Issue Tracking Info

• 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.

[bitwarden-bot]

Thank you for your report! We've added this to our internal board for review.
ID: PM-11671

[daniellbw]

Hi there,

I am unable to reproduce this issue, it has been escalated for further investigation. If you have more information that can help us, please add it below.

Thanks!

[BJReplay]

I am unable to reproduce this issue, it has been escalated for further investigation. If you have more information that can help us, please add it below.

I'm not sure what else I can add that will help.

The same cipher with the same passkey is available in both Bitwarden and Bitwarden beta on the same device.

Both Bitwarden and Bitwarden beta are enabled to respond to passkey requests, and both respond to other applications.

The prior version of Bitwarden beta did respond to this banking app - but I was unable to log in - so I guess this is additional information.

I guess I can extract the passkey from the cipher and redeact some of the information to share it, but I'm not sure that that will help.

[BJReplay]

Hi @daniellbw I can now add more information.

I managed, once to repro the issue with an error message once that I couldn't capture due to screen capture prevention, and haven't been able reproduce, but I have now been able to experiment enough to be confident enough to provide additional information.

In an attempt to repro another issue, I downloaded and ran the beta from the artifacts from https://github.com/bitwarden/android/actions/runs/10965438942.

As noted in bitwarden/mobile#3377 the provider (ubank) is a neobank (digital only) and is rapidly moving towards passkey based authentication.

They (as noted in legacy issue 3377) us both userDisplayName and userName in the fido2Credentials, and this causes issues for Bitwarden (both legacy and native) apps when presenting the credential, as both apps display the userName field, rather than the userDisplayName field.

However, the error message that I saw when selecting the credential was something like "Invalid - Incorrect User Name".

I have just created a new passkey against a new cipher in a different vault, and I think this is why the native client is failing.

Below is a somewhat redacted dump of the cipher. I have redacted the same section of the username of the cipher and the userName of the fido2Credentials - but the unredacted GUIDs are identical.

I believe that the reason that the native Bitwarden isn't presenting the passkey is because the ubank app is requesting them in such a way that it expects (or is seaching for) credentials that match both a cipher and fido2Credentials for the userName. Because they don't match, nothing is presented.

Obviously I have redacted the keyValue, credentialId, and userHandle from the fido2Credentials .

Note that Android legacy presents credentials (presumably based on application matching) and I am able to log in.

Note in particular:

From fido2Credentials: "userName": "c8b2c7d0-redacted-7b90e3c3cb37",
From cipher: "username": "c8b2c7d0-redacted-7b90e3c3cb37",

The redacted portions of the GUID are the same - this is a ubank allocated UserName, and is what is allocated as username when I allow Bitwarden Native to create a passkey against a new cipher running 2024.9.0 (19184).

bw get item dbe23814-002f-476b-b29f-b1f300473469 --pretty
{
  "passwordHistory": null,
  "revisionDate": "2024-09-22T04:19:14.836Z",
  "creationDate": "2024-09-22T04:19:14.836Z",
  "deletedDate": null,
  "object": "item",
  "id": "dbe23814-002f-476b-b29f-b1f300473469",
  "organizationId": null,
  "folderId": null,
  "type": 1,
  "reprompt": 0,
  "name": "www.ubank.com.au",
  "notes": null,
  "favorite": false,
  "login": {
    "fido2Credentials": [
      {
        "credentialId": "f19aed2f-redacted-7c76ab26040a",
        "keyType": "public-key",
        "keyAlgorithm": "ECDSA",
        "keyCurve": "P-256",
        "keyValue": "redacted",
        "rpId": "www.ubank.com.au",
        "userHandle": "redacted",
        "userName": "c8b2c7d0-redacted-7b90e3c3cb37",
        "counter": "0",
        "rpName": "www.ubank.com.au",
        "userDisplayName": "redacted mobile number",
        "discoverable": "true",
        "creationDate": "2024-09-22T04:19:12.170Z"
      }
    ],
    "uris": [
      {
        "match": null,
        "uri": "androidapp://au.com.bank86400"
      }
    ],
    "username": "c8b2c7d0-redacted-7b90e3c3cb37",
    "password": null,
    "totp": null,
    "passwordRevisionDate": null
  },
  "collectionIds": []
}

[BJReplay]

I think the final piece in the puzzle about the passkey not being presented may be the way the app appears - when it fails passkey authentication, and falls back to password, bitwarden native won't match the app - it says it has no matching items for app bank86400. If I search for the cipher manually, and accept the option to auto-fill and save, a new URI is added for https://bank86400. This still doesn't match on subsequent attempts, so multiple new URIs are added, each with https://bank86400 as the match URI.

I'm sure a lot of this is down the to the Ubank (who were once known as 86400) developers reading the URI and thinking "Oh, I can do this, I will do this - I can have different userNames and userDisplayNames so I may as well, and I can have a different android app ID and a different match ID, because that's all in the spec, so let's do it, but this is the first app where your native app is choking, but the legacy app isn't.

[BJReplay]

If you have more information that can help us, please add it below.

@daniellbw I have captured additional screenshots of the sequence that occurs now that I've set the username of my cipher to the GUID that the ubank app is expecting - so it now allows the ubank app to allow Bitwarden Native to present a passkey whereas it previously could not.

This is with app version 2024.9.0 (19187) (beta) downloaded from artifacts from build action https://github.com/bitwarden/android/actions/runs/11001927746

However, it still fails to authenticate - but the error messages are now more useful with these later builds than the official build which was just a failure presented by the Ubank app, rather than error message from the bitwarden app as shown below...

The first error that is displayed (after selecting Bitwarden Native Beta as the passkey source and authenticating with biometrics) is:

The second error, after clicking on OK, is then displayed:

Finally, after clicking on OK, the matching Login is displayed:

[markcs]

Excellent reporting and debugging on this issue.

Waiting patiently for a fix as ubank only allows 4 passkeys and I've been locked out a few times due to this bug.

[BJReplay]

Waiting patiently for a fix as ubank only allows 4 passkeys and I've been locked out a few times due to this bug.

Hopefully they come up with one @markcs as it's gone all quiet here, and they're due to come out of beta on Thursday, and I haven't seen a commit that suggests they've closed it.

[BJReplay]

I have tried to re-test with the v2024.10.2 release by manually installing com.x8bit.bitwarden.beta.apk from the https://github.com/bitwarden/android/releases/tag/v2024.10.2 since the early access from the app store hasn't been updated yet.

However it simply doesn't allow me to set it up as a passkey provider.

I don't know if that is because of the way it was installed (i.e. from a download, rather than from the app store), because I installed the beta apk (because I could not afford to lose access to legacy bitwarden app given that I can't log into my bank using the native bitwarden app betas so far, which would have happened if I used the non-beta apk), but v2024.10.2 simply would not present as a passkey provider.

@daniellbw Will the Bitwarden Beta (Early Access) version in the Google Play Store be updated so that issues such as this can be re-tested on the "release version" through official channels?

[BJReplay]

Hi, I have just confirmed that this is still present in v2024.11.1