mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2025-12-10 17:23:04 +03:00
admin_token in config.json shouldn't be in clear text #1250
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 @mgutt on GitHub.
I'm using the Vaultwarden docker container and was a little bit suprised seeing the admin token in clear text in /data/config.json:
Shouldn't this be a md5 hash or similar?
And of course this feature should be removed:
@BlackDex commented on GitHub:
To be fair, all password are stored there in clear text.
Same goes for using the env variables or using docker-compose.yml.
You should take care of the security of the server it self and not expose this items.
Also, why should you want to remove that specific feature?
And, it doesn't really matter if you change that token to an sha hash (md5 should never be used again) it won't give you that much extra security. Since if someone has access to those files, that means they have access to your server already which is probably a greater problem then that specific string of random chars being exposed.
There is a feature request already to add some extra login options to the admin, which until now hasn't been picked-up yet.
@BlackDex commented on GitHub:
I agree, but that could be close to impossible sometimes. Though good design is half the job done. Same goes for backups, encrypting them and storing them off-site is half the job done on having it safe.
Filezilla is using a master-password, which you either provide during startup of Filezilla or when you start the connection. Or, if I'm correct, it uses the keychain/keystore provide by the os/platform when available which unlocks when you login to your desktop account.
While this works great for interactive software on either GUI or CLI software, it isn't very helpful on server/deamonised software. Because that would need the password during startup. Something like this was the case long time ago when people though it would be good to put a password on there website keyfile, which then required you to provide a password at ever restart of Apache httpd.
In the end you need to provide a password or keyfile which is able to be used to decrypt/encrypt the secure values. And that needs user interaction or it needs the secret key to be stored as plain text somewhere. An other way would maybe be using some kind of public/private key, which then still needs to be stored near the server to be used, which gets you right back at the whole storie.
In theorie changing the url/domain doesn't do that much harm, it could prevent MFA to work, and attachments fail to download. Though mails could point people to a different domain which could pose a risk when people do not validate and check this.
It is only used to access the admin indeed. But if you don't want it plain text, as you probably also don't want the smtp password, hibp api key, duo secret key etc.. which are also stored in the confIg.json, then the only way is to encrypt the whole config.json file. Which then needs something to be used to encrypt and decrypt that file which needs to be available by the software, and probably you want that backed-up also.
In the end, if you do not want to have to interactivaly provide a password, you need some way to decrypt/encrypt the values stored in plain text.
Sure!! No problem.
@mgutt commented on GitHub:
Are they?! Why? I would expect AES encrypt/decrypt in the database for user passwords (de-/encrypted by user password) and a hash for the admin token.
If there is a security hole in the WebUI/Webserver/Linux, which allows loading specific files or direct access to the database, you wouldn't have access to the clear text passwords. Another scenario are stolen backups (which include the vaultwarden container). And no admin should have access to passwords of their users. IMHO this is obvious.
If you get access to a clear text password, then you have it. If you get access to an AES decrypted binary value, you need to bruteforce it. And depending on the strength of the user's password, this is an impossible task.
IMHO md5 with a salt is as safe as any other hash algorithm. But nothing speaks against using SHA.
EDIT: Does not look like the user passwords are stored in clear text?!
@BlackDex commented on GitHub:
I'm specifically talking about the config.json, everything within the database is encrypted by the Bitwarden clients.
Backups should be encrypted to in my opinion.
Well to be fair, you would only have access to the admin interface and while you can delete users etc you can't change there passwords or read the vault items or decrypt there attachments or anything.
So, to be clear, all passwords and auth credentials are encrypted within the database. All items within the config.json aren't.
While we could try to encrypt this, you still need to have a decryption key stored somewhere in plain text because the software needs to be able to decrypt/encrypt it, and if that is backed-up then you are still exposing everything. It will slow down or maybe even halt ordinary people from seeing those items. But still it will not help in fully securing it
@mgutt commented on GitHub:
Ah okay, that reassures me 😅
Software should not have security holes. That's the problem with "should".
This reminds of an issue with Filezilla. Many years they stored the passwords in clear text. Someday (around 2009) a special trojan stole all Filezilla ftp credentials and spreaded itself through many websites. It took many years until the issue was solved. Now, all credentials are encrypted, which of course does not help if the trojan is active while Filezilla is open, but in 99% of the remaining time, they were safe and since then we never heard about similar issues.
Ok, good to know. But what about changing the URL to a phishing website or changing the email settings?
I thought the admin token is only used for accessing the admin UI, why is it needed to encrypt it?
PS Thank your for your detailed answers! 🤗
@dani-garcia commented on GitHub:
I'm not really sure if an encrypted config is workable, you'd have to provide the decryption key in an env variable if you want the server to launch automatically, and at that point you can just define the whole config in env variables (or using the
_FILEvariables to load the secrets from a file).If we are to hash the admin token, I wouldn't allow the admins to pick an algorithm, I'd just use PBKDF2, which is already used for the users vaults password hashes.
@jjlin commented on GitHub:
I don't see admin token hashing as particularly useful, but if it were to be added, a relatively clean way could be to use
password-hashto hash to PHC format. It would be easy to detect whether the token is hashed or not, so people could use either hashed or unhashed tokens transparently. Perhaps there would be an extra button on the admin page to convert an unhashed token to a hashed version and save it.@AcidGreg commented on GitHub:
I also felt a bit uncomfortable with the admin token in plain sight on the filesystem. I think it is not unreasonable to also support storing it as a hash as well, maybe with an additional variable to define the behavior if necessary. Maybe something like ADMIN_TOKEN_SECURITY=plaintext(default)/MD5/etc..
I would be interested in giving it a go myself, if no one else prefers to tackle it. I don't think it would be too complicated and it'd be a nice exercise of some off work nerding. ;-)
@AcidGreg commented on GitHub:
If I understand correctly, the user then would need extra inputs (salt, etc.) and a mechanism (new web page of the app?) to produce the hash.
My thought was to use an algorithm without salting, which is far better than plaintext, but still allows for a quick conversion of a plaintext password to a hashed value using any appropriate online converter or command line / GUI tool. I was thinking convenience along avoiding the dread of the plaintext token. :D
That said... I am not very familiar with the security/cryptography fields, so I hope I am not suggesting silly things.
@mgutt commented on GitHub:
People could easily overwrite the value. No need to decrypt their password.
I would suggest if the config file contains a non-hased value, it is hashed on first login. By that the admin is able to reset it through the config file.
@BlackDex commented on GitHub:
And then still you would have your mail server password in plain text within that file. It will do you no good by only hashing that specific string of text.