Support for passkey

[tatroc]

Summary

Will keepassxc support the new passkey standard?

Examples

(https://tidbits.com/2022/06/27/why-passkeys-will-be-simpler-and-more-secure-than-passwords/) For example, will keypassxc be able to store the private key for the passkey?

Context

I am a heavy user of keypassxc, passkey is an attempt at passwordless. However, there is still a private key which is required for authentication. I do not want to store all my passwords and 'passkeys' in my browser or keychain.

[kitingChris]

+1

[sxe]

Google started testing passkey support in chrome and Android. https://www.theverge.com/2022/10/14/23400775/google-passkey-login-chrome-android-beta

Would love to see this feature in keepassxc as well.

Cheers

[alensiljak]

Some additional links:

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

Obviously, KeePassXC would be a part of the overall solution as the integration with the browser and the OS is the key. The rest of the flow is very similar to what we have today with strong random passwords and the .kdbx sync across devices.

[michaelk83]

Related: https://github.com/keepassxreboot/keepassxc/issues/1870#issuecomment-1277040691:

A quick glance at this shows that the API for Passkeys with Chrome is restricted to its own password manager. Which is a bit disappointing.

[alensiljak]

Related: #1870 (comment):

A quick glance at this shows that the API for Passkeys with Chrome is restricted to its own password manager. Which is a bit disappointing.

As they say themselves:

Passkeys are an emerging technology and supported environments are still evolving. As of October 2022, Chrome on macOS and Windows stores passkeys on the local device only.

and

A new API set that will offer full passkeys support for Android apps will be released soon.

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

The important bit is:

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

[droidmonkey]

I'm not sure where KeePassXC will fit into PassKey. It most definitely is leveraging the OS Native (read kernel trust level) key store of the operating system. That means defined OS Native calls through a common API platform layer.

So unless operating systems offer an alternative to their own kernel trust store.... I think you know what the answer to that is. And honestly there shouldn't be an alternative, it would completely break the trust chain and guarantees that kernel level provides.

[alensiljak]

I'm not sure where KeePassXC will fit into PassKey

You are most-likely right. This may be more of an issue for the browser extension and enhancing the API to be able to supply the key from KeePassXC. Also the key generation.

Eventually, there would be APIs supporting 3rd-party key storages, which is where KeePassXC would fit. The Android team has already stated that they will support this scenario.

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

I'm not sure how things work on macOS (https://developer.apple.com/passkeys/).

[droidmonkey]

Apple will never support third party stores, that is totally against their corporate principles and would nullify their security guarantees. Android has to support third party stores because Samsung exists. That is the only reason. This isn't for anyone to implement, it's for trusted partners.

After reading all the articles on passkey I am going to close this as we won't be able to participate. If there is a real third party future we can evaluate at that time.

[zerobiscuit]

Dashlane password manager claims to have this capability, if they can do it, could it not be possible via KeePassXC?

https://www.theverge.com/2022/8/31/23329373/dashlane-passkeys-password-manager

[tatroc]

I'm skeptical that this cannot be supported. Although I'm not an expert in this area. This blogpost, states: These operating systems will store passkeys just as they do passwords and other entries in the user keychain, protected by a device password or passcode, Touch ID, or Face ID. Passkeys will also sync securely among your devices using iCloud Keychain, which employs end-to-end encryption—Apple never has access to passkeys or other iCloud Keychain data. . If the passkeys are stored in keeychain , how can then not be stored in a different store? Unless as droidmonkey stated Apple does not allow the support. Also on the 1password forums someone asked a similar feature request, and 1pass played coy stating there is exciting new feature to come.

[droidmonkey]

Remember these companies can pay to play... just cause they support DOES NOT mean there is a public api for the feature. I am skeptical of the browser vendors not locking this into operating systems and commercial players.

[alensiljak]

https://bitwarden.com/blog/passwordless-authentication-access-your-bitwarden-web-vault-without-a-password/

I'll throw this in here for those who missed it and add that I did not check the code implementation but can confirm that the feature works as described.

[bynt]

Google just announced availability in Chrome Stable M108. https://blog.chromium.org/2022/12/introducing-passkeys-in-chrome.html

[delize]

From the above link, i think there are a few important quotes there.

With the latest version of Chrome, we're enabling passkeys on Windows 11, macOS, and Android. On Android your passkeys will be securely synced through Google Password Manager or, in future versions of Android, any other password manager that supports passkeys.

On a desktop device you can also choose to use a passkey from your nearby mobile device and, since passkeys are built on industry standards, you can use either an Android or iOS device.

https://developer.apple.com/documentation/authenticationservices/connecting_to_a_service_with_passkeys

https://passkeys.dev/docs/intro/what-are-passkeys/

https://developers.google.com/identity/passkeys

It seems like there is plenty of open api's to be used here. So i don't fully understand your pay to play comments, or device locked. It's a fairly open standard, with documentation coming in all forms.

Microsoft is the only vendor so far that i can't find an open developer documentation for, but they have also started more documentation will come in 2023 regarding their configuration of passkeys.

[varjolintu]

There's already this: https://github.com/keepassxreboot/keepassxc/pull/8825 but it doesn't solve all the walled gardens around Passkeys. For example with Google it seems it's only possible to add Passkeys as an authentication method if you use their password manager. The system is not really open yet, even if it's a open standard. It would be nice if browsers added an open API for inspecting and/or redirecting WebAuthn register/authentication calls. For now we must rely on dirty script injections.

[cmdli]

Supporting passkeys is possible in a password manager, but requires either support from the OS (e.g. Android) or workarounds. I was able to get it working in VirtualFIDO (https://github.com/bulwarkid/virtual-fido) and Bulwark Passkey (https://bulwark.id) by emulating a USB device and building the WebAuthN/FIDO2 protocols off of that. I believe Dashlane also as a beta version working, but from my limited investigation it seems to intercept the Javascript calls in the browser in order to support WebAuthN, though I could be wrong as its a proprietary system.

[alensiljak]

And, speaking of monopolies... https://www.bloomberg.com/news/articles/2022-12-13/will-apple-allow-users-to-install-third-party-app-stores-sideload-in-europe

Additionally,

Currently, third-party web browsers, including ones like Chrome from Alphabet Inc.’s Google, are required to use WebKit, Apple’s Safari browsing engine. Under the plan to meet the new law, Apple is considering removing that mandate.

[droidmonkey]

This request is related to #1870 and #8825

[NeatNit]

I just want to warn you regarding this promise:

From the above link, i think there are a few important quotes there.

With the latest version of Chrome, we're enabling passkeys on Windows 11, macOS, and Android. On Android your passkeys will be securely synced through Google Password Manager or, in future versions of Android, any other password manager that supports passkeys.

https://developers.google.com/identity/passkeys

It seems like there is plenty of open api's to be used here. So i don't fully understand your pay to play comments, or device locked. It's a fairly open standard, with documentation coming in all forms.

Google has promised the same thing about WebAPKs: https://web.dev/webapks/ (archive.org mirror)

Q: I am a developer of another browser on Android, can I have this seamless install process?

A: We are working on it. We are committed to making this available to all browsers on Android and we will have more details soon.

This feature was launched in January 2017, here's an article for evidence, and guess what - Chrome is still the ONLY browser with this feature.... Except on Samsung devices, where Samsung Browser is the other only browser with this feature.

Bottom line: for Android, don't count on it!

[alensiljak]

I'm sure you've all seen this: https://hachyderm.io/@rmondello/110329118270492669

Guess we just need to wait a bit longer...

[droidmonkey]

Core to the early passkey design docs was the idea that the user can never ever export the private key. This is true across every public private key design system. If users are exporting private keys from specialized key storage hardware, the system has failed.

The only proposal I’ve seen is that a user would be able to enroll multiple tiered keys at the same time, which neither solves the vendor lock-in problem or the usability design.

https://c.im/@matdevdug/110329168251222302

Interesting discussions in that thread, thank you for sharing.

[tatroc]

https://developer.apple.com/passkeys/

"Now people can share passwords and passkeys from iCloud Keychain with their trusted contacts. Password manager apps can save and offer passkeys on iOS, iPadOS, and macOS. Enterprises can take advantage of passkeys thanks to Managed Apple ID support for iCloud Keychain. And administrators can manage which devices passkeys sync to using Access Management controls in Apple Business Manager and Apple School Manager."

[3d73a4a412]

So its not clear to me, I assume there are plans to support passkeys (bitwarden and lastpass have announced planned support) is there a timeframe? I cant find much mention of passkeys as they relate to keepassxc

[droidmonkey]

See https://github.com/keepassxreboot/keepassxc/issues/8214#issuecomment-1407657084

[dobesv]

It looks like third parties can add their own passkey implementation to Chrome by implementing it in an extension. The extension would either use a new API to chat with the KeePass desktop app to complete the auth request or load the private key from KeePass and do the calculations itself.

[marcomsousa]

1password already supports passkeys:

• https://blog.1password.com/save-sign-in-passkeys-1password/
• https://1password.com/product/passkeys

It works directly inside Chrome with 1password extension:

• Open https://accounts.ebay.com/acctsec/security-center
• Press Turn on: Security key sign in Use your FIDO 2-compliant security key (NFC, BLE, and USB) to sign in to eBay instead of your password.
• 1Password extension open to save a new passkey for eBay. Generate a new key pair Public/Private just for eBay, give the server the public key, and store in 1password the private key.
• Logout eBay
• Login again. 1password extension asks me to use the passkey for eBay. I approve. I've finished it.

Also works with a phone:

• I can also log in with the Android/iOS, by validating my fingerprint/Face ID.
• Also can use the QR code to validate by phone.

I see these passkeys as the future, much more secure than random passwords and more secure than OTP/SMS/Auth. The only thing that is more secure than virtual passkeys is Hardware Passkeys like Yubikey.

But Hardware Passkeys have downsides: only have one single Private/Public Key, so you can't share it, and you can't backup it. Hardware Passkeys (Yubikey) are for the IT administrator's purpose. Passkeys are for the general public: A key pair for each app/service/website with a local biometric validation.

[ttonin33]

Bulwark Passkey can do it like an Fido Stick without the need of an broser extension and it is open source. https://github.com/bulwarkid/bulwark-passkey

[droidmonkey]

I see these passkeys as the future, much more secure than random passwords

I agree with them being the future, but synchronized (virtual) PassKeys are exactly the same thing as randomized passwords stored in a password database. The security of the solution rests with the storage and transfer medium.

[marcomsousa]

I see a lack of total understanding of passkeys.

PassKeys are exactly the same thing as randomized passwords stored in a password database 1) Key pair certificate isn't the same as a random password. It is a hundred times safer. An 8/20/40 length random password isn't the same as a key pair certificate

2) If a hacker stole the website passwords he is stealing the public keys. With the public key is impossible to get to the private key. So the user can still be continuing using the same private key without any problem.

If any hacker leak is a public key to the web, no one can log in to the website.

3) During the validation, the private key never leaves the user local or provider.

4) Implicitly MFA: The Passkey's private key standard is mandatory to be used using a local biometric sensor, like Windows Hello, iPhone Face ID, Android/Mac fingerprint, etc.

Sure there is always something we need to trust, but it's more secure to trust 1 security website, company, or local app, to store the Virtual PassKeys than trust in all the web.

[droidmonkey]

I see a lack of total understanding of passkeys.

That's incredibly assumptive.

PassKeys are exactly the same thing as randomized passwords stored in a password database 1) Key pair certificate isn't the same as a random password. It is a hundred times safer.

True for length of material, but not in the context that you chopped off.

2) If a hacker stole the website passwords he is stealing the public keys. With the public key is impossible to get to the private key. So the user can still be continuing using the same private key without any problem.

Hashing. Stealing public keys is exactly equivalent to stealing hashed, salted passwords. Again don't take me out of context, we are talking about secure randomized passwords.

3) During the validation, the private key never leaves the user local or provider.

Concur here.

4) Implicitly MFA: The Passkey's private key standard is mandatory to be used using a local biometric sensor, like Windows Hello, iPhone Face ID, Android/Mac fingerprint, etc.

Wrong in some contexts. Only device bound (ie hardware stored and managed) PassKeys are MFA equivalent. You chopped off my context that stated that.

[marcomsousa]

Hashing. Stealing public keys is exactly equivalent to stealing hashed, salted passwords. Again don't take me out of context, we are talking about secure randomized passwords.

If a website that you use a strong key is hacked, please change your password anyway..

are you sure that you should trust the whole web with security?

You don't know how if website is following the best security practices, and even so, you should change it ASAP because potentially can be reversed engineering.

Shared a public key is completely fine, is how the whole web https works. Is impossible to brute force your private key.

2) Trust in Apple, Google, 1password or KeePass is something that each individual needs to think about it. But this isn't the question, since random password we have the same problem..

[droidmonkey]

BTW, I am totally for passkeys and this implementation, just for the record. They are not magical though.

[tmccombs]

Hashing. Stealing public keys is exactly equivalent to stealing hashed, salted passwords. Again don't take me out of context, we are talking about secure randomized passwords.

Not exactly. For one thing, with hashed password the private key (password) has to be transmitted to the server, so if the server is compromised, an attacker might be able to get the plaintext password which they can then use in future requests. For another, you have to rely on the service provider to securely hash and salt your password, which is relatively easy to mess up. With an asymmetric keypair, if the other party doesn't store your public key sufficiently securely it isn't as much of a problem.

The Passkey's private key standard is mandatory to be used using a local biometric sensor, like Windows Hello, iPhone Face ID, Android/Mac fingerprint, etc.

What if your device doesn't have any biometric interface? Like, say, a linux desktop without a webcam.

[marcomsousa]

What if your device doesn't have any biometric interface? Like, say, a linux desktop without a webcam.

Fingerprint sensor, or can be an external device. for example the big tech if you have your passkeys in Apple/Google, and you try to access via windows chrome, Chrome will ask to scan a qr code with the trusted Android. (MFA)

[dobesv]

synchronized (virtual) PassKeys are exactly the same thing as randomized passwords stored in a password database. The security of the solution rests with the storage and transfer medium.

The passkey is not as vulnerable to phishing attacks, though. If someone can trick you into entering your password on their fake version of a site, they can then use your password to log into the original site. Even with TOTP they can steal both your password and TOTP to log into your account as long as they complete the operation within the TOTP expiry window. With passkey the handshake is mutual and no secrets are exposed to the website either client or server side.

Note that even in a case like using KeePass where no biometric login is required, there are two factors in a way - (1) having a copy of the password database with the username and passkey in it and (2) having the password to that database. An attacker who only knows your password OR only has a copy of your password database can't log in. With a typical website login without 2FA they only need to know your username and password.

Phishing is a far bigger problem for people than someone getting access to their password database file, so using passkeys is a huge improvement over using passwords.

[dobesv]

hashed password the private key (password) has to be transmitted to the server, so if the server is compromised, an attacker might be able to get the plaintext password

Note that this doesn't have to be the case, there is a protocol called secure remote password which does not transmit the password. It uses a cryptographic proof of having the same password without sending it. However, it's not implemented at the browser or OS level, so it's still subject to phishing because a fake website will still have the user entering the password plaintext in the browser. It does avoid having the plaintext passwords exposed if the server's database is compromised, though. Or if there's a MITM attack at the network layer the password is still protected.

[marcomsousa]

Github now support Passkeys

No username/password directly with the passkeys.

[ttonin33]

Passkeys are the future, there have a lot of advantages and an implemention is inedeble if KeepassXC want to be ready for the future more and more Websites suport them and a normal Password with OTP is still not nearly as secure and never gonna be. Specaly because it requers an easy to mess up ore ingnore (like use of broken methodes like MD5) implementation of Password transver and storage, also passwords are posible for pfishing. Both weaknisses Passkeys dont have.

[dobesv]

implementation of Password transver and storage

Just to clarify, passkeys usually only replace password for most logins, to prevent phishing attacks or password interception. But for the majority of sites they won't replace passwords yet. Most sites will offer passwords and password reset as a backup login method for when you don't have your passkey handy. And the sites I have used so far still require you to set up a password.

I suppose sites that want to go fully passwordless could use another passwordless login method as the backup, like emailing you an instant login link, though. But that's a totally independent matter from the use of passkey and could be done without implementing passkey.

[varjolintu]

Github now support Passkeys

No username/password directly with the passkeys.

I have been now testing this. Registration works with small tweaks to the extension code, but logging in still needs some work. GitHub is using conditional mediation for the login process, and KeePassXC does not support that. However, if that feature is disable from the client, the login process should go without any extra prompts, but it still does not work yet. I haven't found the exact reason why it fails, but I'll keep investigating the issue.

EDIT: I'm missing support for userHandle and some extensions GitHub is using. I should be able to fix the issues.

[varjolintu]

Closing this a a duplicate. Let's continue to discuss this feature in the older thread: #1870.