4 ms·

https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994299617 https://github.com/keepassxreboot/keepassxc/issues/10407#iss... > You absolute

by shmerl 2y ago

https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994299617 https://github.com/keepassxreboot/keepassxc/issues/10407#iss... > You absolutely should be preventing users from being able to copy a private key! Huh? This is dumb. Users should be able to do whatever they want with their private keys. Looks like the post in on point about the push to take away control from the user. This is an anti-feature that should not be sneakily accepted as a security feature. When DRM-like stuff is shoved on the user in the name of security, it turns into the means to control the users by whoever makes those decisions for them. This should always be opposed. Having requirements like "users should not be allowed to do X" stinks to extreme.

hooverd 2y ago
Later down thread, this bit honestly reads like a threat. > 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).
amluto 2y ago
I disagree. Not necessarily in principle, but because there is no good way for a passkey app to distinguish between a competent user and a malicious actor pretending to be a competent user. Passkeys are, in a sense, very very dangerous — with passwords, everyone knows that a password can be compromised, and any competent security system needs to tolerate passwords getting compromised. But passkeys (and TOTP secrets and such) are treated as long term secrets. If a website enrolls a passkey supposedly attached to an Apple keychain, then that website would like to be able to trust that a compromise of the Apple account that is subsequently recovered will not result in a persistent compromise of a passkey that predates the compromise and recovery. If a passkey can have its private key exported, by anyone at all, then this property is lost. I do not want access even to my own passkey private keys! I certainly don’t love having a few gatekeepers in charge, but the protocol (currently?) does not really support a good alternative. And doing better is hard!
- shmerl 2y ago
  Passkeys are advertised as more convenient form of private / public keys approach. So how is that any different from other usage of private keys which are considered long term secrets? Incompetent users can compromise them now too. It doesn't mean it should be easy to do, but it's also completely unacceptable to make a requirement like "users are forbidden to access their private keys". > by anyone at all What do you mean by anyone at all? By the owner of the private key. Not by anyone.
  - amluto 2y ago
    > What do you mean by anyone at all? By the owner of the private key. Not by anyone. If I log into my computer and turn my private key into a plaintext blob, as a file or a Python object or something on a USB stick or a QR code that I photograph, then anyone who happens to have compromised my computer at the time has my public key, too. Even if I subsequently fix the compromise, they still have my public key. I do not want this to happen.
    - csande17 2y ago
      IMO one of the biggest issues with the Passkey spec is that it doesn't provide a way to automatically rotate credentials. The entire security model relies on Apple/Google/[insert name of nonprofit they end up allowing through the DRM gates to avoid antitrust suits] being completely infallible, forever.
    - shmerl 2y ago
      That's why normally private keys (like when used with ssh for example) are paired with something like a passphrase that should offer an additional layer of protection. But still, you (the owner of the private key) can access it. You should keep both your key and your passphrase secret. Not sure what passkeys are doing about it, but I still don't see any valid reason for the owner not to have full access to the key. If someone has sufficient access to your computer (like being able to keylog and stuff) - it's somewhat late to worry about keys being compromised.
- socksy 2y ago

by shmerl 2y ago

hooverd 2y ago

Later down thread, this bit honestly reads like a threat. > 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).

amluto 2y ago

I disagree. Not necessarily in principle, but because there is no good way for a passkey app to distinguish between a competent user and a malicious actor pretending to be a competent user. Passkeys are, in a sense, very very dangerous — with passwords, everyone knows that a password can be compromised, and any competent security system needs to tolerate passwords getting compromised. But passkeys (and TOTP secrets and such) are treated as long term secrets. If a website enrolls a passkey supposedly attached to an Apple keychain, then that website would like to be able to trust that a compromise of the Apple account that is subsequently recovered will not result in a persistent compromise of a passkey that predates the compromise and recovery. If a passkey can have its private key exported, by anyone at all, then this property is lost. I do not want access even to my own passkey private keys! I certainly don’t love having a few gatekeepers in charge, but the protocol (currently?) does not really support a good alternative. And doing better is hard!

shmerl 2y ago
Passkeys are advertised as more convenient form of private / public keys approach. So how is that any different from other usage of private keys which are considered long term secrets? Incompetent users can compromise them now too. It doesn't mean it should be easy to do, but it's also completely unacceptable to make a requirement like "users are forbidden to access their private keys". > by anyone at all What do you mean by anyone at all? By the owner of the private key. Not by anyone.
- amluto 2y ago
  > What do you mean by anyone at all? By the owner of the private key. Not by anyone. If I log into my computer and turn my private key into a plaintext blob, as a file or a Python object or something on a USB stick or a QR code that I photograph, then anyone who happens to have compromised my computer at the time has my public key, too. Even if I subsequently fix the compromise, they still have my public key. I do not want this to happen.
  - csande17 2y ago
    IMO one of the biggest issues with the Passkey spec is that it doesn't provide a way to automatically rotate credentials. The entire security model relies on Apple/Google/[insert name of nonprofit they end up allowing through the DRM gates to avoid antitrust suits] being completely infallible, forever.
  - shmerl 2y ago
    That's why normally private keys (like when used with ssh for example) are paired with something like a passphrase that should offer an additional layer of protection. But still, you (the owner of the private key) can access it. You should keep both your key and your passphrase secret. Not sure what passkeys are doing about it, but I still don't see any valid reason for the owner not to have full access to the key. If someone has sufficient access to your computer (like being able to keylog and stuff) - it's somewhat late to worry about keys being compromised.
socksy 2y ago