mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
Loss of all passwords due to change of masterpassword with encryption key rotation #1474
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nordic-style on GitHub (Jan 19, 2023).
Subject of the issue
All passwords are without a name or content (see screenshot)
Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden: DOMAIN, SIGNUPS_ALLOWED, ADMIN_TOKEN, SMTP_HOST, SMTP_SSL, SMTP_PORT, SMTP_FROM, SMTP_USERNAME, SMTP_PASSWORD
Steps to reproduce
Expected behaviour
Just change the encryption key and my master password
Actual behaviour
changed my master password but the passwords are not usable anymore
Troubleshooting data
from the logs:
[2023-01-18 22:31:28.269][response][INFO] (sync) GET /api/sync?<data..> => 200 OK
[2023-01-18 22:31:31.236][request][INFO] GET /api/accounts/revision-date
[2023-01-18 22:31:31.237][response][INFO] (revision_date) GET /api/accounts/revision-date => 200 OK
[2023-01-18 22:31:31.252][request][INFO] POST /identity/connect/token
[2023-01-18 22:31:31.255][response][INFO] (login) POST /identity/connect/token => 200 OK
[2023-01-18 22:31:31.586][request][INFO] GET /api/sync
[2023-01-18 22:31:31.697][response][INFO] (sync) GET /api/sync?<data..> => 200 OK
[2023-01-18 22:31:32.699][request][INFO] GET /api/two-factor
[2023-01-18 22:31:32.700][response][INFO] (get_twofactor) GET /api/two-factor => 200 OK
[2023-01-18 22:31:32.702][request][INFO] GET /api/accounts/profile
[2023-01-18 22:31:32.703][response][INFO] (profile) GET /api/accounts/profile => 200 OK
[2023-01-18 22:31:40.440][request][INFO] GET /api/accounts/profile
[2023-01-18 22:31:40.441][response][INFO] (profile) GET /api/accounts/profile => 200 OK
[2023-01-18 22:32:47.734][request][INFO] POST /identity/connect/token
[2023-01-18 22:32:47.738][response][INFO] (login) POST /identity/connect/token => 200 OK
[2023-01-18 22:32:47.752][request][INFO] GET /api/sync?excludeDomains=true
[2023-01-18 22:32:47.867][response][INFO] (sync) GET /api/sync?<data..> => 200 OK
[2023-01-18 22:32:48.039][request][INFO] POST /api/accounts/password
[2023-01-18 22:32:48.167][response][INFO] (post_password) POST /api/accounts/password => 200 OK
[2023-01-18 22:32:53.304][request][INFO] POST /api/accounts/key
[2023-01-18 22:32:54.042][vaultwarden::api::core::ciphers][ERROR] The field Notes exceeds the maximum encrypted value length of 10000 characters.
[2023-01-18 22:32:54.045][response][INFO] (post_rotatekey) POST /api/accounts/key => 400 Bad Request
@BlackDex commented on GitHub (Jan 19, 2023):
Ai, that's nasty.
But, i do think this issue is already fixed in the
testingtagged images.I'll need to verify.
@BlackDex commented on GitHub (Jan 19, 2023):
Did some quick checks, and there are some strange issues indeed.
Also one which has to do with some updates regarding the websockets to logout.
It needs to exclude the client which does the password changing, and that currently isn't done.
Besides that, it also needs to provide a better error in case there are some cipher issues, I probably have some time this evening to check this.
@tessus commented on GitHub (Jan 19, 2023):
@BlackDex what I don't understand is why the transaction is not rolled back. e.g. when an error occurs, a database transaction is supposed to be rolled back. Yet it seems something happens and the data is committed anyway, even if the data is garbage.
@BlackDex commented on GitHub (Jan 19, 2023):
We do not have transactions, so that is one.
Further, after the
stablerelease there was a fix regarding the note sizes. All ciphers are saved in a loop, and not a transaction. Intestingthere is a validation step done before stuff gets stored, and thus prevents this issue.On top of that, if using websockets, it tells the clients (including the one changing the password) to logout, but that interrupts the key rotation. That one is easily fixed by providing the contextId during this specific event, because the client will logout it self afterwards, but that websocket message will still logout other clients, which is good.
Using transactions is something still on our list to implement.
@tessus commented on GitHub (Jan 19, 2023):
Thanks for the explanation. Yep, I thought that
00855ee31dwould fix the size issue.@BlackDex commented on GitHub (Jan 19, 2023):
Well, it would have, if i had put that validation step there ;)
@nordic-style commented on GitHub (Jan 19, 2023):
Thanks for the quick responses. Just for my understanding: with the patch i will not be able to save my PGP public and private key in one note since it together exceeds 10k size? Not even in the Web version since some clients cannot handle the size?
@tessus commented on GitHub (Jan 19, 2023):
@nordic-style if the encrypred data exceeds 10k (not the raw data you paste in the field), you won't be able to add the gpg keys in the Notes field. However, you can attach them as files.
@BlackDex commented on GitHub (Jan 19, 2023):
The issue with that is that it is not synced 😉 .
I understand the issue, but we can't risk other issues with allowing a larger size of the notes.
While we had it larger for a longer time, it does prevent people from switching to Bitwarden if they want.
And, indeed some clients have issues with this.
Maybe voting here will help: https://community.bitwarden.com/t/support-longer-notes-breaks-lastpass-import/2970
@BlackDex commented on GitHub (Jan 20, 2023):
@nordic-style I have resolved the issue via #3157 , once merged, it should tell you that there are notes which are to large, and prevent it from being stored. The password will still be changed though, but the key-rotation will not have an effect.
Thanks for reporting!.
@nordic-style commented on GitHub (Jan 21, 2023):
Thank you for fixing!
After removing the "evil notes" i could restore a backup.