7 ms·

KeePassXC Issue: [Passkeys] should never be exported in clear text

34 points by danShumway 3y ago

danShumway 3y ago
> I've changed the title back to my original text to stay on the record here that this is a really bad idea and I strongly recommend you temporarily disable this feature or at a minimum require file protection/encryption. > To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406). This cements a lot of criticism I have of Passkeys as a standard. As of now, KeePassXC is the only implementer I'm aware of that makes it easy to export passkeys. There is no standardized import/export mechanism from any other provider and no timeline of when that will happen other than "we're working on it." I've been told before that Open implementations of Passkey providers would come and we wouldn't have to worry about the spec being largely proprietary, locked-down implementations. But with an Open implementation that serves the user in allowing them to export and import that data, there's pushback that the implementation shouldn't exist, and suggestion that even an encrypted export should be a "temporary minimum bar". So it does not seem to me that the Open implementations matter. In particular, the threat of blocking KeePassXC by relying parties should be interpreted as a threat against Open implementations that deviate from the spec (even though I know Tim has good intentions and does not intend it that way). ---- > Passkey provider certification, migration, spec development, etc is part of the FIDO Alliance. Please reach out directly and I we can talk about how to get you engaged in the discussion We are long past the point where these conversations should be happening completely in the open. The continued lack of portability in the Passkey ecosystem is only made worse by the closed and private nature of the conversation surrounding it. As time continues to tick on and on and more and more articles suggest that users move over to what is, frankly, an incomplete specification with a fatal flaw, it becomes harder and harder to see the continued delay of real universal portability guarantees as a temporary setback. At the very least, these kinds of conversations should serve as a warning against assuming that Open Source providers of Passkeys are necessarily going to be able to paper over the real flaws in the spec, particularly around data portability, attestation requirements, and hardware requirements. Half-baked promises are a large part of Passkey advocacy. With KeePassXC allowing real export and direct user access to encrypted keys, we get to see the actual industry reaction when an org tries to fulfill those half-baked promises. To be clear, I do not think that Tim Cappalli is operating in anything other than good faith and that he wants anything other than the best for the product. This is not Tim being evil, but the FIDO spec and approach to standardizing Passkeys is necessarily flawed and results in these kinds of threatening outcomes and requirements on user agents regardless of the intentions of any individual members or advocates. You don't have to think less of Tim Cappalli or think that he's operating in bad faith to understand that this kind of rhetoric is still threatening. ---- Frankly, I'm done with the "wait and see" approach to the FIDO alliances constant foot-dragging on portability and their continuous indication through their actions that they do not see portability as a user requirement. Timelines, open discussions, open calls for feedback, and open implementations. Talk is so ridiculously cheap.
frankjr 3y ago
>> Nothing stopping people from copy pasting values around. > You absolutely should be preventing users from being able to copy a private key! A what now?
timmyc123 3y ago
>> "Frankly, I'm done with the "wait and see" approach to the FIDO alliances constant foot-dragging on portability and their continuous indication through their actions that they do not see portability as a user requirement. Timelines, open discussions, open calls for feedback, and open implementations. Talk is so ridiculously cheap." There was a public Authenticate Conference session today that talked about the status of the credential migration specification drafts. I believe it was recorded: https://authenticatecon.com/event/authenticate-virtual-summit-demystifying-passkey-implementations/ https://authenticatecon.com/event/authenticate-virtual-summi...
- danShumway 3y ago
  Looking forward to watching it if/when it's posted online. That being said, a tech conference "where are we" video recording is a far cry away from an Open standardization process. The lack of real details on this has been infuriating, especially given that Passkey advocates are pushing Passkeys for regular users and enterprise customers right now. Portability should be a blocking feature -- if it had been treated like an essential feature instead of a post-launch nice-to-have, we wouldn't still be waiting for an answer on it a year after people started raising these complaints. The lack of transparency allowed a lot of advocates to dismiss what were in retrospect extremely valid concerns about how portability was going to be handled. Advocates dismissed those concerns by talking about how the ecosystem was still young, this was all beta, solutions were coming. And then gradually the "beta" talk vanished, but the solutions never came -- it played out exactly as critics predicted. This and the attestation talk that I've seen around providers risks damaging Passkey adoption for years to come; it turns a technology that should be a clear and easy security win into an ideological fight about open standards and user control over their accounts and their identities -- none of that fight was necessary. It's wild to me how this kind of stuff has been handled; there is absolutely no excuse at all for these conversations to be happening behind closed doors. Tech conference talks are nice and I welcome getting any information at all about progress on portability. Genuinely, I am so hungry for even just a crumb of information about portability, I'll be very happy if that talk gets put online. But this is all a far cry from timelines, open discussions, open calls for feedback, or open implementations. Tech talks are not a standardization process. I mean, heck, step away from portability even. This Github issue drops the nugget that enterprise members of FIDO are now pushing for provider attestation, which would have massive implications for Passkey as an Open standard. That is a conversation that should be happening openly and publicly with public input through official forums or issue trackers. That is not a conversation that should be happening just amongst FIDO members, and it's absurd to learn about the existence of that conversation through an unrelated Github issue. But I'm just shouting into the void, I guess. The Github issue ends with "I will send you a dm/email". So that's another conversation that will be moved behind closed doors. Well, what's another year? We'll all just wait patiently while we're constantly told that we should be using what is today a locked down, proprietary ecosystem that is actively pushing back on Open implementations trying to solve the problems that the FIDO alliance either won't or can't currently address by threatening disqualification from the ecosystem. Of course, Open providers being threatened via attestation was another thing that I was told by advocates not to worry about, but whatever, we'll all just keep trusting people.
no_time 3y ago
>(…)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). What a nice guy… Basically saying do what we say or we will make the treacherous part of your device do it against your will.
- danShumway 3y ago
  I don't think that Tim meant it that way, but I do think it's an indication that attestation can be used that way. I think it's somewhat missing the point to say that Tim is being mean; Tim could be entirely supportive and this would still be a danger and would still be a risk that FIDO has to address and that it's currently ignoring. This is a spec issue. There are (as far as I can tell) no penalties or mechanisms to guard against businesses using attestation punitively to punish actors that deviate from the spec even when that deviation is in the interest of users. We are relying on corporate good will, and corporate good will is not something that ought to be relied on. Now, what that comment reveals is that there are multiple actors pushing to extend attestation to roaming keys and to have even fewer safeguards against excluding clients from the ecosystem. That's scary, and that's a much bigger problem than one person. When Apple zeroed out attestation requests for its roaming keys, I was told by multiple advocates that this meant that attestation would not be coming for roaming keys, and that attestation would never be used this way. After all, attestation was primarily intended (they told me) for regulatory compliance in industries that were primarily worried about device-bound keys. "What is Apple changes its mind" was dismissed as fearmongering. But here we see the danger of setting expectations about an ecosystem based on Apple deciding randomly not to do something. There was no public commitment from FIDO not to pursue additional attestation for roaming keys, and behind the scenes it looks like players calling for that attestation have more sway than advocates let on. So we end up with essentially a threat against implementations that deviate from the standard even when they are deviating in the clear interest of users. I don't think Tim meant it as a threat, if anything he was probably trying to be helpful. But it is still a threat regardless of the intention. And it's a threat because the ecosystem explicitly exposes tools to enable this kind of behavior. It's not a threat because of Tim, it's a threat because it's plausible. And it shouldn't be plausible. This is why attestation is dangerous without safeguards; and the FIDO alliance has completely ignored the need for safeguards. Maybe there are conversations that I'm not privy to -- there probably are. But from the outside, it looks like a lot of people hoping that Google and Apple and Netflix and your bank will all magically care about not locking users to hardware and will completely voluntarily choose not abuse attestation. And I'm sorry, that's just not in their nature to do. If the spec directly gives these companies tools to be abusive, then they're going to be abusive.
KingOfLechia 3y ago
Web Integrity failed so now they are trying to lock down the internet by refusing authentication to anyone not using "trusted" passkey implementation (eventually the only trusted implementation will be TPM with unmodified Windows/MacOS/Chrome OS/Android/iOS).

34 points by danShumway 3y ago

> I've changed the title back to my original text to stay on the record here that this is a really bad idea and I strongly recommend you temporarily disable this feature or at a minimum require file protection/encryption. > To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406). This cements a lot of criticism I have of Passkeys as a standard. As of now, KeePassXC is the only implementer I'm aware of that makes it easy to export passkeys. There is no standardized import/export mechanism from any other provider and no timeline of when that will happen other than "we're working on it." I've been told before that Open implementations of Passkey providers would come and we wouldn't have to worry about the spec being largely proprietary, locked-down implementations. But with an Open implementation that serves the user in allowing them to export and import that data, there's pushback that the implementation shouldn't exist, and suggestion that even an encrypted export should be a "temporary minimum bar". So it does not seem to me that the Open implementations matter. In particular, the threat of blocking KeePassXC by relying parties should be interpreted as a threat against Open implementations that deviate from the spec (even though I know Tim has good intentions and does not intend it that way). ---- > Passkey provider certification, migration, spec development, etc is part of the FIDO Alliance. Please reach out directly and I we can talk about how to get you engaged in the discussion We are long past the point where these conversations should be happening completely in the open. The continued lack of portability in the Passkey ecosystem is only made worse by the closed and private nature of the conversation surrounding it. As time continues to tick on and on and more and more articles suggest that users move over to what is, frankly, an incomplete specification with a fatal flaw, it becomes harder and harder to see the continued delay of real universal portability guarantees as a temporary setback. At the very least, these kinds of conversations should serve as a warning against assuming that Open Source providers of Passkeys are necessarily going to be able to paper over the real flaws in the spec, particularly around data portability, attestation requirements, and hardware requirements. Half-baked promises are a large part of Passkey advocacy. With KeePassXC allowing real export and direct user access to encrypted keys, we get to see the actual industry reaction when an org tries to fulfill those half-baked promises. To be clear, I do not think that Tim Cappalli is operating in anything other than good faith and that he wants anything other than the best for the product. This is not Tim being evil, but the FIDO spec and approach to standardizing Passkeys is necessarily flawed and results in these kinds of threatening outcomes and requirements on user agents regardless of the intentions of any individual members or advocates. You don't have to think less of Tim Cappalli or think that he's operating in bad faith to understand that this kind of rhetoric is still threatening. ---- Frankly, I'm done with the "wait and see" approach to the FIDO alliances constant foot-dragging on portability and their continuous indication through their actions that they do not see portability as a user requirement. Timelines, open discussions, open calls for feedback, and open implementations. Talk is so ridiculously cheap.

frankjr 3y ago

>> Nothing stopping people from copy pasting values around. > You absolutely should be preventing users from being able to copy a private key! A what now?

timmyc123 3y ago

>> "Frankly, I'm done with the "wait and see" approach to the FIDO alliances constant foot-dragging on portability and their continuous indication through their actions that they do not see portability as a user requirement. Timelines, open discussions, open calls for feedback, and open implementations. Talk is so ridiculously cheap." There was a public Authenticate Conference session today that talked about the status of the credential migration specification drafts. I believe it was recorded: https://authenticatecon.com/event/authenticate-virtual-summit-demystifying-passkey-implementations/ https://authenticatecon.com/event/authenticate-virtual-summi...

danShumway 3y ago
Looking forward to watching it if/when it's posted online. That being said, a tech conference "where are we" video recording is a far cry away from an Open standardization process. The lack of real details on this has been infuriating, especially given that Passkey advocates are pushing Passkeys for regular users and enterprise customers right now. Portability should be a blocking feature -- if it had been treated like an essential feature instead of a post-launch nice-to-have, we wouldn't still be waiting for an answer on it a year after people started raising these complaints. The lack of transparency allowed a lot of advocates to dismiss what were in retrospect extremely valid concerns about how portability was going to be handled. Advocates dismissed those concerns by talking about how the ecosystem was still young, this was all beta, solutions were coming. And then gradually the "beta" talk vanished, but the solutions never came -- it played out exactly as critics predicted. This and the attestation talk that I've seen around providers risks damaging Passkey adoption for years to come; it turns a technology that should be a clear and easy security win into an ideological fight about open standards and user control over their accounts and their identities -- none of that fight was necessary. It's wild to me how this kind of stuff has been handled; there is absolutely no excuse at all for these conversations to be happening behind closed doors. Tech conference talks are nice and I welcome getting any information at all about progress on portability. Genuinely, I am so hungry for even just a crumb of information about portability, I'll be very happy if that talk gets put online. But this is all a far cry from timelines, open discussions, open calls for feedback, or open implementations. Tech talks are not a standardization process. I mean, heck, step away from portability even. This Github issue drops the nugget that enterprise members of FIDO are now pushing for provider attestation, which would have massive implications for Passkey as an Open standard. That is a conversation that should be happening openly and publicly with public input through official forums or issue trackers. That is not a conversation that should be happening just amongst FIDO members, and it's absurd to learn about the existence of that conversation through an unrelated Github issue. But I'm just shouting into the void, I guess. The Github issue ends with "I will send you a dm/email". So that's another conversation that will be moved behind closed doors. Well, what's another year? We'll all just wait patiently while we're constantly told that we should be using what is today a locked down, proprietary ecosystem that is actively pushing back on Open implementations trying to solve the problems that the FIDO alliance either won't or can't currently address by threatening disqualification from the ecosystem. Of course, Open providers being threatened via attestation was another thing that I was told by advocates not to worry about, but whatever, we'll all just keep trusting people.

no_time 3y ago

>(…)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). What a nice guy… Basically saying do what we say or we will make the treacherous part of your device do it against your will.

danShumway 3y ago
I don't think that Tim meant it that way, but I do think it's an indication that attestation can be used that way. I think it's somewhat missing the point to say that Tim is being mean; Tim could be entirely supportive and this would still be a danger and would still be a risk that FIDO has to address and that it's currently ignoring. This is a spec issue. There are (as far as I can tell) no penalties or mechanisms to guard against businesses using attestation punitively to punish actors that deviate from the spec even when that deviation is in the interest of users. We are relying on corporate good will, and corporate good will is not something that ought to be relied on. Now, what that comment reveals is that there are multiple actors pushing to extend attestation to roaming keys and to have even fewer safeguards against excluding clients from the ecosystem. That's scary, and that's a much bigger problem than one person. When Apple zeroed out attestation requests for its roaming keys, I was told by multiple advocates that this meant that attestation would not be coming for roaming keys, and that attestation would never be used this way. After all, attestation was primarily intended (they told me) for regulatory compliance in industries that were primarily worried about device-bound keys. "What is Apple changes its mind" was dismissed as fearmongering. But here we see the danger of setting expectations about an ecosystem based on Apple deciding randomly not to do something. There was no public commitment from FIDO not to pursue additional attestation for roaming keys, and behind the scenes it looks like players calling for that attestation have more sway than advocates let on. So we end up with essentially a threat against implementations that deviate from the standard even when they are deviating in the clear interest of users. I don't think Tim meant it as a threat, if anything he was probably trying to be helpful. But it is still a threat regardless of the intention. And it's a threat because the ecosystem explicitly exposes tools to enable this kind of behavior. It's not a threat because of Tim, it's a threat because it's plausible. And it shouldn't be plausible. This is why attestation is dangerous without safeguards; and the FIDO alliance has completely ignored the need for safeguards. Maybe there are conversations that I'm not privy to -- there probably are. But from the outside, it looks like a lot of people hoping that Google and Apple and Netflix and your bank will all magically care about not locking users to hardware and will completely voluntarily choose not abuse attestation. And I'm sorry, that's just not in their nature to do. If the spec directly gives these companies tools to be abusive, then they're going to be abusive.

KingOfLechia 3y ago

Web Integrity failed so now they are trying to lock down the internet by refusing authentication to anyone not using "trusted" passkey implementation (eventually the only trusted implementation will be TPM with unmodified Windows/MacOS/Chrome OS/Android/iOS).