Import account-restricted encrypted JSON export into vault after changing master password and rotating keys?

[joeysmith]

Hi all, painted myself in some corner I guess.

What happened:

-signed out of all sessions
-made encrypted .json-backup (from webvault I was logged into I think it was)
-purged vault
-changed master key
-rotated keys
-tried to import encrypted .json backup
-failed, because the backup has a different password than the current vault
-I do have the old master password

Question: is any attempt to get the data back futile?

If there is a chance: how? I read about a decryptor, but that seems to be Linux and command line…

Thanks a lot in advance, Joey

[Nail1684]

@joeysmith Welcome to the forum!

Could you clarify if the encrypted JSON export you made is:

• account restricted or

• password protected

?

[joeysmith]

Hello Nail, thanks for your reply.

I chose on export ‘encrypted json’ as format. And I am almost certain I checked the box that restricted re-import to the vault it came from.

Kind regards, Joey

[Nail1684]

@joeysmith

And I am almost certain I checked the box that restricted re-import to the vault it came from.

Then, unfortunately, I think here is your answer:

(–> Encrypted Exports | Bitwarden)

[joeysmith]

Thank you very much for looking into this Nail, greatly appreciated. I will have to consider my vault lost forever.

This ‘warning’ image you show: I did not see such a warning when rotating my keys. But probably/possibly I did not pay proper attention. Anyhow, it should be displayed when rotating keys that this is an action that renders encrypted exports useless. I’ll check soon if that is the case or not.

What I’ll do now is go back into an (quite an) old disk-image that has the desktop-application of Bitwarden in it. Hopefully I can make an export from the vault in that image (unencrypted this time ).

Thanks once more for your kind help, Joey

[Nail1684]

@joeysmith

What I’ll do now is go back into an (quite an) old disk-image that has the desktop-application of Bitwarden in it. Hopefully I can make an export from the vault in that image (unencrypted this time ).

If you do that, make sure to disconnect that device from the internet! Otherwise you will get logged out (which wipes the local vault data) when you try to unlock that desktop app.

(–> My Master Password | Bitwarden)

[Nail1684]

@joeysmith

This ‘warning’ image you show: I did not see such a warning when rotating my keys. But probably/possibly I did not pay proper attention. Anyhow, it should be displayed when rotating keys that this is an action that renders encrypted exports useless. I’ll check soon if that is the case or not.

I just tested it with a test account (that I already deleted again): the option itself has only a small question mark (when you click it, you land on that Help Site I linked before).

 

But/and as soon as you check that “Also rotate my account’s encryption key” option, the following warning message automatically pops up:

PS:

@joeysmith

Hopefully I can make an export from the vault in that image (unencrypted this time ).

If you write down the password you used, password-protected encrypted JSON exports are completely acceptable.

PPS: I now updated the title of this thread and included the info that it’s about an account-restricted export file.

[DenBesten]

@joeysmith

Anyhow, it should be displayed when rotating keys that this is an action that renders encrypted exports useless. I’ll check soon if that is the case or not.

In addition to what @Nail1684 included, there is also a warning when the account-restricted export is created (below).

The bigger lesson-to-learn is to have a backup of last resort that depends upon the least amount of technology possible. In my case, once every few backups, I create an unencrypted JSON and a CSV export. I can retrieve my passwords from either with something as simple as notepad. Then to mitigate the obvious risk, I keep the unencrypted exports exclusively on thumb drive(s) under lock and key. Those more paranoid than I have even been reputed to keep a paper copy.

[grb]

@joeysmith

-made encrypted .json-backup (from webvault I was logged into I think it was)
-purged vault
-changed master key
-rotated keys

As a lesson for other readers of this thread, it seems you made three unforced errors, the combined effect of which was to eliminate all access to your vault data:

1. Selected account-restricted export type.
2. Purged vault.
3. Rotated account encryption key.

If you had skipped any one of those three steps, you would still have access to your data today. The kicker is that all of those three of those actions were likely unnecessary or inadvisable.

I’m curious why you took such extreme steps (especially the purging of the vault and the rotation of the account encryption key). Was there a confirmed compromise of your Bitwarden account?

 

@joeysmith

What I’ll do now is go back into an (quite an) old disk-image that has the desktop-application of Bitwarden in it.

Do let us know how this works out for you. As already noted by @Nail1684, you should disconnect your computer from the internet before launching the Desktop app after restoring the disk image.

[kpiris (Kiko Piris)]

@grb

I’m curious why you took such extreme steps (especially the purging of the vault and the rotation of the account encryption key). Was there a confirmed compromise of your Bitwarden account?

I obviously can not answer this (since I’m not the OP). But I can see why an extra cautious/paranoid user could end up doing something like this:

• Your are going to perform an action that could spoil your vault (importing some file that you are not sure if it’s ok, for example).

• You decide to make a backup before performing that action.

  • Not wanting a clear text export written on the device’s disk, you choose the encrypted type
  • A password encrypted export has the inconvenience of having to generate a complex password and having to save it somewhere (a device’s disk is a not so secure option, paper is inconvenient, and also has other risks, etc.).
  • So you chose the encrypted method that seems more secure.

• You end up having to restore your vault.

• You decide that, it’s a good moment to change mp, and rotating a key can’t be a bad thing from a security perspective. You’ve read somewhere that this is a risky action, but your vault is in bad shape and you have to restore a backup anyway.

• Then you purge your vault and change mp (rotating the account’s encryption key). The order of these two actions doesn’t matter.

• Game over.

I know the consequences of that key rotation are documented in several places, but many users don’t read warnings (and some of those who read them, don’t fully understand them -I’m not implying this is OP’s case-).

Because It’s counterintuitive that an action that I do today (changing mp rotating the account’s encryption key) will affect the exports made in the (maybe distant) past.

Let me repeat myself: Bitwarden should remove this type of encrypted export.

[Nail1684]

@kpiris

Let me repeat myself: Bitwarden should remove this type of encrypted export.

… or at least make the password-protected encrypted JSON export the default/pre-defined choice… (of course, that wouldn’t prevent bad choices as effective as your request…)

[joeysmith]

Hi all, Nail, DenBesten, grb, Kiko Piris, thanks for all detailed reactions. Greatly appreciated. I got most of my vault back from the backup. Will describe the process. After I’ll address the other issues in your posts.

What I did to get part of my vault back:
-created an image of my current Windows-system
-restored an old image of my system, lo and behold there was a working instance of Bitwarden in there
-disconnected from internet
-logged in to my local vault
-exported it in several formats, one of which I immediately imported in Keepass 2.x
-logged out of the local vault completely
-reconnected to internet
-logged in on my Bitwarden-vault
-imported the unencrypted backup
-done

After this it took a while to recover from the shocking possibility that I had destroyed all access to a large part of my digital (and not so digital) life. Truly horrifying…

Other issues
-At this point, after recovery, I have tried to import the encrypted backup to the local vault that, at that point, had not been in contact with the Bitwarden server (put differently: this local vault had the same account, master key and encryption key(s) as the vault that the encrypted export was made with). Locating the file and telling the vault to import it was possible. Importing generated an error ‘Failed to fetch’. I tried a few times and then gave up this attempt at full recovery.

Now let me first state that it is my own responsibility how I went to work. I have clearly not interpreted the warning messages correctly.

It comes down to what Kiko aptly writes above (thanks for that). I use the vault intuitively. The encrypted backup I created just minutes before the drastic measures I took. Not for one second I have realized what the consequences would be of my actions.

I did not have indications of my vault having been accessed or compromised. But I had been on the internet, using Bitwarden, with a Windows 11 machine that had not been patched since november 2025. Reason for this is that I restored a diskimage from november 2025 that I forgot to update before webbrowsing (I did my antivirus and firewall, but not the system patches. Silly, but the context is that I got too much on my mind apparently). Anyhow: I wanted to be certain about the security of my vault, I did not want to corrupt my vault for reason of which I cleared it before rotating keys, I did not want a clear text export on my hard drive. I have succesfully performed these actions before (exporting, logging out of all sessions, purging, changing master password, rotating keys, importing). I have just not realized the implications of the distinction between a password protected and an encrypted export that is tied to the account.

What may have helped me in this sequence of events is a warning just before rotating, in bold font, separated by a line or two in the warning window, that my actions would render all previously created encrypted exports totally useless (I mean, it is not likely the export would be decrypted before the end of the universe). I admit that it will not be possible to avoid all clumsiness (or stupidity) in the use of these tools, but, well…

Again, it is my own responsibility, but it’s correct what Kiko writes that I just thought ‘yeah of course, go ahead I have the export I created just minutes ago, haven’t I? Yeah, I am staying within the same account, of course. Let’s go’.

A last question on my part: when it comes to restoring the encrypted json to the local vault (‘failed to fetch’), why is this not working?

Thank all! Joey

ps: I agree that the default option for a .json export should be the password protected option. The option for an encrypted export could be put under ‘expert’ or ‘advanced’ option. Use of it could be further protected by measures mentioned above and/or others.

[grb]

@joeysmith

(exporting, logging out of all sessions, purging, changing master password, rotating keys, importing)

It’s the purging (and subsequent reimporting) part that is most confusing to me, especially since there was no evidence of a malicious account take-over. What was your motivation for this?

@joeysmith

A last question on my part: when it comes to restoring the encrypted json to the local vault (‘failed to fetch’), why is this not working?

The cloud database acts like a hub, and each local client database is like a spoke from that hub; all database modifications are first recorded in the cloud database, and subsequently synced to each client. When it comes to importing, until version 2023.10.0, it was only possible to import from the Web Vault (which obviously requires a network connection); even though you can now import directly from the other clients (e.g., Desktop app and browser extensions), doing so requires an internet connection for uploading the imported data to the cloud database. Thus, off-line importing is not supported for the same reason that off-line editing (or adding/deleting vault items) is not supported.

[kpiris (Kiko Piris)]

@joeysmith

-At this point, after recovery, I have tried to import the encrypted backup to the local vault that, at that point, had not been in contact with the Bitwarden server

This, as you already realized, won’t work.

@joeysmith

(put differently: this local vault had the same account, master key and encryption key(s) as the vault that the encrypted export was made with)

This is what’s wrong and the reason you can’t import that export back once your account encryption key has changed (either because it was rotated or because you are trying to import it into another account).

The account encrypted export is encrypted with your account encryption key, but that key simply is not present in the export. That key is only present (encrypted with your previous mp) on the local encrypted copies of your vault from before that rotation.

Where could you find any of those copies? you already had one copy and were able to use it [*]: In a local vault cache from a device that was logged in before that rotation, and hasn’t yet syncronized with the bitwarden servers (hence the advice to firstly disconnect that device from the Internet).

[*] for the reasons @grb wrote just above: importing into bitwarden can’t be done off-line, but exporting can.

[grb]

@kpiris

@joeysmith

(put differently: this local vault had the same account, master key and encryption key(s) as the vault that the encrypted export was made with)

This is what’s wrong and the reason you can’t import that export back

I think the point of confusion on @joeysmith’s part was that the client app and data cache that were restored from their disk image indeed includes the account encryption key required to decrypt the account-restricted export (see explanation below).

@kpiris

That key is only present (encrypted with your previous mp) on the local encrypted copies of your vault from before that rotation.

The local vault cache from @joeysmith’s disk image should in theory be able to yield the key. However, the encryption key would be stored in a “protected” form (itself encrypted using a key that is derived from the master password and email address). Thus, someone with the necessary programming skills, and sufficient insight into the data formats used in both the cache and in the account-restricted JSON export should in theory be able to:

1. Find the protected account key in the local cache.
2. Decrypt the protected key to yield the naked account encryption key.
3. Use the account encryption key to decrypt the account-restricted JSON.
4. Condition the data in the decrypted JSON to force it into a format that will be recognized by Bitwarden’s importer.
5. Import the data into the cloud vault.

However, to my knowledge, Bitwarden provides no tools for performing the necessary steps, and I am also not aware of any third-party tools that have the necessary capabilities. Nonetheless, the encryption algorithms are all documented (and open-source), so it would definitely be possible (for someone with the skills and inclination) to use reverse-engineering to recover the data.

[kpiris (Kiko Piris)]

@grb

I think the point of confusion on @joeysmith’s part was that the client app and data cache that were restored from their disk image indeed includes the account encryption key required to decrypt the account-restricted export (see explanation below).

You are right, I undestood it better later after re-reading it.

@grb

someone with the necessary programming skills, and sufficient insight into the data formats used in both the cache and in the account-restricted JSON export should in theory be able to:

Yes, an attacker trying to get into your encrypted vault (from a compromised device, for example) would probably have those skills (and motivation).

[joeysmith]

@grb the reason I purged the vault was because I did not want to run the risk of corrupting my data by changing master key and rotating. I figured: ‘corruption is not possible in an empty vault and I do have an account restricted backup that I’ll be able to restore the vault with after’.

[grb]

@joeysmith Thanks for explaining your reasoning. Personally, I would have purged/reimported only after seeing evidence of data corruption in the vault, but perhaps you were concerned about not being able to detect corrupted data after the key rotation…

[grb]

@joeysmith

@grb the reason I purged the vault was because I did not want to run the risk of corrupting my data by changing master key and rotating.

For future reference, I have it on good authority that as a result of behind-the-scenes improvements in the encryption processes, account key rotations (and similar changes to account security settings) no longer create any risk of data corruption, so there should be no good reason to purge vault contents (or even backing up the vault) before a key rotation.

I have been informed that the warning that remains in the documentation is obsolete, and will be removed in the near future.

[joeysmith]

Thanks for your updates grb, good to know there is no reason to be concerned about that.