Can't stay logged in

[LanceMcCarthy]

Hi folks, I'm not sure what changed, but it looks like the browser extension (chromium-based Edge) doesn't stay logged in. when I went to the vault's landing page, my master password doesn't work anymore... this is worrisome 😬

Just like what happened in December, I thought "hmm, maybe the extension/clients got an update that wasn't compatible with vaultwarden server anymore". I was on a release from March I think, so I did a quick update to 2023.5.0. However, the problem still persists after the update.

To help explain the experience clearly, here's the experience:

1. I go to a webpage that needs credentials, but the extension is locked
2. Unlock the extension, takes forever to unlock
3. Fill that site's credentials and let the extension close
4. The extension is now locked again

If I go to the vault's homepage in the browser directly, I get the following result when trying to log in:

POST 1 - prelogin:

{"Kdf":0,"KdfIterations":600000,"KdfMemory":null,"KdfParallelism":null}

POST 2 - token

{
    "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": ""
}

Question

How is it possible that the master password works to unlock the extension, but not the home page? Is it possible that the master password would get reset

System setup

• I am using Docker with a persistent storage mount
• I have MFA enabled using Duo
• I am using my own custom reverse proxy (Loadmaster), Vaultwarden doesn't need to be concerned about external or HTTPS traffic I can confirm SSL and HTTPS traffic is fine, I checked this first).

[BlackDex]

See #3692, it probably is related.

[LanceMcCarthy]

LOL and I thought I searched everything before opening this :)

That makes sense for the extension, but what about what happened the master password. Is it possible the server has locked out the master user because the extension is DDOSing the server?

In the meantime, since I have a hint, I will uninstall the extension, then upgrade, then reinstall it. Maybe there's something in the extension's cache that is being used which is breaking it.

[BlackDex]

It would be strange something wrecked your master password, since nothing will write your master password unless you changed it your self, not the update nor the extensions.

If you are 100% sure of the password, you can try the procedure i mentioned there, in theory that should work.

[LanceMcCarthy]

Thank you for the prompt reply on a Saturday morning :) Yes, I'm 100% sure of the master password. I use it daily because I have the vault auto-lock.

So something is weird, I downloaded and opened db.sqlite3 from the host's mounted directory just so I could look around and become familiar with the structure (before I started playing with the hash and salt values).

There aren't any records for users table, this leaves me with a couple questions:

• The db file size is only 224 kb, this seems extremely small for the number of vault entries I have (in fact some of my secure notes are larger than that). Is it possible that 224kb is the default starting size?
• Am I supposed to look in another table for administrator users?
• Or is the entire database encrypted and I need to open it with "DB Browser (SQL Cipher)" app instead of "DB Browser (SQLite)" app?

I do have automatic backups enabled (through bruceforce/vaultwarden-backup and ``) and I'm going to check those backups to see what the size of the db is in there.

[BlackDex]

Not sure what the default size of a new database is actually.
But this looks like an empty database to me.

Maybe during the updates/troubleshooting you moved the data folder, or changed some stuff?
But currently, that would explain you can't login.

[LanceMcCarthy]

Yep, something went wrong somewhere and I ended up with an empty database. I guess I should take this opportunity to move to a new host.

The one thing I'm hoping to salvage is all of my settings. Is there an easy way for me to read it if I exec into the container? I tried cat'ing out things like $YUBICO_CLIENT_ID but that was empty so I'm guessing I have the wrong env varible names or they'r ein a different env context.

Please forgive my intermediate Linux skills, I'm a .NET developer and spend 95% of my time in non-bash environments. I tried using nano to read the env file, but I'm not sure I got the file name correct, or maybe it's in the wrong env context.

[LanceMcCarthy]

Never mind! I'll switch to docker-compose.yml and never lose the settings again ;) Also, from my opinion, it's easier to update when using compose anyways. it's a good thing I exported the vault to an unencrypted file right before updating, all of my values for the yubico and duo were stored as secure notes, so I was able to get up and running again on a different domain.

I also feel much better knowing the container is running in a system that has an SLA, while my Pi4 is subject to outages that last longer than my solar panels and then Powerwall runs out of battery 🤣