[Passkeys] should never be exported in clear text #10407
Comments
|
@matthewmummert5 you put it better than I did earlier today. See #10411 |
droidmonkey
changed the title
|
Is there any public conversation about this topic? It would be interesting to see different suggestions and possible conclusions. Of course we are going to implement the standard when it's available. |
|
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).
That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text. I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.
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 (https://timcappalli.me). |
timcappalli
changed the title
There are hundreds of encryption options to choose from. Sure, we can choose AES-256-GCM. To what end? If no other product implements that encryption option, then exporting becomes worthless for portability. Define the standard first (just pick one or two), then publish it. There is no need to spend time debating the choice, plenty of great options to choose from. |
|
You've defined an arbritrary file format and schema, so they can only be imported back to another KeePassXC instance. So why not pick an encryption option that is also KeePassXC specific to offer some protection in the short term? |
|
Or just don't export? We are arguing over user choice. Nothing stopping people from copy pasting values around. Sounds like the minimal export standard for portability needs to be defined as well. |
You absolutely should be preventing users from being able to copy a private key!
This is all part of the 2+ year workstream. Please reach out if KeepassXC would like to contribute! |
As a (somewhat tech-savvy) user, this sounds ridiculous to me. If I have a private key on a dedicated file somewhere, I can copy it just fine where I need/want to. Why should that be any different with a private key that's stored inside my passwords database, which I own and control? I know enough not to share the private key, nor to place it anywhere unsafe. But for that, a warning is enough. At most, don't export the private key by default, and require an extra action to do so. |
|
Like I said in the other thread, at the end of the day, it is your product and your choice. I am providing advice as someone who has worked very hard to bootstrap this ecosystem while balancing security and usability. 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).
Asking you to put basic protections in place and collaborate with the ecosystem/industry is hardly "anti-user-choice mentality". Anyway, I've given my advice on the public record. I welcome any future collaboration for the advancement of the ecosystem as we try to eliminate credential phishing from the web. |
If you don't mind posting (perhaps in a new issue) any of these you come across, I would love to watch or read the presentation. We are always trying to balance the trifecta of security, user expectation, and developer capacity. I have skimmed through and corresponded with several people regarding the webauthn/passkey spec. My personal opinion is that it is incredibly challenging to "get right" and have full compliance. Implementations can be way off and still function properly. To me, that is a ding on the spec, not the developer(s). We try hard to be as compliant as possible, but webauthn spec projects a lot of principles as requirements (ie, shoulds are written as shalls). There are also many many problems with the RP side of implementations that causes a lot of "is it me or them" situations. This is mainly due to obtuse or absent errors. |
|
@droidmonkey I'll be discussing this in my Identiverse 2024 presentation on passkeys. You can watch last year's presentation at https://www.youtube.com/watch?v=BsvA9VdlGKA&list=PLNPzoRgqH5el892rMcHBQYVDbePx99J5E&index=1. |
|
As one of the contributors to the spec, I can certainly empathize with the sentiment that the spec can be challenging to implement.
Please share some more detailed feedback if you can spare the time (doesn't have to be here). |
|
FYI: Even Bitwarden's CLI tool allows extracting the private key, and every other data there is: |
"Someone else is doing bad things too" isn't the greatest argument... Bitwarden is actively engaged in the industry discussion and standards work around passkey migration. |
Wasn't meant to be an argument. Just to point out that if you have full access to your data, the private key is impossible to protect. |
@timcappalli I will send you a dm/email. Thank you. |
I don't think that's true. Plaintext formats are easy to convert. You can do it by hand if you must. Binary formats are much harder to convert, let alone encrypted ones. The best we can do now is to use a standard container format such as PKCS#12, but then again, this should be at least a suggested part of the standard and an accepted solution across the industry. |
I am not a KeepassXC developer and am speaking as a long time user. anti-feature : (software) Functionality originally intended as a feature, but perceived as a bug, annoyance, or infringement of freedoms by some or even most users. The very definition of what Tim is demanding are anti-features. Basic protections should not abridge the freedoms of users, including freedom 0 ["the freedom to run the program as you wish, for any purpose"]; which in my mind clearly states that user-choice is everything. Having said that, enhancing the export process to allow users additional options on what and how things are exported are good ideas. |
|
I interpret Tim's tickets as follows: He is communicating with the KeePassXC project about what perceives to be the consensus on the passkey specification among the individuals involved in its development. He specifically points out the export of private keys and user verification (UV) versus user presence (UP) as potential issues. Also the passkey protocol apparently allows the other party to reject specific implementations because it contains some form of self identification. He predicts that in the future, many websites are likely to decline implementations that are widely viewed as non-compliant with the specification. My understanding is that he is essentially advocating for certain aspects here because it would benefit the passkey ecosystem as a whole if a password manager popular among FOSS enthusiasts, like KeePassXC, does not face widespread blocking by major websites. While I greatly value user freedom, which is why I use software like KeePassXC, what use is an implementation of passkeys with higher user freedom if it is deemed non-compliant and doesn't work in many places? (I assume the question about impersonating a spec compliant implementation's ID was more of a devil's advocate thing, and isn't seriously considered here) |
|
@samuelspiza There's no point to adding antifeatures to satisfy such websites. They'd just block KeePassXC anyway, under the argument that even though it meets all of their demands, since it's FOSS, someone could compile a modified version that didn't. (As for impersonating a spec compliant implementation, that's not possible because of another antifeature: attestation.) |
|
@matthewmummert5 I really appreciate your comments, they are fair and very relevant. I actually did not appreciate the ongoing general challenges of passkeys prior to these discussions and the conversation has helped me discover this fact. This is a complex problem deserving of a complex solution. The current solution (spec) is complex, but only technically. There are broader social challenges not addressed that involve differences between corporate environments and personal environments. |
|
I also really don't want to derail this conversation, it's clear that an issue tracker for KeepassXC is not the correct place to have an extended conversation about provider blocking. That being said, I will push back a little bit on the labeling of these problems as primarily political and not technical. The reason we're having a conversation about providers being blocked is because the FIDO Alliance is considering extending attestation to cover roaming keys. Today, blocking providers over roaming keys is (as far as I can tell) not ultimately possible. I'm assuming that nothing has changed and Apple still zeros out the provider identification field for roaming keys? So any provider looking to avoid being blocked can just mimic Apple's behavior. I actually agree with Apple's position on this (assuming the position hasn't changed) that attestation does not make sense from a security perspective for passkeys that are not device-bound -- from a security perspective, guarantees about the system for a key that is designed to live on multiple devices across multiple systems, each of which might have their own vulnerabilities and phishing risks, is kind of like bolting the barn door after the cows have all already left. And yes, how providers get blocked has political implications. Most technical decisions ultimately have political implications. But whether or not providers can be blocked is a technical decision that the FIDO Alliance will ultimately decide to support or not to support. If Apple publicly commits to continuing to zero out identification when services request roaming keys and if Apple commits to not implementing attestation guarantees for roaming keys issued from Apple devices, then in practice it's not clear to me that Open Source providers can be blocked regardless of whether or not they're spec-compliant. But presumably, that's not going to happen; presumably Apple is going to start handling requests differently (if it doesn't already). From this conversation it sounds like the FIDO Alliance is leaning towards making it possible for services to block roaming keys from specific providers. That's disappointing and I would love to advocate that this is the wrong decision (both from a political and from a pure security perspective) but assuming that nobody's mind can be changed on this, there are also both technical and political decisions that the FIDO Alliance could make that would mitigate some of the potential harms that are absolutely going to come out of blocking providers and requiring certification -- at the very least, the FIDO Alliance could introduce some of those mitigations into the spec. I'm not an implementer and I'm not an expert on WebAuthentication. I'm looking at this purely from a user perspective. Where would be the best place to have that conversation? @droidmonkey elsewhere brings up a great point about the lack of error messages when a provider is blocked; I would take that a step further and suggest that the full list of blocked/allowed services should be publicly declared at some point as part of the protocol between providers and services and services that refuse to publish publicly which providers they block/allow should be considered to be breaking spec. As a user I would like to be able to tell which providers any given service supports and what options I have if I want to use that service -- and that's something that the spec could facilitate by making the exchange of that information a normal part of registering with any provider . So I think there's a long conversation that needs to happen about the implications of blocked providers for multiple parts of the specification. But also much more importantly, there's also a conversation that should happen about how attestation and certification could potentially be used to guarantee at least some user freedoms and could be used to build safeguards against services abusing attestation. As long as we're going down the path of certification, can certification include requirements that guarantee at least some user freedoms? But this specific Github issue is absolutely not the best place to have that conversation. Is there a better place? Are these issues that could be brought up on the WebAuthn Github repo possibly? https://github.com/w3c/webauthn I would love to get involved in this conversation to some small degree even if I'm not an implementer. But I don't want to intrude into spaces where that's not appropriate or where it would just be a distraction. |
@matthewmummert5 I would welcome some correction on this if I'm giving bad information because I don't have Apple devices to check with and I'm not an expert on WebAuthentication. But I don't believe this would be the case? My understanding is that Apple has released a browser extension at least for Chrome to allow use of Apple-generated keys within other browsers on Mac, and the extension communicates with Apple's built-in provider on Mac/iOS (https://developer.chrome.com/blog/passkeys-on-icloud-keychain/). I'm not sure what the status is for Firefox, and this doesn't mean a service couldn't fingerprint for Safari anyway (they could do that today with normal passwords); but because Apple keys can be generated and used from other browsers, restricting to Safari would lock out Apple users who are using Chrome on Mac. iOS requires roaming keys to be synced to iCloud (correct me if I'm wrong and that's changed) and they get automatically synced between Apple devices; so my understanding is that users who own both an iOS device and a Mac are going to be signing into services using the same keys across both devices. Maybe some services are OK with losing those users or fielding tech support questions from them? Or maybe they decide, "we'll just fingerprint both browsers." But that feels like a large tradeoff to make and at some point as a business you have to decide just how complicated you want your codebase for logging into your website to be. I also suspect that if this was a public commitment and zeroing out identity was seen as spec compliant, fingerprinting might get harder over time as other providers begin to follow Apple's example. I saw some talk when I first learned about Apple doing this that Apple's behavior was more spec-compliant than filling in the "identification" field, and there were people suggesting that implementations on Android/Windows should be doing the same in order to be spec-compliant. Whether those people knew what they were talking about, I don't know. Given that Tim hasn't filed a bug complaining that KeePassXC identifies itself when generating a roaming key, I would guess no. :) But that's a decision that the FIDO Alliance can make; they could specify that providers should not identify themselves when generating roaming keys. Fingerprinting is always a concern for blocking devices/browsers, but this would move verification away from the OS and onto the browser level, and would require services to deviate from the spec in order to do that fingerprinting -- in an environment where they would be forced to maintain fingerprints from multiple browsers on multiple OSes with multiple combinations of extensions. I suspect building a list of what browsers/combos of major providers to allow would be difficult, especially if passkeys continue to expand beyond browsers to be used for other forms of authentication. Ideally passkeys should eventually be used for API authentication, sign-in for native apps, etc... I have seen calls to get webAuthentication working without a dependence on Javascript. None of that makes fingerprinting impossible, but it should make it a harder sell for businesses. I suspect it would become increasingly more and more difficult to lock off every API exposed for signing up for a service and to justify to product managers caring about those locks. But I could be wrong! Unfortunately, you're also right that Apple doesn't seem outright hostile to attestation in other parts of iOS, and I believe it's looked into some level of attestation support in Safari around captcha bypasses (although I'm not sure how that ended up working out). And if Tim's suggestion that there is movement on attestation for roaming keys is correct, then... I mean, I don't know what's going on in Apple or what position the company currently has about that debate, but presumably they'll go along with what the spec says and they'll implement attestation if the spec tells them to. That just comes down to... if the FIDO Alliance is determined to do it, then they're determined to do it, and then the conversation just shifts to harm reduction and trying to figure out if attestation/certification can also be used on behalf of users and not just on behalf of services -- and I do think there are decisions the Alliance could make within the WebAuthn specification that would help with that. But this is all me talking from the outside, I'm not privy to any of the conversations that may or may not have happened about that. |
|
This whole blocking talk reads like the FIDO alliance is trying very hard to alienate tech savvy users who do not want to stick their entire digital existence (the ability to login) into apples or googles newest device. |
|
Newly released passkeys for Proton Pass also supports export, although the details are missing from the docs: |
|
For anyone else coming across this issue, the recent FIDO virtual meetup included a brief talk about the plans for passkey portability that's now available online: https://www.youtube.com/watch?v=Mje6J2IMRTY I have some questions about the talk and about some of the details, but this issue isn't the right place to bring them up. The important things that are relevant to this issue are: A) this is more of a migration than an export standard; I don't think this is something that can be implemented by developers ahead of the spec dropping. With the exception of the pre-shared key auth flow (see 18:11), the auth flows all seem to require both providers be installed at the same time and to communicate with each other. So I don't think this will be as simple as changing the export format, there's bidirectional communication that needs to happen that needs to be standardized. B) The timeline for a spec drop is the 2025, which (opinion me) seems to be too far away for implementers right now to wait for while they are currently rolling out implementations for real users for real-world critical applications. It's not my place to say, but I would suggest that the FIDO alliance should be releasing interim standards for how to handle export, because I don't think it's reasonable to ask applications or users to wait until 2025 to be able to handle this kind of migration. We're seeing that apps right now are interested in compatibility, and users obviously are interested in this as well. If the FIDO alliance has criteria for how encrypted exports should be handled or created -- even just basic standards -- it would be good to hear them because I don't think that implementers can (or should) wait for 2025 to start supporting export/import. Regardless, it's good to finally get some kind of update about portability, although I am still hungry for actual details and I would still love to know what the best place is to ask those questions. |
I wonder how the "backup and long-term storage" part is gonna be played with this, as the virtual meetup mentions. Maybe we have to wait for the specification draft to be released so we can dig to this. |
I'm thinking that's likely to be the case, but I have been following up and trying to get some questions answered (https://groups.google.com/a/fidoalliance.org/g/fido-dev/c/3fzN3H6cwFY). I am realizing that I forgot to hit reply-all on my response, so I'll forward that back to the group so it's public. I was also curious about how backup would work if the keys to decrypt weren't handed off to the user and if the programs needed to communicate with each other as part of the migration. Relevant quote to that:
My take from that is that user-controlled export is sort-of planned to be supported? Or at least allowed. The actual requirements may be fuzzier than I took away from the talk itself. But I'm still waiting for some clarification on that to make sure I understood the response, and to try and understand how this differs from a normal encrypted export in the case where a user controls the keys and can supply them to an aribtrary importer later in the future. Once I have more information I'll make sure to summarize what I've been told and put it online somewhere. But probably the V1 draft will provide more clarity. |
Could this discussion be held in a public medium, instead of an invite-only one? |
This comment was marked as off-topic.
This comment was marked as off-topic.
droidmonkey
changed the title
|
Closing in favor of #11363 |
droidmonkey
changed the title
and others
Overview
Passkeys should never be allowed to be exported in clear text.
There is significant work going on across the industry on a secure migration protocol for credentials like passkeys. Please consider removing this feature temporarily or at a minimum mandate protection of the with a key or secret of sufficient length.
Please reach out if you're interested in collaborating on these backup/export/migration protocols with other passkey providers in the industry (https://timcappalli.me).
The text was updated successfully, but these errors were encountered: