[GH-ISSUE #724] Admin page choices seem restrictive

kerem commented

2026-03-03 01:29:51 +03:00

Owner

Originally created by @ngoonee on GitHub (Nov 14, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/724

So unless I'm missing something, the bitwarden_rs self-hosted admin panel is:-

Globally accessible (can't be restricted to just a few users with admin permissions)
Password-only (no 2-factor unlike normal users)
Inconvenient (the password must be specified on startup and can't be changed without bringing the docker image down and up)
Unsafe (if because of number 3 you just do not use and admin_token, which is a HUGE BAD IDEA)

Seems it would have been easiest just to make the first user an admin (or perhaps you'd need to specify the admin list when starting the server)? At least you'd get 2FA etc.

Originally created by @ngoonee on GitHub (Nov 14, 2019). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/724 So unless I'm missing something, the bitwarden\_rs self-hosted admin panel is:- 1. Globally accessible (can't be restricted to just a few users with admin permissions) 2. Password-only (no 2-factor unlike normal users) 3. Inconvenient (the password must be specified on startup and can't be changed without bringing the docker image down and up) 4. Unsafe (if because of number 3 you just do not use and admin\_token, which is a HUGE BAD IDEA) Seems it would have been easiest just to make the first user an admin (or perhaps you'd need to specify the admin list when starting the server)? At least you'd get 2FA etc.

kerem closed this issue

2026-03-03 01:29:51 +03:00

kerem commented

2026-03-03 01:29:52 +03:00

Author

Owner

@dani-garcia commented on GitHub (Nov 14, 2019):

1- Not sure what do you mean, the admin page is protected by the password set in admin_token, if we used one of the users credentials it would still be protected by an email and a password, security wise it's the same.

2- This one is true, implementing TOTP authenticator support should be fairly easy and I've been meaning to do it for some time now. The rest would be harder but doable still.

3- The admin token can be changed in the admin page, it's at the bottom of the general settings section.

4-I don't understand what do you mean here, yeah not using an admin_token is a bad idea, but I don't think having it set up is that inconvenient, you can change it from the admin page and you can save it in your vault for easy logins.

The reason we don't support using a users credentials in the admin page is because that can mean two things:

Sending the user's plain password to the server, which is something I've generally tried to avoid and isn't done at the moment (The clients hash the password before sending it to the server)
Implementing the hashing in the admin page code, which would take a decent amount of work for not much benefit.

For what it's worth, in my instance I generate long admin_tokens (60+ chars) and save them as a cipher inside my bitwarden account, that way I can use autocomplete to log in quickly.

@dani-garcia commented on GitHub (Nov 14, 2019): 1- Not sure what do you mean, the admin page is protected by the password set in admin_token, if we used one of the users credentials it would still be protected by an email and a password, security wise it's the same. 2- This one is true, implementing TOTP authenticator support should be fairly easy and I've been meaning to do it for some time now. The rest would be harder but doable still. 3- The admin token can be changed in the admin page, it's at the bottom of the general settings section. 4-I don't understand what do you mean here, yeah not using an admin_token is a bad idea, but I don't think having it set up is that inconvenient, you can change it from the admin page and you can save it in your vault for easy logins. The reason we don't support using a users credentials in the admin page is because that can mean two things: - Sending the user's plain password to the server, which is something I've generally tried to avoid and isn't done at the moment (The clients hash the password before sending it to the server) - Implementing the hashing in the admin page code, which would take a decent amount of work for not much benefit. For what it's worth, in my instance I generate long admin_tokens (60+ chars) and save them as a cipher inside my bitwarden account, that way I can use autocomplete to log in quickly.

kerem commented

2026-03-03 01:29:52 +03:00

Author

Owner

@BlackDex commented on GitHub (Nov 14, 2019):

Also, the official bitwarden project doesn't link the accounts to the admin panel.

It provides login via email which sends a special link to login.

In any case, if you use a reverse proxy like nginx, apache or haproxy even you can add extra basic auth pre-login if you want.

@BlackDex commented on GitHub (Nov 14, 2019): Also, the official bitwarden project doesn't link the accounts to the admin panel. It provides login via email which sends a special link to login. In any case, if you use a reverse proxy like nginx, apache or haproxy even you can add extra basic auth pre-login if you want.

kerem commented

2026-03-03 01:29:52 +03:00

Author

Owner

@ngoonee commented on GitHub (Nov 14, 2019):

The page is a totally separate account with a separate password, which means its globally accessible to anyone who knows the password (admin_token). This wouldn't be much of a problem if 2FA was possible, but under the current situation it does seem like the security (single password) is much lower than if you could just re-use the login credentials.
Does setting the admin token in the settings page persist across reboots? My concern with setting it on startup is that startup scripts tend to be uploaded to people's dotfiles etc. and no sensitive information should ever exist in a startup script. Of course, if its possible to set a dummy password and immediately change it permanently from the admin page, this is a non-issue.
This stems from my misunderstandings of the above I think. If 3. is viable then 4. becomes a non-issue. However 2FA of course would be very welcome.

Thanks for the follow-up para as well, yes sending plaintext passwords is a bad idea. I guess I thought admin page could just re-use the session from the web vault, hence you'd need to be logged in to the web vault first. Could even put a convenient 'admin' link on the top bar there. Wouldn't this handover the responsibility to the web vault for authentication?

@ngoonee commented on GitHub (Nov 14, 2019): 1. The page is a totally separate account with a separate password, which means its globally accessible to anyone who knows the password (admin_token). This wouldn't be much of a problem if 2FA was possible, but under the current situation it does seem like the security (single password) is much lower than if you could just re-use the login credentials. 3. Does setting the admin token in the settings page persist across reboots? My concern with setting it on startup is that startup scripts tend to be uploaded to people's dotfiles etc. and no sensitive information should ever exist in a startup script. Of course, if its possible to set a dummy password and immediately change it permanently from the admin page, this is a non-issue. 4. This stems from my misunderstandings of the above I think. If 3. is viable then 4. becomes a non-issue. However 2FA of course would be very welcome. Thanks for the follow-up para as well, yes sending plaintext passwords is a bad idea. I guess I thought admin page could just re-use the session from the web vault, hence you'd need to be logged in to the web vault first. Could even put a convenient 'admin' link on the top bar there. Wouldn't this handover the responsibility to the web vault for authentication?

kerem commented

2026-03-03 01:29:52 +03:00

Author

Owner

@dani-garcia commented on GitHub (Nov 14, 2019):

Yes, the admin page configuration and the admin token are all saved in the config.json file, by default in the data folder. Once that's set there, you can remove it from the environment variables, as the config file would take precedence anyway.

Well I've never thought about it before, but reusing the session tokens would technically work, though it would create a very unintuitive login process: first go to vault.example.com, login, then manually go to vault.example.com/admin, we could redirect from the admin page to the login page but not the other way around, not without modifying the web vault code.

@dani-garcia commented on GitHub (Nov 14, 2019): Yes, the admin page configuration and the admin token are all saved in the config.json file, by default in the data folder. Once that's set there, you can remove it from the environment variables, as the config file would take precedence anyway. Well I've never thought about it before, but reusing the session tokens would technically work, though it would create a very unintuitive login process: first go to vault.example.com, login, then manually go to vault.example.com/admin, we could redirect from the admin page to the login page but not the other way around, not without modifying the web vault code.

kerem commented

2026-03-03 01:29:52 +03:00

Author

Owner

@ngoonee commented on GitHub (Nov 15, 2019):

This is beyond my expertise as I'm not a web/UI guy, but would it be possible to 'inject' an additional div or something to the web vault for that purpose? Is the current web vault code directly taken from bitwarden?

Will the config file take precedence even when removing and recreating the docker? Currently I can't find 'config.json' anywhere on my system or inside the docker.

@ngoonee commented on GitHub (Nov 15, 2019): This is beyond my expertise as I'm not a web/UI guy, but would it be possible to 'inject' an additional div or something to the web vault for that purpose? Is the current web vault code directly taken from bitwarden? Will the config file take precedence even when removing and recreating the docker? Currently I can't find 'config.json' anywhere on my system or inside the docker.

kerem commented

2026-03-03 01:29:52 +03:00

Author

Owner

@dani-garcia commented on GitHub (Nov 15, 2019):

Yes the current vault code is pretty much the same as upstream, just changing the URLs to not point to the official API and some style changes to hide stuff like billing pages and similar. We try to not touch any of the functionality because that would mean more work to keep it updated as new web vault releases come out.

The config.json file takes precedence over environment variables or the .env file, and should be inside the mounted data volume, but it's only created the first time the settings are saved in the admin panel, so maybe that's why you don't see it. The data volume will survive the containers being updated or deleted yes, which means the config file would still apply.

@dani-garcia commented on GitHub (Nov 15, 2019): Yes the current vault code is pretty much the same as upstream, just changing the URLs to not point to the official API and some style changes to hide stuff like billing pages and similar. We try to not touch any of the functionality because that would mean more work to keep it updated as new web vault releases come out. The config.json file takes precedence over environment variables or the .env file, and should be inside the mounted data volume, but it's only created the first time the settings are saved in the admin panel, so maybe that's why you don't see it. The data volume will survive the containers being updated or deleted yes, which means the config file would still apply.

kerem commented

2026-03-03 01:29:52 +03:00

Author

Owner

@ngoonee commented on GitHub (Nov 16, 2019):

Thanks, have updated the wiki page with this information.

Final question on the admin page, is there no way to logout (beyond leaving it alone/closed for 20 minutes)?

@ngoonee commented on GitHub (Nov 16, 2019): Thanks, have updated the wiki page with this information. Final question on the admin page, is there no way to logout (beyond leaving it alone/closed for 20 minutes)?

kerem commented

2026-03-03 01:29:52 +03:00

Author

Owner

@dani-garcia commented on GitHub (Nov 16, 2019):

You can also delete the cookies in the browser, but adding an explicit logout button is not a bad idea.

@dani-garcia commented on GitHub (Nov 16, 2019): You can also delete the cookies in the browser, but adding an explicit logout button is not a bad idea.

kerem commented

2026-03-03 01:29:52 +03:00

Author

Owner

@dani-garcia commented on GitHub (Dec 1, 2019):

The logout button is now present in the latest commit.

@dani-garcia commented on GitHub (Dec 1, 2019): The logout button is now present in the latest commit.

kerem commented

2026-03-03 01:29:53 +03:00

Author

Owner

@mprasil commented on GitHub (Jan 29, 2020):

I think this can be now closed since the logout button was added and the reason for separate "account" was explained. Feel free to reopen if you think there's more we can do here.

@mprasil commented on GitHub (Jan 29, 2020): I think this can be now closed since the logout button was added and the reason for separate "account" was explained. Feel free to reopen if you think there's more we can do here.

Rows
Columns

[GH-ISSUE #724] Admin page choices seem restrictive #490