Support for Passkeys

[alensiljak]

Wondering if it is time to resurrect the request for passkeys support. The initial support has come to Android and it may soon be possible to have 3rd-party apps managing passkeys on devices. I'd like my passkeys stored in .kdbx files, along with other sensitive data. At this point, this is a brainstorming and research stage. Also, this could be related to some other issues involving FIDO standards.

The end-result is to have KeePassDX as the storage and a key generator for Passkeys on Android.

Background info:

• https://fidoalliance.org/passkeys/
• https://developer.apple.com/passkeys/
• https://developers.google.com/identity/passkeys
• https://android-developers.googleblog.com/2022/10/bringing-passkeys-to-android-and-chrome.html
• https://developers.google.com/identity/passkeys/supported-environments
• https://www.passkeys.io/

Add Android Credential provider :

• https://developer.android.com/training/sign-in/credential-provider

Emphasis on the statement from Google:

Note: In the future, Android users will be able to use third-party credential management apps to store their passkeys.

[J-Jamet]

https://github.com/keepassxreboot/keepassxc/pull/8825 https://w3c.github.io/webauthn/ https://passkeys.dev/docs/tools-libraries/libraries/ https://github.com/webauthn4j/webauthn4j https://github.com/passkeydeveloper/discussions/discussions

[alensiljak]

also https://github.com/keepassxreboot/keepassxc/pull/8214

[matchboxbananasynergy]

https://developers.google.com/identity/passkeys/supported-environments

Note: Starting from Android 14, users will be able to opt to use third-party credential management apps to store their passkeys.

https://developer.android.com/training/sign-in/passkeys

[J-Jamet]

Yes, unfortunately it will take time to implement this feature, and the fact that Google already has its PassKeys private key storage system won't make it any easier to adopt KeePass.

[matchboxbananasynergy]

Yes, unfortunately it will take time to implement this feature, and the fact that Google already has its PassKeys private key storage system won't make it any easier to adopt KeePass.

To be fair, I'm okay with waiting for this to be implemented in KeePass and other 3rd party password managers, as implementation there isn't urgent given that actually using passkeys to sign up for services isn't as widespread just yet. I doubt people can sign up for 100% of their services via passkeys at this time.

[Kareltje1980]

This is really getting some traction. There is already some collaboration between other keepass clients on how these should be stored in keepass vaults.

https://github.com/keepassxreboot/keepassxc/pull/8825

I think it would make sense to take a look at this implementation.

[serrq]

It seems that a kind of "passkey provider" is needed, in order to use this method. A sync process is required. Major actors involved? Apple, Google, Microsoft, etc.

I remain in the 100% offline and syncless world. Bye bye passkey.

[life00]

It seems that a kind of "passkey provider" is needed, in order to use this method. A sync process is required. Major actors involved? Apple, Google, Microsoft, etc.

I remain in the 100% offline and syncless world. Bye bye passkey.

@serrq I am afraid that you might not have a choice in few decades considering that all large tech companies are currently standardizing it. Google even made it a default login option and they encourage users to use it [1].

Quote from that article:

In the meantime, we’ll continue encouraging the industry to make the pivot to passkeys—making passwords a rarity, and eventually obsolete.

I am also a bit concerned about the sync process requirement and the flexibility of passkeys.

[1] https://www.wired.com/story/google-passkey-default/

[serrq]

I forgot to say also trustless. You need to trust in your sync provider. And leaderless: no single point must to have a prominent role from mountain to valley.

And here everything seems centralized and dependent on a leader. Again.

[life00]

@serrq you know, the issue I find with passkeys flexibility is that its implementation is up to the browser or the OS. There is no underlying universal support as it is with password/passphrase/pin code. If you look at the Device Support page you might notice the problem (e.g. Apple ID, Google account requirement).

Passkeys create a monopoly on authentication service unless the browser or ideally the OS provides an open standard API for 3rd party credential managers. Otherwise there is just no way you can authenticate.

Fortunately as it was already mentioned here Google seems to plan on providing such API.

[serrq]

@life00 It also needs to understand if these APIs will be open source. However, I don’t really have the problem, since I will avoid the passkeys.

I’m not convinced. Not even the mathematical link behind it. Will we find out in 30 years' time that a quantum computer can calculate the private key from the public key?

Asses available? Many.

[life00]

@serrq I definitely agree with you and I personally would prefer to avoid passkeys for the same reasons. I do not want to be so dependent on any proprietary service and there might be a threat of QCs in the long term.

But again as said already. We might just not have a choice considering the current trend of moving to passkeys.

What if GitHub will force everyone to use passkeys like they did with 2FA? You'll likely switch from GitHub, but what if this happens with more services?

The only hope is that passkeys will be reasonably open to allow 3rd party clients.

[serrq]

@life00 Who will force you to do something is simply saying: «you will have no other god that me.»

An assertion, but also an own goal. The clever will look elsewhere, the fools will let themselves be caught in the big net.

[serrq]

What is a long term QC? I am not a developer and not even English native.

[alensiljak]

This is getting too philosophical. Please focus the posts here to the implementation of the feature.

[life00]

@alensiljak sure, I just wanted to point out that the implementation of this feature is important and it will inevitably be needed.

[andromedasun]

@serrq you know, the issue I find with passkeys flexibility is that its implementation is up to the browser or the OS. There is no underlying universal support as it is with password/passphrase/pin code. If you look at the Device Support page you might notice the problem (e.g. Apple ID, Google account requirement).

Passkeys create a monopoly on authentication service unless the browser or ideally the OS provides an open standard API for 3rd party credential managers. Otherwise there is just no way you can authenticate.

In the link you provided, the row for third party passkey providers is the relevant one. Both Apple and Google seem to support this, and Microsoft (Windows) is already planning it. I don't see a Google account or Apple ID requirement there.

On Android it's available from version 14, which has just been released. I am waiting to test it out as soon as a Keepass client or Bitwarden ships with the passkey support.

Linux's passkey support is poor at the moment, but AFAIU some browsers on Linux can use third party managers to login, but cannot generate passkeys because typically it's the OS that generates them and then stores them immediately onto a TPM, and also passes this to a password manager/sync provider which should store/transmit it encrypted only. According to the spec, the keys should never leave the device unencrypted.

Linux supports hardware authentication devices (I think these are called device specific keys than passkeys), but they have very limited capacity in terms of number of keys, and doesn't support sync.

The mechanism of sync between providers is currently left unspecified by the standard. I think I have read syncing passkeys between Apple and Google account is possible but can't verify this for sure. If sync isn't possible you will need to login to every service you use and generate a new passkey once you login on the device that doesn't have the passkey using cross device authentication (assuming the website allows you to create new passkeys). This is why I have been waiting till Android 14 to start using passkeys, so that I can store my passkeys in a third party manager rather than place my bets with Google immediately.

and there might be a threat of QCs in the long term.

There maybe worse things to worry about if Quantum Computing becomes relevant to passkeys because the global digital infrastructure including SSL/HTTPS communication depends on public/private key cryptography anyway and your passwords would then be no better than if they were sent as plaintext.

I think there is research being done to mitigate the threat of QC in the long term, some of which is already promising. I don't know if protection against QC from these techniques depends on no one having found a technique to crack them by modeling it as a QC problem yet, but I guess it's a different question outside the scope of this thread.

[serrq]

I hope that the encryption algorithm is out of the PassKey spec, so that newest and more performing one comes in the future will be easy to implement in a kind of key renegotiation.

[mas1701]

Just found this issue on KeePassDX when searching for Keepass for Android w/ Passkeys support.

Things I'd like to point out:

• current KeePassXC v2.8.0 snapshot has just added working Passkeys implementation on the PC, official v2.8.0 release should follow very soon
• I'm currently using that KeePassXC version and I'm using it with Nextcloud's WebAuthn/Passkey option (I got my snapshot version from one of the devs)
• I also tried Nextcloud's WebAuthn/Passkey option on my Samsung Galaxy Note 20 5G Ultra and it works out of the box, I registered with Nextcloud using the Samsung Browser and they logged in using Brave for Android with that same identity.

Hope this information is useful for you.

[abiud254]

Quick question, does support for third party passkey managers like password managers on Android only work with Android 14 and no other version?

[mas1701]

Quick question, does support for third party passkey managers like password managers on Android only work with Android 14 and no other version?

Yes, this seems to be the case. At least as long as you use the Android integrated authentication APIs. But I'm an IT admin, not a software developer. It's far from being my area of expertise.

KeePassXC does JS injection on the PC, not sure if that method would be feasable on Android though.

I'm also testing another solution (on PC), which emulates a USB security token als a virtual USB device. Early version and seems a bit buggy. Was able to add this to my Nextcloud account for testing (the identity information was stored locally by this software), but could not log in afterwards with this tool.

But with Google and others pushing towards Passkeys, I expect a lot more development to happen in this area soon.

[Calmquist]

KeepassXC appears to be in the process of back porting passkey support to 2.7.7: https://github.com/keepassxreboot/keepassxc/pull/10189

Bitwarden appears to be adding it as part of the migration from Xamarin to MAUI: https://github.com/bitwarden/mobile/tree/feature/maui-migration-passkeys . It appears to still be in early development, but it looks like Bitwarden is using the credential provider API.

[Kranzes]

PassKey support has just been added to KeePassXC 2.7.7 so I think it would be nice to have support for PassKeys on KeePassDX too. One super important thing I have got to request is to not use Google's API for passkeys on android, it doesn't work on a degoogled phone and barely works with MicroG. Nextcloud uses a different WebAuthn library I believe that does actually work on a degoogled device, please consider using it or if there is a better and newer library use that instead, anything but the Google one that forces you to use Google Play Services.

Google are attempting to kill security keys on degoogled phones by moving everything towards their own implementation

[Calmquist]

PassKey support has just been added to KeePassXC 2.7.7 so I think it would be nice to have support for PassKeys on KeePassDX too. One super important thing I have got to request is to not use Google's API for passkeys on android, it doesn't work on a degoogled phone and barely works with MicroG. Nextcloud uses a different WebAuthn library I believe that does actually work on a degoogled device, please consider using it or if there is a better and newer library use that instead, anything but the Google one that forces you to use Google Play Services.

Google are attempting to kill security keys on degoogled phones by moving everything towards their own implementation

Is that true with the Android 14 Credential Manager API? It was supposed to add support for third party credential providers such as KeePassDX. I have read reports of 1Password's passkey implementation working on GrapheneOS.

[Kranzes]

1Password might be using a different library than Google's. I know that the MicroG still doesn't have full support for it, that would imply that stock AOSP without Google services doesn't actually support it.

I'm still on Android 11 and don't plan on updating so I'm not too sure. You might be able to support both a non-google WebAuthn implementation for security keys and a "PassKey" implementation using Google' stuff.

[foss-]

1Password is using their own library for Passkeys: https://blog.1password.com/passkey-crates/

[Kranzes]

I just checked on GrapheneOS forums and people are saying that third party passkeys do not work because they rely on Google Play Services.

Oh and btw MicroG doesn't even supports all the use cases and features for even FIDO2 Security Keys, it is getting better, I'm on an older MicroG version but still the only app I tried so far that supports WebAuthn security keys without any MicroG or Google Play Services is Nextcloud.

[Ironfist69]

Bump

[martinord]

Here's some insight on how Proton Pass has approached this: https://proton.me/support/pass-use-passkeys

[Calmquist]

I just checked on GrapheneOS forums and people are saying that third party passkeys do not work because they rely on Google Play Services.

Oh and btw MicroG doesn't even supports all the use cases and features for even FIDO2 Security Keys, it is getting better, I'm on an older MicroG version but still the only app I tried so far that supports WebAuthn security keys without any MicroG or Google Play Services is Nextcloud.

Sadly, I believe the application (e.g. web browser) needs to support third party passkeys to avoid the Google Play Services dependency. I know of no applications that actually support them. Chromium has limited experimental support, but it appears to use Google Password Manager as an intermediary.

[bingoxo]

Here's some insight on how Proton Pass has approached this: https://proton.me/support/pass-use-passkeys

can confirm it works without Google Play Services

[mrghosti3]

https://passkeys.dev/device-support/

[AZMCode]

Honestly I don't particularly agree with some of the negative sentiment on Passkeys. The idea of being able to log in single-click to multiple popular applications using public-key cryptography in a way where the underlying private key is never exposed to anyone unencrypted sounds pretty appealing to me.

It is as close to universal password manager integration as we'll probably get, and in my opinion perfectly aligns with the spirit of password managers in general.

I hope to soon see Passkey support in KeepassDX, since I use applications (example, WhatsApp) that only really have options for either a really short and very repeatedly-needs-to-be-confirmed PIN, or Passkeys. This requires Passkey support in Android, for which KepassDX is my only possible provider.

I already use KeepassXC Passkeys to great effect in my desktop, and I'd hope this app's implementation can at least be compatible with XC's implementation.

I also more broadly hope to see Passkey integrations and usage in Browsers, OS's and Password Managers like outlined above.

Options, specially options that increase security and convenience, are always good IMO.

[MicroPanda123]

