Short description: Bitwarden fully implements zero knowledge - i.e. the secret data is encrypted on the client side before uploaded to the Bitwarden servers and during sync.
At the moment “The FIDO allicance” together with Bitwarden and others are working on the above mentioned CXP and CXF specifications which when implemented will make it possible to switch/migrate ones passkeys from one ‘Credential Provider’ to a different credential provider. That could for example be from Proton Pass to Bitwarden. And that in itself is a great thing to prevent lock-in to a credential provider.
During such a migration the exporting credential provider creates a list of credentials in the CXF format, sends the data to the importing credential provider as described in the CXP specification. The importing credential provider now reads the credentials from the CXF formatted data and populates the end-user vault.
This means that during building the list of credentials at the exporting side in the CXF format and reading the list of credentials at the importing side both the exporting credential provider and the importing credential provider will access to the unprotected private keys of the passkey entries.
Because of that the there is no “Zero Knowlege” at least during the migration phase from one provider to the other, as both credential providers as described will have access to the unencrypted private keys
If my understanding is correct I would think there should be an additional step during the export and the import of the entries (particularly the private keys). A possible solution could be that the end-user is involved in both the import and export phase in a way that the end-user via / in the client software (of the exporting credential provider) is prompted to specify a passphrase specifically for the migration process and that passphrase should then be used to encrypt the private keys before they are added to the CXF data. The corresponding action should then be implemented at the importing process - the end-user should now be prompted by the client software of the importing credential provider and now specify the passphrase which the user specified during the export phase. At this point the client software has access to the private keys and is now able to upload the entries to the importing credential provider encrypted via the usual routines (in Bitwarden: With the master password). This means that the providers at no point of the migration have access to the unencrypted private key.
I’m of course aware that this only implements zero knowledge with credential providers that actually implement zero knowledge (like Bitwarden). But even in the scenario where you want to migrate passkeys either from/to Bitwarden at least Bitwarden still would be able to keep the zero knowledge.
I don’t think that Google Password Manager uses Zero Knowledge, but 1Password and Proton Pass (and I’m sure others as well) use zero knowledge when storing secrets on their servers.
Since Bitwarden (Anders Åberg and Oscar Hinton) is one of the active participants in the CXF/CXP project I hope this post perhaps can help address this problem
Hi @flatalk, I’m Anders. As you’ve already noted, I work at Bitwarden and I also work in the technical working group inside FIDO that came up with CXP and CXF. Just mentioning it for future readers.
I’m always happy to see interest in CX and help clear up any misunderstandings
Because of that the there is no “Zero Knowlege” at least during the migration phase from one provider to the other, as both credential providers as described will have access to the unencrypted private keys
I think you have a misunderstanding here. All implementations out there today (iOS and soon Android) are purely taking place on the users device, with the end user involved. At no point can Bitwardens server observe your unencrypted data, or transfer it to 1Password.
One could make the point that your operating system can see your unencrypted data while it’s in memory and transfering between the two apps, but that’s always the case. If your device is malicious, it can read anything you can read.
But I think you perhaps (but pls see my last paragraph here) are misunderstanding what I’m trying to say. I am totally aware that right now / today the private keys of the passkeys only are unencrypted on the client, not at your servers or anywhere else
My concern is in the future / that later on - at the time where CXP and CXF actually are implemented and in use by credential providers like Bitwarden and others. At that point during the migration the private key will be unprotected while the exporting credential provider is building the CXF structure / adding the private keys in the CXF structure. And the same goes for the importing credential provider - after decrypting the received CXF structure the importing credential provider has at this point access to the unprotected private key so it can add it to the end-user vault.
All this unless you are telling me that the building and encryption of the CXF structure and the decryption and import of the CXF structure actually happens purely at the client side / client app only, and not at the credential provider servers - in that I have misunderstood the planned implementation. In that case I did misunderstood the situation!
Please understand: I’m not talking about how it works today “All implementations out there today …“).
I’m only talking about the “near future” (Q1 of 2026 if I should guess - at the time when CXF and CXP are actively being used) - and at that time how the zero knowledge can be upheld when passkeys are migrated from one credential provider to another (for example between Bitwarden, 1Password or others, which is the whole purpose of CXP and CXF - transfer between different credential providers). Neither the CXP or CXF standards are finished or implemented today, so therefore I’m referring to the future, not as things are today / now.
Therefore my question to Anders @andersaberg is still open
I would also like to add that Anders @andersaberg wrote :
“At no point can Bitwardens server observe your unencrypted data, or transfer it to 1Password.”
So therefore I had to assume that Anders misunderstood my point, since the whole purpose of CXF / CXP is to enable credential provides like Bitwarden, 1Password and others to transfer data between them).
(Pls refer to Credential Exchange Protocol , paragraph “1.1 Scope”)
My concern is in the future / that later on - at the time where CXP and CXF actually are implemented and in use by credential providers like Bitwarden and others
Right, so that’s the misunderstanding. Bitwarden (and Apple, and Dashlane) has implemented CX. You can fire up iOS and use it today.
CX only works client side. That’s the way it was defined. It’s never transmitted through our servers because we can never see your credentials and we want to keep it that way. Zero-knowledge, that is.
CX = Credential Exchange, including both Protocol + Format.
And yes, the goal of CX is to allow the transfer of credentials between providers… but all transport channels are client side only. And if a non client-side transport would be introduced, it would feature E2E encryption to make sure it stays zero knowledge.
Presumably the scheme works along the following lines:
flowchart
F[Bitwarden servers]-->A[Bitwarden encrypted data on user device] --> B[Bitwarden decrypted data on user device] --> C[CXF/CXP on user device] --> D[1Password decrypted data on user device] --> E[1Password encrypted data on user device]-->G[1Password servers]
Thank you for elaborating on that - I must admit that I couldn’t find the information that the encryption and decryption / CX*-handling to a big part is done by the clients when I looked at the Credential Exchange Protocol working draft and the Credential Exchange Format proposed standard. When I read statements like “passing credentials between credential providers“ I understood that like those “credential providers” were actually for example Bitwarden and 1Password - on the server / company side.
I of course believe you ! So thank you very much again for explaining and confirming my thought that if it were client side including the encryption/decryption zero trust still could work.
I would however think that the fact about that it happens client-side could perhaps been mentioned explicitly in the above mentioned CXF and CXP documents. I didn’t read them word for word, but I also didn’t just “fly over” them.
If it actually is mentioned I apologize for not spotting that
But I am glad to have learned that the zero trust still is upheld when using CXF/CXP - that is very good to hear.
Keep up the good work (both Bitwarden and CX*) - and have a nice evening
Anders’ explanation “did do the trick” - the explicit explanation of the fact that the encryption / decryption actually happens on the clients (like you diagram)
