Support for passkey #8214
Comments
|
+1 |
|
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 |
|
Some additional links:
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. |
|
Related: #1870 (comment):
|
As they say themselves:
and
Source: https://developers.google.com/identity/passkeys/supported-environments The important bit is:
|
|
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. |
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. 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.
I'm not sure how things work on macOS (https://developer.apple.com/passkeys/). |
|
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. |
|
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 |
|
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. |
|
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. |
|
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. |
|
Google just announced availability in Chrome Stable M108. |
|
From the above link, i think there are a few important quotes there.
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. |
|
There's already this: #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. |
|
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. |
|
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,
|
|
I just want to warn you regarding this promise:
Google has promised the same thing about WebAPKs: https://web.dev/webapks/ (archive.org mirror)
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! |
|
I'm sure you've all seen this: Guess we just need to wait a bit longer... |
https://c.im/@matdevdug/110329168251222302 Interesting discussions in that thread, thank you for sharing. |
|
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." |
|
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 |
|
See #8214 (comment) |
|
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. |
|
1password already supports passkeys: It works directly inside Chrome with 1password extension:
Also works with a phone:
I see these passkeys as the future, much more secure than random passwords and more secure than OTP/SMS/Auth. But Hardware Passkeys have downsides: only have one single Private/Public Key, so you can't share it, and you can't backup it. |
|
Bulwark Passkey can do it like an Fido Stick without the need of an broser extension and it is open source. |
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. |
|
I see a lack of total understanding of passkeys.
If any hacker leak is a public key to the web, no one can log in to the website.
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. |
That's incredibly assumptive.
True for length of material, but not in the context that you chopped off.
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.
Concur here.
Wrong in some contexts. Only device bound (ie hardware stored and managed) PassKeys are MFA equivalent. You chopped off my context that stated that. |
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.
|
|
BTW, I am totally for passkeys and this implementation, just for the record. They are not magical though. |
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.
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) |
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. |
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. |
|
Github now support Passkeys No username/password directly with the passkeys. |
|
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. |
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. |
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 |
|
Closing this a a duplicate. Let's continue to discuss this feature in the older thread: #1870. |
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.
The text was updated successfully, but these errors were encountered: