6 ms·

> An attempt by an open source password manager to provide export of private keys was ruled insecure and should not be supported. The name of the issue reveals

> An attempt by an open source password manager to provide export of private keys was ruled insecure and should not be supported. The name of the issue reveals the actual problem: "should never be exported in clear text". If the export was encrypted with a passphrase in a standard format, then there would be no issue. It's specifically doing it in plain text that causes consternation. Of course, in practice it doesn't make much of a difference when users are incapable of choosing secure passwords, let alone passphrases. But requiring exports to be encrypted is the least one can do to maintain a degree of security while still allowing exports. > For many years already, people lose access to their Google account every day and can never regain it. Google is well known for terminating accounts without stating any reasons. With that comes the loss of access to your data. In this case, you also lose your credentials for third-party websites. In practice this is frequently already true. Many sites require an email to sign up. Whenever you attempt to log in on a new device, they require you to type in a code sent to your email. Without access to your email, you cannot sign in.

tuckerman 1y ago
Where is the line exactly though? If the password manager put up a big red notice when trying to export in plain text is that enough? If not, why not? I am sympathetic to the intent but the words of Patrick Henry come to mind too often in conversations like these. I love passkeys and appreciate secure defaults but I feel strongly that user freedom is a more fundamental requirement than preventing phishing attacks.
- AndrewDucker 1y ago
  Because many end users will ignore that. And this technology is set up to prevent end users from hurting themselves, even if that constrains technologically capable ones.
  - tuckerman 1y ago
    My values are such that it’s inappropriate for a few folks at companies and random consortiums to make that decision on behalf of all society. If KeepassXC wanted to enforce that world view for the safety of their users, it’s their right, but this is essentially a threat of blacklisting an entire password manager for adding a feature demanded by their users (who likely predominantly used by technically savvy users at that).
    - palata 1y ago
      > but this is essentially a threat of blacklisting an entire password manager I don't think they could blacklist the entire password manager. They can't prevent it from giving you a username/password... Refusing some passkeys is, to me, similar to refusing passwords that are too short. It may make sense to only accept passkeys backed by a secure element. Companies already force their employees to use a specific MFA app, because they don't want to trust any app out there.
      - tuckerman 1y ago
        What if websites start adopting passkey-only with instead of offering a username/password option? We could live in a world where services are inaccessible unless you use Google/Apple/1Password/etc as your password manager
        palata 1y ago
        > We could live in a world where services are inaccessible unless you use Google/Apple/1Password/etc as your password manager If services want to force you to use whatever authentication they want, they can. That's what already happens with any service that is serious about security. In big companies, you have to use their authenticator app, their mail client, their messaging system, etc. Often it's Microsoft software. Banks have their own systems, etc. Now, if a service allows you to use a passkey instead of their own 2FA app, I'd say it's a win. I'm happier using a security key than a Microsoft authenticator. But if they give up on using their own app, they may well set conditions on the passkey you use. And that condition may be "it has to be backed by a trusted secure element". You won't be able to use a passkey that's deemed unsecure just like right now, you already are not able to just use a weak password with some services. Again, I'm not saying that being forced to depend on TooBigTech is not a problem: it very much is. But nothing says that services have to do it with passkeys: they could (and should) also accept secure passkeys that don't come from TooBigTech. But they still have a say in what they find secure or not, and that part is okay.
        1y ago
