jesseendahl
Joined 18 years ago
Joined 18 years ago
This is factually incorrect — no one supported exporting passkeys at the time and I believe the only ones who supported passkey sharing of any kind was Apple: https://support.apple.com/guide/iphone/share-passwords-iphe6...
What that Keepass X GitHub PR comment section was discussing was giving users a way to export their passkeys to an unencrypted file on disk, which would have allowed for attackers to convince non-technical users to export all their passkeys and then send them to an attacker.
I believe person who commented on that GitHub PR was trying to explain that instead of implementing export to plaintext file on disk, it would be a better idea to implement the Credential Exchange Protocol, which was almost finished at the time.
https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20240522.html
Fast forward to today... and it looks like there's movement towards doing exactly that:
https://github.com/keepassxreboot/keepassxc/pull/13343
--
Edit: Indeed if you scroll down to the last comment on that infamous PR (https://github.com/keepassxreboot/keepassxc/issues/10407#iss...), you'll see they closed it in favor of implementing the Credentials Exchange standard.
- Just because you don't do everything someone wants you to do does not make you a supply chain risk.
Google treats both a password and a passkey as a primary factor, and if you forget either of them you have to go through their account recovery flow: https://support.google.com/accounts/answer/7682439?hl=en
AFAIK there's nothing different about the recovery scenario for a Google account in that state regardless of whether it has a password in use as its primary cred, a passkey in use as primary credential, or both.
Passkeys can also be shared with other people like spouses or friends, just like passwords.
This is a strange conclusion to come to when clearly a lot of effort was put into developing an open standard (Credential Exchange Format) to make it easy and secure to move credentials between vendors/ecosystems, without opening end-users up to phishing attacks on credential export.
If big tech wanted to lock people in, it seems like it would have been a lot easier to just... not create an open standard.
This was never a design goal of passkeys as far as I'm aware, and normally passkeys are not generated or stored in a TPM. The primary design goal of passkeys was to make a phishing-resistant primary factor that could compete with the user experience and convenience of passwords, so that folks would actually be interested in using them.
I think you are thinking of security keys, which generate key material in e.g. a YubiKey which offer similar protections to a TPM.
YubiKeys can also be used to generate/store passkeys, but when they are used for passkeys typically they'd be referred to as "device-bound passkeys" rather than just "passkeys".
The high level UX of this idea feels very compelling to me as a "yes and" -- aka a world where vendors continue to offer end-to-end encrypted syncing within an ecosystem, but then this idea gets layered on to solve the cross-ecosystem problem. I think the trickiest part would be how to do it in a privacy-preserving way, but that's solvable.
passkeys are not meant to be a second factor; they are meant to replace the password as a primary factor.
>to protect against the theft or compromise of your primary device.
I love Yubikeys, but the only additional protection you get by making the passkey hardware-bound is preventing an attacker who has already compromised your operating system from stealing the credential.
But! Unless you are also doing hardware binding of the session (aka cookie) after sign-in, then doing hardware binding of your credential is mostly security theater, because the attacker can just wait for you to sign in and then steal your session.
And there is standards work happening separately for hardening session security, such as DBSC: https://w3c.github.io/webappsec-dbsc/
I have no idea if Yubico is involved with DBSC, but I would hope that they are, because it would help them make Yubikeys live up to the security guarantees that I personally feel are heavily implied by their marketing.
https://twitter.com/jesseendahl