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

@bitwarden-bot commented on GitHub (Sep 5, 2024):

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

@bitwarden-bot commented on GitHub (Sep 5, 2024): Thank you for your report! We've added this to our internal board for review. ID: PM-11671

GiteaMirror commented

@daniellbw commented on GitHub (Sep 10, 2024):

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!

@daniellbw commented on GitHub (Sep 10, 2024): 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!

GiteaMirror commented

@BJReplay commented on GitHub (Sep 10, 2024):

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 commented on GitHub (Sep 10, 2024): > 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.

GiteaMirror commented

@BJReplay commented on GitHub (Sep 22, 2024):

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 https://github.com/bitwarden/mobile/issues/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 commented on GitHub (Sep 22, 2024): 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 https://github.com/bitwarden/mobile/issues/3377 the provider ([ubank](https://www.ubank.com.au/mobile-banking-app)) 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": [] } ```

GiteaMirror commented

2025-11-26 23:04:07 -06:00

@BJReplay commented on GitHub (Sep 22, 2024):

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 commented on GitHub (Sep 22, 2024): 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.

GiteaMirror commented

@BJReplay commented on GitHub (Sep 24, 2024):

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:

@BJReplay commented on GitHub (Sep 24, 2024): > 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: ![Screenshot_20240924_191341_Bitwarden Beta](https://github.com/user-attachments/assets/22249ca8-faba-4790-924e-01b44be0c69a) The second error, after clicking on OK, is then displayed: ![Screenshot_20240924_191401_Bitwarden Beta](https://github.com/user-attachments/assets/b4d1461a-700d-45d5-948c-0c3488e6fc3f) Finally, after clicking on OK, the matching Login is displayed: ![Screenshot_20240924_191434_Bitwarden Beta](https://github.com/user-attachments/assets/d1a94176-91c3-4469-af17-7582f3f69a27)

GiteaMirror commented

2025-11-26 23:04:07 -06:00

@markcs commented on GitHub (Oct 21, 2024):

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.

@markcs commented on GitHub (Oct 21, 2024): 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.

GiteaMirror commented

2025-11-26 23:04:07 -06:00

@BJReplay commented on GitHub (Oct 21, 2024):

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 commented on GitHub (Oct 21, 2024): > 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.

GiteaMirror commented

@BJReplay commented on GitHub (Nov 5, 2024):

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 commented on GitHub (Nov 5, 2024): 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?

GiteaMirror commented

@BJReplay commented on GitHub (Nov 7, 2024):

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

@BJReplay commented on GitHub (Nov 7, 2024): Hi, I have just confirmed that this is still present in [v2024.11.1](https://github.com/bitwarden/android/releases/tag/v2024.11.1)

GiteaMirror commented

@Molenaar2 commented on GitHub (Nov 10, 2024):

I have the same issue and cannot login to UBank. I created a separate issue, but will close that one and mark it as a duplicate of this one
One additional comment, we have two UBank accounts in the vault (one in private vault and one in organisation) and the old Android app showed a pop-up too select the required passkey to be used for login. However, the pop-up showed the cyphers, not the usernames, making it hard to pick the right account. It would be great if the pop-up would show the usernames.

@Molenaar2 commented on GitHub (Nov 10, 2024): I have the same issue and cannot login to UBank. I created a separate issue, but will close that one and mark it as a duplicate of this one One additional comment, we have two UBank accounts in the vault (one in private vault and one in organisation) and the old Android app showed a pop-up too select the required passkey to be used for login. However, the pop-up showed the cyphers, not the usernames, making it hard to pick the right account. It would be great if the pop-up would show the usernames.

GiteaMirror commented

@Felitendo commented on GitHub (Nov 11, 2024):

I'm also having the same issue

@Felitendo commented on GitHub (Nov 11, 2024): I'm also having the same issue

GiteaMirror commented

@BJReplay commented on GitHub (Dec 22, 2024):

@daniellbw I have reproduced this issue with https://github.com/bitwarden/android/releases/tag/v2024.12.0

The following sequence of images show the sign in process where I have:

Bitwarden Legacy 2024.10.0 (11270)
Bitwarden Native 2024.12.0 (19597)
Keyguard 1.7.1-12356 21 December 2024

All installed and accessing the same vault.

I can log into Ubank successfully using Bitwarden legacy and Keyguard.

Bitwarden native now attempts to log in, but fails.

After selecting Bitwarden Beta, I get a message: "Passkey operation failed because user could not be verified."

After hitting OK, I get a second message: "We were unable to process your request. Please try again or contact us."

A search for those strings uncovers them in the Bitwarden code base (so they're undoubtedly coming from Bitwarden rather than the bank): 6223f362c3/app/src/main/res/values/strings.xml (L938) and 6223f362c3/app/src/main/res/values/strings.xml (L698)

Again:

I can log in successfully using Bitwarden
I can log in successfully using Keyguard

@BJReplay commented on GitHub (Dec 22, 2024): @daniellbw I have reproduced this issue with https://github.com/bitwarden/android/releases/tag/v2024.12.0 The following sequence of images show the sign in process where I have: - Bitwarden Legacy 2024.10.0 (11270) - Bitwarden Native 2024.12.0 (19597) - Keyguard 1.7.1-12356 21 December 2024 All installed and accessing the same vault. I can log into Ubank successfully using Bitwarden legacy and Keyguard. Bitwarden native now attempts to log in, but fails. ![image](https://github.com/user-attachments/assets/35ba3023-2f0b-48f0-863e-04392728c053) After selecting Bitwarden Beta, I get a message: "Passkey operation failed because user could not be verified." ![image](https://github.com/user-attachments/assets/13212d6f-8de3-4a90-85c8-41d926c8a6d3) After hitting OK, I get a second message: "We were unable to process your request. Please try again or contact us." ![image](https://github.com/user-attachments/assets/23e6235b-e933-4a91-b0cb-5225dc19539a) A search for those strings uncovers them in the Bitwarden code base (so they're undoubtedly coming from Bitwarden rather than the bank): https://github.com/bitwarden/android/blob/6223f362c32a604d96676793e575e8d6ee1c0382/app/src/main/res/values/strings.xml#L938 and https://github.com/bitwarden/android/blob/6223f362c32a604d96676793e575e8d6ee1c0382/app/src/main/res/values/strings.xml#L698 Again: - I can log in successfully using Bitwarden - I can log in successfully using Keyguard

GiteaMirror commented

@BJReplay commented on GitHub (Jan 13, 2025):

@daniellbw this issue is still an issue with 2025.1.0 (19622) https://github.com/bitwarden/android/releases/tag/v2025.1.0 - with this version, Bitwarden legacy and Keyguard both present a passkey, but Bitwarden native does not - so we're back to the original described issue:

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

Actual Result
Only Bitwarden (and KeyGuard) is displayed as holding the Passkey for the banking app.

@BJReplay commented on GitHub (Jan 13, 2025): @daniellbw this issue is still an issue with 2025.1.0 (19622) https://github.com/bitwarden/android/releases/tag/v2025.1.0 - with this version, Bitwarden legacy and Keyguard both present a passkey, but Bitwarden native does not - so we're back to the original described issue: **Expected Result** Bitwarden Beta should be presented as holding the Passkey for the banking app. **Actual Result** Only Bitwarden (and KeyGuard) is displayed as holding the Passkey for the banking app.

GiteaMirror commented

@pamperer562580892423 commented on GitHub (Jan 31, 2025):

@daniellbw Could it be that this whole problem with "Ubank" also has to do with ubank restricting passkey creation? According to their website (https://www.ubank.com.au/help/current/app-and-online-banking/passkeys/what-are-passkeys - see the screenshot below my text), they allow it only for Android and iOS devices, indicating they have some restrictions set in place - and that could be also a hindrance for working with a third-party passkey provider?!

PS: According to the Bitwarden help sites (https://bitwarden.com/help/storing-passkeys/#tab-android-3XutklkReT3Gw0l1qHhBem), at least for Android it is also said, that passkeys supporting apps on Android is not yet implemented:

Maybe this is an additional problem here?

@pamperer562580892423 commented on GitHub (Jan 31, 2025): @daniellbw Could it be that this whole problem with "Ubank" also has to do with ubank restricting passkey creation? According to their website (https://www.ubank.com.au/help/current/app-and-online-banking/passkeys/what-are-passkeys - see the screenshot below my text), they allow it only for Android and iOS devices, indicating they have some restrictions set in place - and that could be also a hindrance for working with a third-party passkey provider?! ![Image](https://github.com/user-attachments/assets/16e7170a-85fd-411e-a8c3-e2f5435006d5) PS: According to the Bitwarden help sites (https://bitwarden.com/help/storing-passkeys/#tab-android-3XutklkReT3Gw0l1qHhBem), at least for Android it is also said, that passkeys supporting apps on Android is not yet implemented: ![Image](https://github.com/user-attachments/assets/40e2a191-d915-4f57-87ba-b2940d11870e) Maybe this is an additional problem here?

GiteaMirror commented