5 ms·

How do you even ban something like KeypassXC given that it is open source and any end user could basically edit KeypassXC and bypass a ban? Edit: Reading one o

How do you even ban something like KeypassXC given that it is open source and any end user could basically edit KeypassXC and bypass a ban? Edit: Reading one of those issues it sounds like they want the keys stored in an encrypted way, is that too much to ask for? I dont care about viewing it but it shouldnt be stored in a plain easy to open JSON.

digiown 9mo ago
That's the thing, they can't yet. They are proposing an attestation scheme. I'm not sure the details are out yet, but the authenticator would presumably use one of the hardware security mechanisms (like a TPM bound key) to "certify" its own authenticity along with the challenge. This will effectively ban all open-source implementations, and end user freedom if widely adopted. Fortunately for us it seems like Apple isn't cooperating here for now, and without Apple signing on, it wouldn't get anywhere.
- altairprime 9mo ago
  Attestation is not inherently incompatible with open source. Code signing keys are perfectly compatible with open source. You don’t ever commit them to the repo, if they’re even accessible to you at all (vs. in an HSM), and everyone can distinguish your official releases from forks and mods because yours are signed with your key. Attestation is incompatible with having the authority conferred upon upstream automatically inherited by all forks thereof. If you want your fork to have the same authority as upstream, you have to apply for that authority to be recognized and make your case that it deserves that. This is the problem with attestation: that it reintroduces human reputation authorities into the Wild West of computing. If you’re going to argue successfully against attestation, you’ll need to focus on the actual problem rather than the distraction of source code licensing. The same attestation would be necessary whether the app you’re modding is closed source, open source, or a PICO-8 cartridge image: when attestation is in play, everyone knows you’re running a modded version, and they may choose to deny you service over that. That’s the problem attestation poses, and why arguments against passkeys fail so spectacularly to gain traction, by focusing on “open source” (irrelevant) rather than e.g. “right to be modify without being refused service”.
  - digiown 9mo ago
    > right to be different without being refused service You can check my comment history to see the arguments I have against attestation. That's exactly what I argue. It's not an open source problem, it's a user freedom problem, and this is exactly why corporate interests like "open source", but not "free software". Open source is freedom-agnostic: you can use it to hurt users just fine. The current iterations of remote attestation is especially egregious, because most of it is the government itself or an entity the government forces you to deal with (banks). In general I believe remote attestation is actually fine, so long as it does not transcend ownership boundaries. A company can use it to ensure its own colo servers aren't tampered with, for example. But an external authority shouldn't be able to exert control over something I own. In particular there should be no expectation that my device is "trustworthy" in any way at all. Anything else ends privacy and freedom as we know it.
    - altairprime 9mo ago
      > this will effectively ban all open-source implementations This is the only point where I differ: it will effectively ban most implementations, with no regard for whether they’re open source, closed source, or private. 1Password could be open-sourced tomorrow and continue being an approved implementation, no sweat, because they can be trusted not to disguise and release “export your passkeys as plaintext at rest” functionality — but in today’s market, there are certainly a thousand implementations (whether source or not) that died on the vine, whose sole purpose would have been to circumvent that one restriction, far more than there are implementations that are willing to genuinely try to uphold it. Glad someone else is fighting for repurposeability — but there is no universal answer for how to balance privacy, freedom, and security. It’s something people have to decide for themselves, and just as my phone has an “highest security, lower convenience” mode for certain scenarios, so too I wish it had a “no security, total modifiability” mode for other scenarios. (Even if that denied me app store access, and I would demand that it wipe pre-existing passkeys from the HSM when I enabled freedom mode, or else it’s just an uncontrolled attack vector!)
      - digiown 9mo ago
digiown 9mo ago
It's an export format. The storage is always encrypted with the database key. And you can view the key directly anyway just like you can view passwords, and copy it from there.
politelemon 9mo ago
> ask for That's the key difference. If it mattered, they would make it part of the spec, not threaten a ban. That's even more concerning, there is a central group of people who get to decide who can and cannot use Passkeys.
Dedime 9mo ago
Well, it's stored in an encrypted way - in the encrypted password database. Much like a password, everyone already knows not to share a passkey. But also like a password, as the owner, sometimes I want to look at it!
- frizlab 9mo ago
  Genuine question: why?
  - TomasEkeli 9mo ago
    it's mine.
    - cferry 9mo ago
      Exactly. It's beyond me that people have to fight to use what they own as they please, or even are asked to justify themselves...
  - mzajc 9mo ago
    Genuine answers: - because I like backing up my data, especially credentials - because I like looking at how things work in practice - you are on a website called hacker news after all
hypeatei 9mo ago
> they want the keys stored in an encrypted way, is that too much to ask for Well, they are encrypted but the issue is talking about exports. The maintainer of KeepassXC already mentions the issue with that: portability. A backup of such sensitive data (a password manager) is going to be stored somewhere secure (to the user) already. Why would you encrypt the contents and add another layer of complexity that other tools may not be able to handle? I want to be able to rely on those backups in the future and copy paste them around manually if needed. It's user choice, put simply. A specification committee should never be deciding what a user does with their data, period. The security maximalist is always going to advocate for the most secure thing but most of the time that's not practical or friendly to humans.

digiown 9mo ago

That's the thing, they can't yet. They are proposing an attestation scheme. I'm not sure the details are out yet, but the authenticator would presumably use one of the hardware security mechanisms (like a TPM bound key) to "certify" its own authenticity along with the challenge. This will effectively ban all open-source implementations, and end user freedom if widely adopted. Fortunately for us it seems like Apple isn't cooperating here for now, and without Apple signing on, it wouldn't get anywhere.

altairprime 9mo ago
Attestation is not inherently incompatible with open source. Code signing keys are perfectly compatible with open source. You don’t ever commit them to the repo, if they’re even accessible to you at all (vs. in an HSM), and everyone can distinguish your official releases from forks and mods because yours are signed with your key. Attestation is incompatible with having the authority conferred upon upstream automatically inherited by all forks thereof. If you want your fork to have the same authority as upstream, you have to apply for that authority to be recognized and make your case that it deserves that. This is the problem with attestation: that it reintroduces human reputation authorities into the Wild West of computing. If you’re going to argue successfully against attestation, you’ll need to focus on the actual problem rather than the distraction of source code licensing. The same attestation would be necessary whether the app you’re modding is closed source, open source, or a PICO-8 cartridge image: when attestation is in play, everyone knows you’re running a modded version, and they may choose to deny you service over that. That’s the problem attestation poses, and why arguments against passkeys fail so spectacularly to gain traction, by focusing on “open source” (irrelevant) rather than e.g. “right to be modify without being refused service”.
- digiown 9mo ago
  > right to be different without being refused service You can check my comment history to see the arguments I have against attestation. That's exactly what I argue. It's not an open source problem, it's a user freedom problem, and this is exactly why corporate interests like "open source", but not "free software". Open source is freedom-agnostic: you can use it to hurt users just fine. The current iterations of remote attestation is especially egregious, because most of it is the government itself or an entity the government forces you to deal with (banks). In general I believe remote attestation is actually fine, so long as it does not transcend ownership boundaries. A company can use it to ensure its own colo servers aren't tampered with, for example. But an external authority shouldn't be able to exert control over something I own. In particular there should be no expectation that my device is "trustworthy" in any way at all. Anything else ends privacy and freedom as we know it.
  - altairprime 9mo ago
    > this will effectively ban all open-source implementations This is the only point where I differ: it will effectively ban most implementations, with no regard for whether they’re open source, closed source, or private. 1Password could be open-sourced tomorrow and continue being an approved implementation, no sweat, because they can be trusted not to disguise and release “export your passkeys as plaintext at rest” functionality — but in today’s market, there are certainly a thousand implementations (whether source or not) that died on the vine, whose sole purpose would have been to circumvent that one restriction, far more than there are implementations that are willing to genuinely try to uphold it. Glad someone else is fighting for repurposeability — but there is no universal answer for how to balance privacy, freedom, and security. It’s something people have to decide for themselves, and just as my phone has an “highest security, lower convenience” mode for certain scenarios, so too I wish it had a “no security, total modifiability” mode for other scenarios. (Even if that denied me app store access, and I would demand that it wipe pre-existing passkeys from the HSM when I enabled freedom mode, or else it’s just an uncontrolled attack vector!)
    - digiown 9mo ago

digiown 9mo ago

It's an export format. The storage is always encrypted with the database key. And you can view the key directly anyway just like you can view passwords, and copy it from there.

politelemon 9mo ago

> ask for That's the key difference. If it mattered, they would make it part of the spec, not threaten a ban. That's even more concerning, there is a central group of people who get to decide who can and cannot use Passkeys.

Dedime 9mo ago

Well, it's stored in an encrypted way - in the encrypted password database. Much like a password, everyone already knows not to share a passkey. But also like a password, as the owner, sometimes I want to look at it!

frizlab 9mo ago
Genuine question: why?
- TomasEkeli 9mo ago
  it's mine.
  - cferry 9mo ago
    Exactly. It's beyond me that people have to fight to use what they own as they please, or even are asked to justify themselves...
- mzajc 9mo ago
  Genuine answers: - because I like backing up my data, especially credentials - because I like looking at how things work in practice - you are on a website called hacker news after all

hypeatei 9mo ago

> they want the keys stored in an encrypted way, is that too much to ask for Well, they are encrypted but the issue is talking about exports. The maintainer of KeepassXC already mentions the issue with that: portability. A backup of such sensitive data (a password manager) is going to be stored somewhere secure (to the user) already. Why would you encrypt the contents and add another layer of complexity that other tools may not be able to handle? I want to be able to rely on those backups in the future and copy paste them around manually if needed. It's user choice, put simply. A specification committee should never be deciding what a user does with their data, period. The security maximalist is always going to advocate for the most secure thing but most of the time that's not practical or friendly to humans.