Admin reset not working

[R-DGS]

Subject of the issue

Enabled admin reset for a organization. Master-password reset.

i used it on a test user to test it how how it works etc and if it works.

When i reset the password and try to login with that account it just fails the login says username / password wrong.
i tried to change the password multiple times but the same Error.

Deployment environment

[BlackDex]

Seems to work fine for me.
Are there any errors in the logs or the browser F12 console when resetting the password?

[R-DGS]

/identity/connect/token 400 (Bad Request)
{
"ErrorModel": {
"Message": "Username or password is incorrect. Try again",
"Object": "error"
},
"ExceptionMessage": null,
"ExceptionStackTrace": null,
"InnerExceptionMessage": null,
"Message": "Username or password is incorrect. Try again",
"Object": "error",
"ValidationErrors": {
"": [
"Username or password is incorrect. Try again"
]
},
"error": "",
"error_description": ""
}

[BlackDex]

I actually mean during the password reset, not during login.
Also, what happens if you try to use the original password, and not the one used to reset?

[R-DGS]

the account that i did restart was an account that already excists before this update to the latest version. I enabled rest master password and reset it. The old one and new one arnt working.

I just created a new account and added it to the same organization. and this one is auto added to the enrollment. and i also did a reset on this account but for this one it works.

I tried it again on the old one and it does not work.

[stefan0xC]

Can you tell us more? E.g. by posting the generated support string of the diagnostics page in the admin panel? And by also providing the logs when you try to change the password of the old user if there might be some indication what happens?

[BlackDex]

I just tried multiple scenarios, including the one you did with an existing account.
I'm not seeing any issues here at all.

From which version did you come?

[R-DGS]

Your environment (Generated via diagnostics page)

• Vaultwarden version: v1.28.0
• Web-vault version: v2023.3.0b
• OS/Arch: linux/x86_64
• Running within Docker: true (Base: Debian)
• Environment settings overridden: true
• Uses a reverse proxy: false
• Internet access: true
• Internet access via a proxy: false
• DNS Check: true
• Browser/Server Time Check: true
• Server/NTP Time Check: true
• Domain Configuration Check: true
• HTTPS Check: true
• Database type: SQLite
• Database version: 3.39.2
• Clients used:
• Reverse proxy and version:
• Other relevant information:

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden: ADMIN_TOKEN

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": false,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_smtp_img_src": "cid:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_session_lifetime": 20,
  "admin_token": "***",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "***************",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": true,
  "domain": "*****://***************",
  "domain_origin": "*****://***************",
  "domain_path": "",
  "domain_set": true,
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "email_attempts_limit": 3,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "enable_db_wal": true,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": null,
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Vaultwarden",
  "invitations_allowed": true,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "Info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "",
  "org_events_enabled": false,
  "org_groups_enabled": false,
  "password_hints_allowed": true,
  "password_iterations": 2000000,
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": false,
  "signups_domains_whitelist": "*****************,************,********,******************",
  "signups_verify": false,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "*****************************",
  "smtp_from_name": "Vaultwarden",
  "smtp_host": "***********",
  "smtp_password": null,
  "smtp_port": 25,
  "smtp_security": "off",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": null,
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": null,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_sendmail": false,
  "use_syslog": false,
  "user_attachment_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "websocket_address": "0.0.0.0",
  "websocket_enabled": true,
  "websocket_port": 3012,
  "yubico_client_id": "85784",
  "yubico_secret_key": "***",
  "yubico_server": null
}

_vaultwarden_logs.txt

[R-DGS]

1.27 the previous version

[BlackDex]

First, i would suggest to try and use a reverse proxy to handle the TLS/Cert errors I see.
Second, could you please try the :testing tagged image and see if that solves the issue?
I see an error regarding the known device endpoint. While i think it shouldn't have any impact, i could be wrong of course.

[R-DGS]

First, i would suggest to try and use a reverse proxy to handle the TLS/Cert errors I see. Second, could you please try the :testing tagged image and see if that solves the issue? I see an error regarding the known device endpoint. While i think it shouldn't have any impact, i could be wrong of course.

This is a live setup. so i cant really just put the whole vaultwarden on testing.

This is only for internal usage. a reverse proxy in our network is harder to fix.

[BlackDex]

Well. there is nothing changed in testing except that issues.
You can always copy the database etc.. and setup a different container maybe?

