7 ms·

> I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/k

> I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/key managers already supporting passkeys, i don't think it turned out to be true. Here's an Okta employee threatening to use the attestation (anti)feature of passkeys to block open-source implementations, because they allow you to export your passkeys: https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994673954 https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

FreakLegion 1y ago
Tim Cappalli is thoroughly misguided throughout that discussion, but he's not threatening anything. Okta lets users require attestation, but it will never, ever force attestation on anyone.
- josephcsible 1y ago
  The specific part that I consider a threat is "which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations".
  - FreakLegion 1y ago
    Sorry, to clarify: Okta is not for our purposes a relying party and won't do anything to force attestation on relying parties. The second bit of what he wrote is ambiguous, but charitably, could simply mean "I used to argue against requiring attestation, but now I'm not sure". Which is fine, since he has absolutely no pull when it comes to how Okta's product works (and to be fair, I don't think he implied otherwise or even mentioned Okta).
- jauntywundrkind 1y ago
  Tim's not threatening, but he is saying quite clearly that sites on the internet (Relying Parties) might just not accept Passkeys from KeePassXC: > The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations). Tim's talking the reality of KeePassXC and the reality is that this specification is being built in a way where the user is fundamentally out of control. Where the industry at large has total control over your material, gets to say how you can store your keys, and will refuse you credential managers that they don't like. The proposed Credential Exchange Protocol draft also does not allow you to backup your key. A credential manager will only Export the key to another credential manager service, across public endpoints on the internet. Never transiting the user's control. So you have to trust your credential manager that they actually will let you export your credentials, to someone you can trust, at a future point in time. There's an issue open for this, but no real hope this ever gets better. https://github.com/fido-alliance/credential-exchange-feedback/issues/24 https://github.com/fido-alliance/credential-exchange-feedbac... Passkeys seem designed to never be trustable by users. There's always some online service somewhere holding your materials that governments will be able to legally strongarm the service into getting access to. You won't be able to Export when you need it. The security people seem intent on making sure computers are totally controlled by corporations and governments, in the worst ways. The top post is right. https://news.ycombinator.com/item?id=45737608 https://news.ycombinator.com/item?id=45737608
  - FreakLegion 1y ago
    Correct, individual sites could make that choice. They won't, but they could. (Love the mention in the linked comment of Netflix and Disney, two services that don't even support proper MFA.) We're completely on the same side, to be clear. I just have zero fear of KeePassXC (which I sometimes use with Okta!) being blocked by anything consumer-facing.
    - commandersaki 1y ago
      Apple does precisely this for Apple account, you need to have a hardware attested passkey implementation to authenticate using passkey. Edit: forgot to add Apple account
      - FreakLegion 1y ago
        To authenticate to what? I have a few dozen people using passkeys on macOS without attestation, but I'll admit none of them are logging into "Apple".
      - FreakLegion 1y ago
        To your edit: I suppose this is strictly true, but it's relevant that Apple's own devices satisfy the attested hardware requirement. These are the same devices you need to have a full-fledged Apple account in the first place. That's more Apple doing Apple things than anything to do with passkeys, but it is indeed an example of not being able to use KeyPassXC. Will there be more than epsilon cases like that? I still don't think so, for what seem like obvious market reasons.
        commandersaki 1y ago
        Will there be more than epsilon cases like that? I anticipate banks, enterprise sso login, etc. doing this.
varjolintu 1y ago
FYI: If you export your Bitwarden vault as plain JSON, passkeys are included in plain-text too. So, it works similar to KeePassXC.
wbl 1y ago
That's the whole point of this exercise. If export is possible it's not secure against local compromise in the way that's needed.
- tzs 1y ago
  That's not quite correct. This can easily be seen by simply considering that the people who developed the passkey standard are also developing a passkey import/export standard which is nearly done and implementations are appearing in the field already. For example Apple's Passwords app on MacOS/iOS/iPadOS 26 now supports export and import of passkeys to/from other apps that support that standard. I don't know if any other apps have yet actually released such support.
- josephcsible 1y ago
  The point of passkeys is to protect against phishing and password reuse. You can't protect against local compromise, even if your passkeys are stored in something like a YubiKey, because once you log in to your bank with your hardware-backed passkey, the malware on your computer could use the session you started to transfer all of your money out of your account.
  - ngrilly 1y ago
    That’s why most banks ask you to approve transactions with an explicit reauthentication.
    - josephcsible 1y ago
      Then the malware will just wait until you want to do something legitimate that needs that, and then swap it out for its own thing.
  - wbl 1y ago
    But it can't maintain that compromise. That's important.
- AlexandrB 1y ago
gowld 1y ago
> because they allow you to export your passkeys because they allow you to export your passkeys in plaintext, for easy stealing. "Information wants to be free" should not apply to passwords!
- josephcsible 1y ago
  But open-source programs can always be modified to do that, so that's a terrible reason to ban open-source passkey managers. And besides, you shouldn't be forbidden from doing things with your own data just because they're unwise.