I saw this: https://docs.passwordless.dev/guide/frontend/android and that it supports Android 9+ Would it make it possible for KeePassDX to support Passkeys on those versions of android or am I missing something EDIT: Nvm it's client sorry my bad

[Riyyi]

@AZMCode I think the important and deciding factor is if their is a new private key generated for each login, if it is then there isnt really an argument against passkeys. If there is only 1 global private key then I get the negative sentiment, however, afaik the password manager has control over this decision.

[kevinlucasilva]

Hello!

I would like to reaffirm @AZMCode's report, I completely agree with everything he said.

And I would also like to share a discussion that is taking place within the Bitwarden community about Passkeys:

https://community.bitwarden.com/t/passkeys-support-for-mobile-apps

I recommend with all due respect that before any initiative on Passkeys within KeePassDX, you take a look at this discussion (if you haven't seen it already), as development on Bitwarden is a little more advanced, and with some issues.

Anyway, I hope they can bring this feature, because the app would be even better than it already is.

THX.

[juliomaranhao]

As of now I can't even test passkeys in my PC because it's not supported. I don't use Microsoft Account login so NO Windows Hello. And my security key is solokey which are not accepted in 3 passkey test sites. I used Google Chrome for all tests today. By the way the bluetooth bridge option also failed (I am not surprised). I will reevaluate passkeys on ... 2025 maybe 2026.

[Thunderbolt32]

@juliomaranhao Which site did you test? https://webauthn.io/ ? If you use Windows, you can try Microsoft Edge. This sounds more like a broken PC setup than a problem with Passkeys. Fingerprint / facial recognition / Palm vein scan login also works with an windows offline account (but you need a TPM chip - which Windows 11 requires anyway). If the Windows passkey popup doesn't work for you (which it sounds like, since even logging in via Bluetooth and Hardware-Token doesn't work), you can still use a password manager that supports passkeys via a browser extension. For example https://keepassxc.org/ .

[juliomaranhao]

Which site did you test? https://webauthn.io/ ?

1. https://www.passkeys.io/
2. https://passkeys-demo.appspot.com/ (I thinks it is broken)
3. https://passkeys.guru/
4. https://passkey.org/ and 5. https://webauthn.io/ after your hint.

If you use Windows, you can try Microsoft Edge.

I decline your offer.

This sounds more like a broken PC setup than a problem with Passkeys.

I could accept "This sounds more like you doing something wrong ...". My PC (laptop) is doing pretty well in all other aspects.

Fingerprint / facial recognition / Palm vein scan login also works with an windows offline account (but you need a TPM chip - which Windows 11 requires anyway)

I forget to say I use Win10Pro. My PC is 7 yo (but it rocks!) and it's not Win11 compatible (I wouldn't upgrade anyway).

you can still use a password manager that supports passkeys via a browser extension. For example https://keepassxc.org/

Thanks! I tested it with Firefox (worked on all 4 test sites) and Chrome (worked on all 4 test sites). I am impressed! But for now I will wait for:

1. KeePass2 become a passkey manager (15 years user) and
2. Passkeys become more popular, more used, more known, more syncable/exportable/importable and
3. All my family Android gadgets fully support 3rd-party passkey managers (Android 14+?). I have Android 7, 8, 9 and13. Thats the reason I'm not in a hurry about passkeys. I feel it like an IP vs IPv6 story (slow adoption and no strong need to migrate).

But I support this quest for passkey support in KPDX. If I can use KPXC and Android 14+, why not?

[kevinlucasilva]

Some sites are broken with Passkeys, like Microsoft, Nintendo, Bitwarden (lol why not?), etc. on KeePassXC.

So, don't worry to bring Passkeys support, but it's appreciated.

[AZMCode]

Some sites are broken with Passkeys, like Microsoft, Nintendo, Bitwarden (lol why not?), etc. on KeePassXC.

So, don't worry to bring Passkeys support, but it's appreciated.

?

I have personally used Passkeys with Microsoft not too long ago, and had no such issues

[kevinlucasilva]

I have personally used Passkeys with Microsoft not too long ago, and had no such issues

Um.. but it doesn't work for me, the site asks for a security key, and doesn't open the dialog window for save its credentials on KeePassXC.

I'm using in Librewolf and Ungoogled Chromium on Linux, but I tested in Chrome, and it didn't work as well.

[foss-]

This is probably not the place to discuss personal passkey pet issues. If you run into trouble with a website and KeePassXC passkey integration add your report to https://github.com/keepassxreboot/keepassxc/issues/10374.

For KeePassDX questions you can open a discussion.

This issue here is about Passkey support in KeePassDX - please stay on topic. No need to bump or metoo this issue, you can use reactions for that.

[cali-95]

I'll look into the implemention of KeepassDX as a credential-provider in Android 14 and up.

[cali-95]

I'll look into the implemention of KeepassDX as a credential-provider in Android 14 and up.

I pushlish my current version at https://github.com/cali-95/KeePassDX/releases/tag/v0.1.0 and I am open for feedback.

[mcrocker]

@cali-95 I have an old Pixel 4 with GrapheneOS available for testing, so I gave it a try and installed your version of KeePassDX on it. There was a conflict and I had to delete the other KeePassDX because installation wasn't treated as an upgrade and there were two apps with the same intents. That allowed unlocking the database to work.

I created a database on KeePassXC with a record for an account on PassKeys.io and a stored password.

The records show up just fine in your version of KeePassDX. Attempting to use this record to login on passkeys.io didn't work in any browser I tried. DuckDuckGo has the "Sign in with a passkey" button is greyed out altogether. Logging in with the email I had stored as the username in KeePassDX worked in the sense that it then sent me an email with a passcode. Ice Raven let me click the button, but it just displayed a spinner and did not appear to do anything else. Trying to login with the email, claimed the account didn't exist. Finally, for the browser that matters, Vanadium, "Sign in with a passkey" popped up a dialog featuring a Google colored key and saying "no passkeys available" and an option to try another device, none of which included KeePassDX.

Trying to create a key with WebAuthN.io. Duck Duck Go, simply displayed a message that passkeys are not supported. Attempts to register with the same email from above with Ice Raven generate an abort message. Vanadium registration attempts just popped up the Google key dialog and continuing tries to register the passkey with Google. Luckily I haven't logged into Google with this device in a long time so I was locked out and Google never got to find out what my passkey was.

I tried to look around for various settings that might help, but the only passkey reference on the device settings was about linked passkey devices. I didn't see any settings in the app that looked like it might do something to help.

I'm sure I'm doing something wrong.

[Calmquist]

@cali-95 I have an old Pixel 4 with GrapheneOS available for testing, so I gave it a try and installed your version of KeePassDX on it. There was a conflict and I had to delete the other KeePassDX because installation wasn't treated as an upgrade and there were two apps with the same intents. That allowed unlocking the database to work.

Pixel 4 is past end of life. Are you on Android 14? Which version of which browser are you using? Depending on the Chromium version, you may have to set certain experimental flags to allow third party passkey support.

[cali-95]

There are some requirements and not all features are implemented right now. For details please checkout the last section of https://github.com/cali-95/KeePassDX/tree/credentialprovider. I did not tested with GrapheneOS.

[mcrocker]

@Calmquist:

Pixel 4 is past end of life. Are you on Android 14? Which version of which browser are you using? Depending on the Chromium version, you may have to set certain experimental flags to allow third party passkey support.

OMG :man_facepalming: I knew that. I chose the Pixel because it was an old device I had sitting around that would be safe to experiment on. The GrapheneOS folks are still supporting Pixel 4, so I thought it would be fine. But I wasn't paying enough attention. They were only providing security fixes for Android 13. Sorry, this was my screw up and I added added noise to the signal :face_holding_back_tears:

I'll try again with a more up-to-date version and let you know. I'll reply to @cali-95 's post separately.

[mcrocker]

There are some requirements and not all features are implemented right now. For details please checkout the last section of https://github.com/cali-95/KeePassDX/tree/credentialprovider. I did not tested with GrapheneOS.

You volunteered your time and expertise to code up a solution, which is awesome. Expecting you to also test on GrapheneOS is a heavy lift and I certainly wouldn't expect you to have the time and resources to test every obscure ALT-ROM out there. No worries.

Having said that, there was a fair bit of discussion further back in the thread expressing the hope that any implementation would not depend on Google Credentials libraries, which are poorly supported in many ALT-ROMS, DeGoogled devices, or in the case of GrapheneOS, deliberately excluded, or optionally sandboxed. There were even postings about 1Password having implemented and open sourced their own credential library. Since your Credential Provider addendum mentioned mentioned 1Password, I figured you had used that library and I should be good to test it.

I read all the code, but I don't know enough about the Android ecosystem to know what comes from where, so figured I'd just try it out and see. Apparently, I messed that up :face_with_diagonal_mouth:

I will try again later this afternoon with a newer GrapheneOS device. :crossed_fingers:

Thanks again for implementing this. :green_heart: