←back to thread

184 points Bogdanp | 1 comments | | HN request time: 0s | source
Show context
bmandale ◴[] No.45105669[source]
> 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.

replies(3): >>45105880 #>>45106093 #>>45117111 #
AlotOfReading ◴[] No.45106093[source]

    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#...), 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.

replies(1): >>45106347 #
tadfisher ◴[] No.45106347[source]
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?
replies(1): >>45106784 #
AlotOfReading ◴[] No.45106784{3}[source]
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.
replies(1): >>45107041 #
tadfisher ◴[] No.45107041{4}[source]
> 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!

replies(1): >>45107255 #
1. AlotOfReading ◴[] No.45107255{5}[source]
If the malware can orchestrate the managers, why wouldn't they simply use that power to orchestrate the offline export as they were going to do anyway? The RP ID makes the process a bit noisy, but it doesn't seem to change the fundamental vulnerability for the credential owner.