[R-DGS]

Well. there is nothing changed in testing except that issues. You can always copy the database etc.. and setup a different container maybe?

will check on that. Because this is a VM with debian /docker installed. need to move the VM it self to a different system.

[BlackDex]

I think i have found the issue.

[BlackDex]

Yes. The issue is that for some reason the mail which needs to be sent to the user isn't sent, which causes a delay/timeout and causes a 504 for me at least. And for some reason it breaks the reset. Which is strange, since it should break/exit/return if sending the mail doesn't work, and should not reset the users password at that point.

[BlackDex]

@R-DGS Can you verify that that specific account did not receive a mail about the password reset?

[R-DGS]

@R-DGS Can you verify that that specific account did not receive a mail about the password reset?

When i reset the password i get a email saying that the master password is reset.

[BlackDex]

Hmm... Also for the user for which it is not working?

[R-DGS]

Hmm... Also for the user for which it is not working?

Yes. Every time i do a reset i get an email.

[BlackDex]

Could you try to login with a different browser or in an Private/Incognito mode for that user?
I'm a bit confused. Since if the submit works it should have set the correct password.

[R-DGS]

Could you try to login with a different browser or in an Private/Incognito mode for that user? I'm a bit confused. Since if the submit works it should have set the correct password.

I have tried it in firefox / firefox private chrome / chrome private

i did start up a old copy of the VM and updated that one also. As far as i know not much is changed except in the other one is all users and passwords and different org and the one 1 started is a initiele setup of vaultwarden.

on my test copy which is running the latest nog the testing it is working on the old account that is there.

Maybe due to al the testing and changing it might have corrupted that user account.

So maybe i will see if i can maybe a copy of the live version and do some tests with that one.

[BlackDex]

In theory, you should be able to overwrite the users record which includes they key's and hashed master-password-hash.
That way the users password and key still match and if the password/keys are not rotated it should still be able to access it.
Just make sure to make a backup of the database.

Also. you could try to do a database check.

sqlite3 db.sqlite3 'PRAGMA integrity_check;'

If that results in all ok, a database corruption is probably not the issue.

[R-DGS]

sqlite3 db.sqlite3 'PRAGMA integrity_check;'

it did give the status ok

[R-DGS]

What i do remember and i was looking in the sqlite db. that on the account where i reset the admin password i had changed the Keys to Argon2id.

Standard that isnt used yet but also wanted to test that out on that account.

---

I tried it again with a new account and changed the keys to Argon2ID and change the master password and now it fails again.
On the account where i changed this does not have this argon2ID yet chosen.

[BlackDex]

Ai. We need to check if this also happens on Bitwarden it self! If that is the case, we can't fix this our self.
But good find! Thanks for the update.

[BlackDex]

What i do remember and i was looking in the sqlite db. that on the account where i reset the admin password i had changed the Keys to Argon2id.

Standard that isnt used yet but also wanted to test that out on that account.

I tried it again with a new account and changed the keys to Argon2ID and change the master password and now it fails again.
On the account where i changed this does not have this argon2ID yet chosen.

I Quickly tried this my self. And I do not see the same issue unfortunately

[stefan0xC]

I managed to reproduce this by setting the Argon2id parameters really high so it takes a lot more than a second (something like m=512,t=6,p=4).

Adding my test account to the organization and enrolling to the feature worked. But when I tried to change the password via the admin password reset function, I could not login with this account anymore (neither old nor new password).

I could get the login for my test account working by manually reducing these values directly in the database and then resetting the password again:

UPDATE users SET client_kdf_memory = 64, client_kdf_iter = 3, client_kdf_parallelism = 4 WHERE email = 'testuser@example.com';

Not sure if this has any unintended side consequences (so far it looks good but I have not tested this extensively).
edit: updated to the actual sql statement I ran...

[BlackDex]

That kinda looks the same as my mail timeout issue i just got once.
Does the call to the server get executed? Or does something else happens?

Is this more a client side issue or server? And what happens when you use the PR i created with the error fix?

[stefan0xC]

I got a mail network issue (once), my firefox also froze by the second time (but might have been unrelated) and once it looked like it worked (but without any error messages).

I will test your PR tomorrow (sorry, it's getting late). But if the client can't handle it, then it might be out of our control.

[2023-03-30 00:24:32.509][request][INFO] GET /api/organizations/2a669f07-a4d3-49a4-9fc3-7b6fd76f1a42/users/0519f8ea-f69d-46ad-ab77-175826087962/reset-password-details
[2023-03-30 00:24:32.512][response][INFO] (get_reset_password_details) GET /api/organizations/<org_id>/users/<org_user_id>/reset-password-details => 200 OK
[2023-03-30 00:24:32.953][request][INFO] PUT /api/organizations/2a669f07-a4d3-49a4-9fc3-7b6fd76f1a42/users/0519f8ea-f69d-46ad-ab77-175826087962/reset-password
[2023-03-30 00:24:32.955][handlebars::render][DEBUG] Rendering value: Path(Relative(([Named("img_src")], "img_src")))
[2023-03-30 00:24:32.955][handlebars::render][DEBUG] Rendering value: Path(Relative(([Named("user_name")], "user_name")))
[2023-03-30 00:24:32.955][handlebars::render][DEBUG] Rendering value: Path(Relative(([Named("org_name")], "org_name")))
[2023-03-30 00:24:32.955][handlebars::render][DEBUG] Rendering value: Path(Relative(([Named("img_src")], "img_src")))
[2023-03-30 00:24:32.955][handlebars::render][DEBUG] Rendering value: Path(Relative(([Named("user_name")], "user_name")))
[2023-03-30 00:24:32.955][handlebars::render][DEBUG] Rendering value: Path(Relative(([Named("org_name")], "org_name")))


[2023-03-30 00:24:47.966][vaultwarden::mail][DEBUG] SMTP error: lettre::transport::smtp::Error {
    kind: Connection,
    source: Os {
        code: 101,
        kind: NetworkUnreachable,
        message: "Network is unreachable",
    },
}
[2023-03-30 00:24:47.966][vaultwarden::mail][ERROR] SMTP error: Connection error: Network is unreachable (os error 101)
[2023-03-30 00:24:47.967][vaultwarden::api::core::organizations][ERROR] Error sending user reset password email: SMTP error: Connection error: Network is unreachable (os error 101)
[2023-03-30 00:24:48.963][response][INFO] (put_reset_password) PUT /api/organizations/<org_id>/users/<org_user_id>/reset-password => 200 OK

[BlackDex]

But, it shouldn't break, or render the login invalid. Unless the argon2 code part freezes and breaks for some reason. But the data in the db should still be valid. We only store the new key/pw-hash.

[R-DGS]

I managed to reproduce this by setting the Argon2id parameters really high so it takes a lot more than a second (something like m=512,t=6,p=4).

Adding my test account to the organization and enrolling to the feature worked. But when I tried to change the password via the admin password reset function, I could not login with this account anymore (neither old nor new password).

I could get the login for my test account working by manually reducing these values directly in the database and then resetting the password again:

UPDATE users SET client_kdf_memory = 19, client_kdf_iter = 2, client_kdf_parallelism = 1 WHERE email = 'testuser@example.com';

Not sure if this has any unintended side consequences (so far it looks good but I have not tested this extensively).

Yes i also had it set a little higher than the standard 128 5 7 or 7 5 for the last 2 values.

[stefan0xC]

I think I found the problem in reset-password-details because it only returns a value for Kdf and KdfIterations. So my sql statement should actually have set the remaining values to the default values (m=64 p=4) to get the password to work. Sorry I had changed it to lower values in my previous post but not actually tested it. 😓

[BlackDex]

I think I found the problem in reset-password-details because it only returns a value for Kdf and KdfIterations. So my sql statement should actually have set the remaining values to the default values (m=64 p=4) to get the password to work. Sorry I had changed it to lower values in my previous post but not actually tested it. sweat

Ah!. I did not changed anything, and used the default settings. Which is probably what will be used if nothing is returned.

I'm Quickly testing this right now :)

[BlackDex]

@stefan0xC Yes, it looks like it just used the defaults set for Argon2id. That is why it worked for me in my test.
Ill update my PR to fix this

[BlackDex]

Thanks @R-DGS for reporting this issue. There is a PR now which should fix this.
Thanks @stefan0xC for spotting the specific location!
I checked all other locations where we return these values, and looks like all should be valid and this location was missed.
I added you as Co-Author to the PR :).