Emergency Access Takeover not storing password #3196
Comments
|
The database record in the Emergency Access table is: |
|
[2023-01-29 16:30:13.214][request][INFO] POST /identity/accounts/prelogin |
|
|
|
Seems to work fine for me. |
|
I know and I did try to login with the username of the grantor with the new password, but failed. The thing is: if I click on save as grantee, nothing seems to happen. Window doesn't close, no message saying that the new password is save/applied, ... (I do see a message if the 2nd password doesn't match the first. So that works...) |
|
Again, it does work for me. Just tested it without any issues. Maybe something else on your side is blocking the request? Try to set it via a different browser, or use a Private/incognito window. Also, on the reverse proxy side, i suggest to check the logs there. because i'm missing the POST that tells it to change the password. It should look like this, but i only see the POST to the |
|
I think I can reproduce this by adding (and confirming) someone as an emergency contact with only view access and then later changing their role to takeover. Afterwards I can attempt an takeover but even if I approve it, it will not work (i.e. do nothing as described above) because the field On the other hand, if I add and confirm someone with takeover permissions from the beginning, this field will not be empty. |
|
@stefan0xC But, as far as i know, you can't change it from takeover to view without removing/rejecting the previous approved one. So, that is probably not the issue here. Update: Ah, wait, you can indeed. That does cause issues. |
|
We probably need to prevent updating the key if it is not set. |
|
As far as I can remember, this was a straight TakeOver config, not first a View Only. Is there any digging I can do on my side to verify this situation? I'm also trying to rule out my nginx reverse proxy, but Vaultwarden (understandably) does not allow me to log in over HTTP. I need some more time to figure out the best way to access Vaultwarden directly in my network. I do get an additional POST logline if I click on Save, but that was a /takeover/ URL and not a /password/ URL if I recall correctly (not at home right now and therefor not able to debug at the moment). Is there a way to verify the user has no items in it's personal vault? I have this disabled in the policy, but I'm unsure whether this was prior to this user being created. Currently this is the view in the Admin Panel for this specific user: |
|
That value is derived from the If you are sure that you did not switched anything, not even the amount of days for example, then i suggest to check (as mentioned before) your reverse proxy log and anything else infront of Vaultwarden which could have blocked calls. Because i'm missing the POST call to update the password as mentioned earlier. |
|
OK, the deauthorized sessions will indeed be the cause of Never. I did try that to force a full login for the user. I will have a look at the proxy logs tonight. |
Can confirm that this is the case. If I replace vaultwarden/src/api/core/emergency_access.rs Line 126 in 9366e31 if data.KeyEncrypted.is_some() {
emergency_access.key_encrypted = data.KeyEncrypted;
}the field will not be emptied when changing the user level from view to takeover (or the number of days). |
|
I tried my best to get a self signed certificate setup using https://github.com/dani-garcia/vaultwarden/wiki/Private-CA-and-self-signed-certs-that-work-with-Chrome but could not get it to work. As it explicitely states no support will be provided, I will not ask any ;-) The logging from my nginx is below: This seems to correspond to the following lines in the VaultWarden log: I've tried this in both Chrome and Edge (although I'm not sure there's too much difference as both are Chromium based), in private modes and with UBlock Origin disabled for the VaultWarden site. I'm not sure where things are going wrong and why the /password POST is not even reaching my nginx, but for now I'm not sure I can do any additional debugging. For me it's fine to close this issue, but I'm not sure you already want it closed as you may have identified a bug (although it may be unrelated to this issue). So I'll leave the honours to close it to you :-D Thanks for your help! |
|
@rsoftnl given that the table did not have the If you did check the developer console of your browser while trying to save a new password for the grantor and nothing happens you would have seen that what actually happens is that the web-vault will throw an error Since this is happening on the client side it's not something you can check (or even notice) in the server logs aside from not seeing the call you expect. And because the database entry has been corrupted somehow (maybe you just opened and saved the grantee again without changing anything?) there's not really anything you could do except removing the grantee and adding them again. |
Hi,
I'm trying to access a users vault by means of the Emergency Access feature. Everything appears to be setup correctly, but when I'm given the opportunity to takeover the Master Password (after 7 days wait period, E-mail from Vaultwarden received it has granted me rights) I can't change the Master Password. It will allow me to enter the new password, but Save seems to not do anything at all. The window does not close and the LOG shows a 200 message
Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden: ADMIN_TOKEN
{ "_duo_akey": null, "_enable_duo": false, "_enable_email_2fa": true, "_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_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": false, "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": "********", "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": "/data/vaultwarden.log", "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": false, "password_iterations": 100000, "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": false, "signups_allowed": false, "signups_domains_whitelist": "********", "signups_verify": true, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": "LOGIN", "smtp_debug": false, "smtp_embed_images": true, "smtp_explicit_tls": null, "smtp_from": "**********************", "smtp_from_name": "Vaultwarden", "smtp_host": "*****************", "smtp_password": "***", "smtp_port": 587, "smtp_security": "starttls", "smtp_ssl": null, "smtp_timeout": 15, "smtp_username": "**********************", "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": 30, "trash_purge_schedule": "0 5 0 * * *", "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": null, "yubico_secret_key": null, "yubico_server": null }Thanks in advance for any suggestions
The text was updated successfully, but these errors were encountered: