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]

keepassxreboot/keepassxc#8825
https://w3c.github.io/webauthn/
https://passkeys.dev/docs/tools-libraries/libraries/
https://github.com/webauthn4j/webauthn4j
https://github.com/passkeydeveloper/discussions/discussions
https://developer.android.com/identity/sign-in/credential-provider

Tests :
https://passkey.org/
https://www.passkeys.io/
https://webauthn.io/

Issues :
bitwarden/mobile#3253
https://community.bitwarden.com/t/passkey-android-beta/66467/10
https://issuetracker.google.com/issues/349310440

[alensiljak]

also keepassxreboot/keepassxc#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.

keepassxreboot/keepassxc#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.