FreakLegion 1y ago

Tim Cappalli is thoroughly misguided throughout that discussion, but he's not threatening anything. Okta lets users require attestation, but it will never, ever force attestation on anyone.

josephcsible 1y ago
The specific part that I consider a threat is "which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations".
- FreakLegion 1y ago
  Sorry, to clarify: Okta is not for our purposes a relying party and won't do anything to force attestation on relying parties. The second bit of what he wrote is ambiguous, but charitably, could simply mean "I used to argue against requiring attestation, but now I'm not sure". Which is fine, since he has absolutely no pull when it comes to how Okta's product works (and to be fair, I don't think he implied otherwise or even mentioned Okta).
jauntywundrkind 1y ago
Tim's not threatening, but he is saying quite clearly that sites on the internet (Relying Parties) might just not accept Passkeys from KeePassXC: > The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations). Tim's talking the reality of KeePassXC and the reality is that this specification is being built in a way where the user is fundamentally out of control. Where the industry at large has total control over your material, gets to say how you can store your keys, and will refuse you credential managers that they don't like. The proposed Credential Exchange Protocol draft also does not allow you to backup your key. A credential manager will only Export the key to another credential manager service, across public endpoints on the internet. Never transiting the user's control. So you have to trust your credential manager that they actually will let you export your credentials, to someone you can trust, at a future point in time. There's an issue open for this, but no real hope this ever gets better. https://github.com/fido-alliance/credential-exchange-feedback/issues/24 https://github.com/fido-alliance/credential-exchange-feedbac... Passkeys seem designed to never be trustable by users. There's always some online service somewhere holding your materials that governments will be able to legally strongarm the service into getting access to. You won't be able to Export when you need it. The security people seem intent on making sure computers are totally controlled by corporations and governments, in the worst ways. The top post is right. https://news.ycombinator.com/item?id=45737608 https://news.ycombinator.com/item?id=45737608
- FreakLegion 1y ago
  Correct, individual sites could make that choice. They won't, but they could. (Love the mention in the linked comment of Netflix and Disney, two services that don't even support proper MFA.) We're completely on the same side, to be clear. I just have zero fear of KeePassXC (which I sometimes use with Okta!) being blocked by anything consumer-facing.
  - commandersaki 1y ago
    Apple does precisely this for Apple account, you need to have a hardware attested passkey implementation to authenticate using passkey. Edit: forgot to add Apple account
    - FreakLegion 1y ago
      To authenticate to what? I have a few dozen people using passkeys on macOS without attestation, but I'll admit none of them are logging into "Apple".
    - FreakLegion 1y ago
      To your edit: I suppose this is strictly true, but it's relevant that Apple's own devices satisfy the attested hardware requirement. These are the same devices you need to have a full-fledged Apple account in the first place. That's more Apple doing Apple things than anything to do with passkeys, but it is indeed an example of not being able to use KeyPassXC. Will there be more than epsilon cases like that? I still don't think so, for what seem like obvious market reasons.
      - commandersaki 1y ago
        Will there be more than epsilon cases like that? I anticipate banks, enterprise sso login, etc. doing this.

varjolintu 1y ago

FYI: If you export your Bitwarden vault as plain JSON, passkeys are included in plain-text too. So, it works similar to KeePassXC.

wbl 1y ago

That's the whole point of this exercise. If export is possible it's not secure against local compromise in the way that's needed.

tzs 1y ago
That's not quite correct. This can easily be seen by simply considering that the people who developed the passkey standard are also developing a passkey import/export standard which is nearly done and implementations are appearing in the field already. For example Apple's Passwords app on MacOS/iOS/iPadOS 26 now supports export and import of passkeys to/from other apps that support that standard. I don't know if any other apps have yet actually released such support.
josephcsible 1y ago
The point of passkeys is to protect against phishing and password reuse. You can't protect against local compromise, even if your passkeys are stored in something like a YubiKey, because once you log in to your bank with your hardware-backed passkey, the malware on your computer could use the session you started to transfer all of your money out of your account.
- ngrilly 1y ago
  That’s why most banks ask you to approve transactions with an explicit reauthentication.
  - josephcsible 1y ago
    Then the malware will just wait until you want to do something legitimate that needs that, and then swap it out for its own thing.
- wbl 1y ago
  But it can't maintain that compromise. That's important.
AlexandrB 1y ago

gowld 1y ago

> because they allow you to export your passkeys because they allow you to export your passkeys in plaintext, for easy stealing. "Information wants to be free" should not apply to passwords!

josephcsible 1y ago
But open-source programs can always be modified to do that, so that's a terrible reason to ban open-source passkey managers. And besides, you shouldn't be forbidden from doing things with your own data just because they're unwise.