AlotOfReading 1y ago
But requiring exports to be encrypted is the least one can do to maintain a degree of security while still allowing exports. Why is the protocol dictating the user's security model? I can see why particular applications wouldn't choose to support insecure exports (and would even agree with that), but I genuinely don't understand why the protocol is dictating that an application can't allow users the freedom to choose their own security model. The same issue exists with HSTS, which I've found infuriating when the system is obviously wrong and I have to resort to absurd workarounds as a user because the application is handicapped from giving me an "ignore this" button. Moreover, "just" password protecting a file isn't allowed by the draft CXP standard (https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html#sctn-response-modes https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html#...), you have to use a HPKE scheme where the key exchange is manually orchestrated by the user to export offline. I get it from a security perspective, but that's stupid.
- tadfisher 1y ago
  The other side of this is the Relying Party, a.k.a. the website operator that is relying on the user's password manager to be decently secure and resistant to phishing. Otherwise, why ditch passwords plus 2FA?
  - AlotOfReading 1y ago
    The website already has guarantees against phishing because those are enforced by the managers. What's prevented is the snooping case of taking an export and cloning it without the exporting manager being involved. This is essentially indistinguishable from many legitimate use cases like archival or access to deceased relatives' credentials, which users might want regardless of the website's preferences.
    - tadfisher 1y ago
      > The website already has guarantees against phishing because those are enforced by the managers. There is no such guarantee if credential-stealing malware can export your private key material in plaintext!
NoGravitas 1y ago
The spec participant here is also saying that encrypting your export file is a "temporary minimum". Personally, I think that requiring a passphrase for some standard symmetric encryption on the export is fine. Plenty of free and privacy-preserving apps I use (Signal, Aegis) do this. The real issue is that there is no guarantee over the medium term that even this will continue to be allowed.

tuckerman 1y ago

Where is the line exactly though? If the password manager put up a big red notice when trying to export in plain text is that enough? If not, why not? I am sympathetic to the intent but the words of Patrick Henry come to mind too often in conversations like these. I love passkeys and appreciate secure defaults but I feel strongly that user freedom is a more fundamental requirement than preventing phishing attacks.

AndrewDucker 1y ago
Because many end users will ignore that. And this technology is set up to prevent end users from hurting themselves, even if that constrains technologically capable ones.
- tuckerman 1y ago
  My values are such that it’s inappropriate for a few folks at companies and random consortiums to make that decision on behalf of all society. If KeepassXC wanted to enforce that world view for the safety of their users, it’s their right, but this is essentially a threat of blacklisting an entire password manager for adding a feature demanded by their users (who likely predominantly used by technically savvy users at that).
  - palata 1y ago
    > but this is essentially a threat of blacklisting an entire password manager I don't think they could blacklist the entire password manager. They can't prevent it from giving you a username/password... Refusing some passkeys is, to me, similar to refusing passwords that are too short. It may make sense to only accept passkeys backed by a secure element. Companies already force their employees to use a specific MFA app, because they don't want to trust any app out there.
    - tuckerman 1y ago
      What if websites start adopting passkey-only with instead of offering a username/password option? We could live in a world where services are inaccessible unless you use Google/Apple/1Password/etc as your password manager
      - palata 1y ago
        > We could live in a world where services are inaccessible unless you use Google/Apple/1Password/etc as your password manager If services want to force you to use whatever authentication they want, they can. That's what already happens with any service that is serious about security. In big companies, you have to use their authenticator app, their mail client, their messaging system, etc. Often it's Microsoft software. Banks have their own systems, etc. Now, if a service allows you to use a passkey instead of their own 2FA app, I'd say it's a win. I'm happier using a security key than a Microsoft authenticator. But if they give up on using their own app, they may well set conditions on the passkey you use. And that condition may be "it has to be backed by a trusted secure element". You won't be able to use a passkey that's deemed unsecure just like right now, you already are not able to just use a weak password with some services. Again, I'm not saying that being forced to depend on TooBigTech is not a problem: it very much is. But nothing says that services have to do it with passkeys: they could (and should) also accept secure passkeys that don't come from TooBigTech. But they still have a say in what they find secure or not, and that part is okay.
        1y ago

AlotOfReading 1y ago

But requiring exports to be encrypted is the least one can do to maintain a degree of security while still allowing exports. Why is the protocol dictating the user's security model? I can see why particular applications wouldn't choose to support insecure exports (and would even agree with that), but I genuinely don't understand why the protocol is dictating that an application can't allow users the freedom to choose their own security model. The same issue exists with HSTS, which I've found infuriating when the system is obviously wrong and I have to resort to absurd workarounds as a user because the application is handicapped from giving me an "ignore this" button. Moreover, "just" password protecting a file isn't allowed by the draft CXP standard (https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html#sctn-response-modes https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html#...), you have to use a HPKE scheme where the key exchange is manually orchestrated by the user to export offline. I get it from a security perspective, but that's stupid.

tadfisher 1y ago
The other side of this is the Relying Party, a.k.a. the website operator that is relying on the user's password manager to be decently secure and resistant to phishing. Otherwise, why ditch passwords plus 2FA?
- AlotOfReading 1y ago
  The website already has guarantees against phishing because those are enforced by the managers. What's prevented is the snooping case of taking an export and cloning it without the exporting manager being involved. This is essentially indistinguishable from many legitimate use cases like archival or access to deceased relatives' credentials, which users might want regardless of the website's preferences.
  - tadfisher 1y ago
    > The website already has guarantees against phishing because those are enforced by the managers. There is no such guarantee if credential-stealing malware can export your private key material in plaintext!

NoGravitas 1y ago

The spec participant here is also saying that encrypting your export file is a "temporary minimum". Personally, I think that requiring a passphrase for some standard symmetric encryption on the export is fine. Plenty of free and privacy-preserving apps I use (Signal, Aegis) do this. The real issue is that there is no guarantee over the medium term that even this will continue to be allowed.