5 ms·

> as soon as passkeys started popping up the endgame became clear That's why I'm 100% against passkeys. I'll never use them and I'll make sure nobody I know do

> as soon as passkeys started popping up the endgame became clear That's why I'm 100% against passkeys. I'll never use them and I'll make sure nobody I know does. They're just a lock-in mechanism.

kleiba 1y ago
For someone who hasn't spent any time thinking about that matter, could you please elaborate your point?
- progval 1y ago
  "Passkeys are incompatible with open-source software" https://www.smokingonabike.com/2025/01/04/passkey-marketing-is-lying-to-you/ https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
  - fragmede 1y ago
    Then how come KeePassXC has them?
    - indigo945 1y ago
      The linked blog post explains it. The spec can be implemented by open source software, but the upcoming (or now current?) update to the spec enables attestation, that is, it allows the auth provider to cryptographically verify which implementation the client is using. Under this scheme, auth providers can simply choose to no longer support open source implementations like KeePassXC, and since the spec authors have already claimed that KeePassXC is "non-compliant" because it doesn't ask for a PIN on every auth request, it seems likely that that would happen.
      - tadfisher 1y ago
        Attestation is dead outside of corporate environments. Apple will not implement it except through MDM.
        freedomben 1y ago
        Isn't PAT apple implementing attestation for everyone?
        GoblinSlayer 1y ago
        Apple will implement it.
        tadfisher 1y ago
        Source? That is surprising news.
      - fragmede 1y ago
        Yes but it seems like KeyPassXC could just ask for PIN on every auth request to satisfy that requirement, without having to close their source.
        reddalo 1y ago
        What if I don't want KeyPassXC to ask me for a PIN every time? I can modify its source code and nobody can stop me.
        pbhjpbhj 1y ago
        Then your version of KeyPass will not be signed and won't pass TPM checks and so the banking app will refuse to run unless you open the signed version?
        yencabulator 1y ago
        Which leads us back full circle to "Passkeys are incompatible with open-source software" from https://news.ycombinator.com/item?id=45090297 https://news.ycombinator.com/item?id=45090297
- dingaling 1y ago
  Imagine using ssh-keygen, but it locks the private key in a vendor-managed secure enclave. You can't copy it, export it, rename it or do anything wth it.
  - tadfisher 1y ago
    I don't just imagine it, I do it, by using gpg-agent as my ssh-agent and using the private key generated by a Yubikey. Another way is to use tpm2-tools so only your laptop running your own signed boot chain can use the key. It is desirable to lock private key material in a physical thing that is hard to steal. You can choose not to do this, and that's fine. Hardware attestation is dead because Apple refuses to implement it, so no one can force you to.
    - oigursh 1y ago
      Can you explain your motivation around gpg-agent and yubikey little more, please? So the private key can't be copied elsewhere?
      - tadfisher 1y ago
        Yes, that's the motivation. These days I would explore the TPM option, but I'm worried that has less legal teeth than a physical key if I'm in a law enforcement situation. There's also practicality; I really, really don't want to tell my boss that TSA or whoever had access to the company git repositories and databases for X minutes or hours, and that's sidestepped by checking a bag with the Yubikey (wastes their time) or mailing it to the destination (needs a warrant).
lucideer 1y ago
"Passkeys" is a new brand name slapped on an older open, interoperable technology, so it's difficult for me to be "against passkeys" as they haven't fundamentally changed anything. Before the branding they were known as FIDO2 "discoverable credentials" or "resident keys". Two things have changed with the rebrand: 1. A lot of platforms are adopting support for FIDO2 resident keys. This is good actually. 2. A lot of large companies have set themselves up as providers of FIDO2 resident keys without export or migration mechanisms. This is the vendor lock-in part (no export feature), but it's not a feature of the underlying tech itself. Fwiw FIDO are actively working on some standard for exporting/importing keys so that's something. If you want to use passkeys without lockin, just use Bitwarden or KeepPassXC - they all have full support. Or you can also store a limited number of passkeys on your FIDO2-compatible hardware key like Yubikey or the open-source Nitrokeys.
- breakingcups 1y ago
  Except the FIDO Alliance is trying to pressure KeepassXC to remove exporting passkeys in an open format: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407
  - aw1621107 1y ago
    > trying to pressure KeepassXC to remove exporting passkeys in an open format I'm not sure that's an entirely accurate representation of the request? At least from a quick skim the claimed issue is being able to export keys in plaintext. For example, from the issue author: > I strongly recommend you temporarily disable this feature or at a minimum require file protection/encryption. And later: > > Besides, determined advanced users could just write code to decrypt the kdbx file and extract the passkeys anyway. > That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text. > I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here. To me that doesn't sound like they're requiring a proprietary format. Something like AES encrypted JSON sounds like it'd work as well, and that sounds pretty "open" to me?
fragmede 1y ago
Do you recommend a password manager to everyone you know? What's the adoption rate?
- reddalo 1y ago
  I honestly suggest using Mozilla Firefox built-in password manager, it's enough for most people.
- pmontra 1y ago
  As a data point: when non technical friends of mine complain against password I tell them to use a password manager. The adoption rate is zero, probably because they don't even know what a password manager is, except the remember password / fill in password feature of their browser. The best I saw, from a not entirely non technical person is passwords on sheets of paper.
- walthamstow 1y ago
  I have tried repeatedly to get my wife to use the family 1Password account for things we will both need, with minimal success. She is reasonably technical, she writes SQL, but she just won't do it.
  - mlrtime 1y ago
    1Password is completely broken in android. I have barely a 50% success rate with it filling in passwords, I'm usually copy/pasting back and forth. If there were anything better and as easy to use as Chrome, I'd switch.

> as soon as passkeys started popping up the endgame became clear That's why I'm 100% against passkeys. I'll never use them and I'll make sure nobody I know does. They're just a lock-in mechanism.

kleiba 1y ago

For someone who hasn't spent any time thinking about that matter, could you please elaborate your point?

progval 1y ago
"Passkeys are incompatible with open-source software" https://www.smokingonabike.com/2025/01/04/passkey-marketing-is-lying-to-you/ https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
- fragmede 1y ago
  Then how come KeePassXC has them?
  - indigo945 1y ago
    The linked blog post explains it. The spec can be implemented by open source software, but the upcoming (or now current?) update to the spec enables attestation, that is, it allows the auth provider to cryptographically verify which implementation the client is using. Under this scheme, auth providers can simply choose to no longer support open source implementations like KeePassXC, and since the spec authors have already claimed that KeePassXC is "non-compliant" because it doesn't ask for a PIN on every auth request, it seems likely that that would happen.
    - tadfisher 1y ago
      Attestation is dead outside of corporate environments. Apple will not implement it except through MDM.
      - freedomben 1y ago
        Isn't PAT apple implementing attestation for everyone?
      - GoblinSlayer 1y ago
        Apple will implement it.
        tadfisher 1y ago
        Source? That is surprising news.
    - fragmede 1y ago
      Yes but it seems like KeyPassXC could just ask for PIN on every auth request to satisfy that requirement, without having to close their source.
      - reddalo 1y ago
        What if I don't want KeyPassXC to ask me for a PIN every time? I can modify its source code and nobody can stop me.
        pbhjpbhj 1y ago
        Then your version of KeyPass will not be signed and won't pass TPM checks and so the banking app will refuse to run unless you open the signed version?
        yencabulator 1y ago
        Which leads us back full circle to "Passkeys are incompatible with open-source software" from https://news.ycombinator.com/item?id=45090297 https://news.ycombinator.com/item?id=45090297
dingaling 1y ago
Imagine using ssh-keygen, but it locks the private key in a vendor-managed secure enclave. You can't copy it, export it, rename it or do anything wth it.
- tadfisher 1y ago
  I don't just imagine it, I do it, by using gpg-agent as my ssh-agent and using the private key generated by a Yubikey. Another way is to use tpm2-tools so only your laptop running your own signed boot chain can use the key. It is desirable to lock private key material in a physical thing that is hard to steal. You can choose not to do this, and that's fine. Hardware attestation is dead because Apple refuses to implement it, so no one can force you to.
  - oigursh 1y ago
    Can you explain your motivation around gpg-agent and yubikey little more, please? So the private key can't be copied elsewhere?
    - tadfisher 1y ago
      Yes, that's the motivation. These days I would explore the TPM option, but I'm worried that has less legal teeth than a physical key if I'm in a law enforcement situation. There's also practicality; I really, really don't want to tell my boss that TSA or whoever had access to the company git repositories and databases for X minutes or hours, and that's sidestepped by checking a bag with the Yubikey (wastes their time) or mailing it to the destination (needs a warrant).

lucideer 1y ago

"Passkeys" is a new brand name slapped on an older open, interoperable technology, so it's difficult for me to be "against passkeys" as they haven't fundamentally changed anything. Before the branding they were known as FIDO2 "discoverable credentials" or "resident keys". Two things have changed with the rebrand: 1. A lot of platforms are adopting support for FIDO2 resident keys. This is good actually. 2. A lot of large companies have set themselves up as providers of FIDO2 resident keys without export or migration mechanisms. This is the vendor lock-in part (no export feature), but it's not a feature of the underlying tech itself. Fwiw FIDO are actively working on some standard for exporting/importing keys so that's something. If you want to use passkeys without lockin, just use Bitwarden or KeepPassXC - they all have full support. Or you can also store a limited number of passkeys on your FIDO2-compatible hardware key like Yubikey or the open-source Nitrokeys.

breakingcups 1y ago
Except the FIDO Alliance is trying to pressure KeepassXC to remove exporting passkeys in an open format: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407
- aw1621107 1y ago
  > trying to pressure KeepassXC to remove exporting passkeys in an open format I'm not sure that's an entirely accurate representation of the request? At least from a quick skim the claimed issue is being able to export keys in plaintext. For example, from the issue author: > I strongly recommend you temporarily disable this feature or at a minimum require file protection/encryption. And later: > > Besides, determined advanced users could just write code to decrypt the kdbx file and extract the passkeys anyway. > That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text. > I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here. To me that doesn't sound like they're requiring a proprietary format. Something like AES encrypted JSON sounds like it'd work as well, and that sounds pretty "open" to me?

fragmede 1y ago

Do you recommend a password manager to everyone you know? What's the adoption rate?

reddalo 1y ago
I honestly suggest using Mozilla Firefox built-in password manager, it's enough for most people.
pmontra 1y ago
As a data point: when non technical friends of mine complain against password I tell them to use a password manager. The adoption rate is zero, probably because they don't even know what a password manager is, except the remember password / fill in password feature of their browser. The best I saw, from a not entirely non technical person is passwords on sheets of paper.
walthamstow 1y ago
I have tried repeatedly to get my wife to use the family 1Password account for things we will both need, with minimal success. She is reasonably technical, she writes SQL, but she just won't do it.
- mlrtime 1y ago
  1Password is completely broken in android. I have barely a 50% success rate with it filling in passwords, I'm usually copy/pasting back and forth. If there were anything better and as easy to use as Chrome, I'd switch.