VaultWarden private or public deployment?

cochon

@oloke said:
TLS client certificates are also a good way of restricting access if you're scared of 0-days on Vaultwarden server. Browsers accept those with no issue but I'm not sure if bitwarden app supports them well enough.
I made a gist on how to set it up, just in case.

Ah, you posted the same idea whilst I was typing, otherwise I wouldn't have bothered

The desktop app does work for me, but occasionally (not always) fails to provide the cert doing things that require extra connections e.g. importing JSON files.

artxs

@Kevinf100 said:
They don't hack your utility bill to pay it, they hack it for data. They get your logins they now have your name, address, number and some banking info as well. They will use this info to trick and scam others or you. Steal your instagram account? Now they try to scam your friends, post scams, or abuse whatever else they offer.

They already have that data when equifax was breached. Also, there's no info in bank logins that you can't get from stealing my bank statements mailed to the house.

As far as scamming friends etc, they're already doing that without my help and using my instagram account to do it is a distinction without a difference.

artxs

@itachikonoha said:
I respectfully disagree. One may disclose his bank account number yet may sleep peacefully but if his pronhub account gets exposed, I am sure he will have sleepless nights.

So it will be wrong to assume everything else is NOT really important.

Aha! and that is a valid point. I do nothing shameful but for those who do, some things are more important to keep secret than money.

oloke

@cochon said:

@oloke said:
TLS client certificates are also a good way of restricting access if you're scared of 0-days on Vaultwarden server. Browsers accept those with no issue but I'm not sure if bitwarden app supports them well enough.
I made a gist on how to set it up, just in case.

Ah, you posted the same idea whilst I was typing, otherwise I wouldn't have bothered

The desktop app does work for me, but occasionally (not always) fails to provide the cert doing things that require extra connections e.g. importing JSON files.

Cool! The more people using mTLS the better. Truly an underrated and undersupported technology built right into TLS

Bochi

I was also playing with the idea to switch to vaultwarden for way too long, mainly held back by security concerns.
The route I did go for now involves vaultwarden behind caddy, making use of the forward_auth directive.
Implemented a super simple Python service that processes the forward_auth request and permits clients after either "knocking" via a valid TOTP or resolved from DynDNS records (to always work automatically from home).
And when I don't want to knock from outside or some NAT magic is breaking the functionality, I just fall back to VPN...

somik

@Kevinf100 said:
Bots are trying to brute force my SSH on my severs everyday. People will certainly try vaultwarden as well with bots. They might also have random bots looking for known vulnerabilitys on a server to hope it works

Have you considered using a non standard ssh port? Seems to work wonders againsts bots. Give it a try. Instead of port 22 for ssh, use port 51322 (or any random combination of 4 to 5 digits bellow 65535).

Second, don't use any password for your ssh. Use ssh-key auth only, atleast for the root user.

@CloudHopper said:
Also, I'm pretty sure if someone roots the server that Vaultwarden is running on then they'll be able to recover the private keys and unlock the vault without having to bruteforce anything.

I thought the vault warden keys are encrypted as well and needs the user to enter the master password every time to decode the key as well as the passwords?

Also vaultwarden is much safer then hosting your passwords on lastpass, bitwarden, keeppass and other publicly accessible multi user sites that are the primary targets of hacker groups. However if you are REALLY paranoid about it, you can always carry around a battery powered raspberry pi running your private vaultwarden and it's own hidden wifi network that you can connect to to get your passwords. You can lower the wifi strength to ensure only people within 1m (3ft) of the device can connect to it.

All I am saying is that each persons use case is different. For me, I need a combination of privacy, security and ease-of-use. For others, they may let go of ease-of-use for more security. Some may even air-gap their setup, running vaultwarden in it's own isolated network. To each, their own.

Kevinf100

@somik said:

@Kevinf100 said:
Bots are trying to brute force my SSH on my severs everyday. People will certainly try vaultwarden as well with bots. They might also have random bots looking for known vulnerabilitys on a server to hope it works

Have you considered using a non standard ssh port? Seems to work wonders againsts bots. Give it a try. Instead of port 22 for ssh, use port 51322 (or any random combination of 4 to 5 digits bellow 65535).

Second, don't use any password for your ssh. Use ssh-key auth only, atleast for the root user.

@CloudHopper said:
Also, I'm pretty sure if someone roots the server that Vaultwarden is running on then they'll be able to recover the private keys and unlock the vault without having to bruteforce anything.

I thought the vault warden keys are encrypted as well and needs the user to enter the master password every time to decode the key as well as the passwords?

Also vaultwarden is much safer then hosting your passwords on lastpass, bitwarden, keeppass and other publicly accessible multi user sites that are the primary targets of hacker groups. However if you are REALLY paranoid about it, you can always carry around a battery powered raspberry pi running your private vaultwarden and it's own hidden wifi network that you can connect to to get your passwords. You can lower the wifi strength to ensure only people within 1m (3ft) of the device can connect to it.

All I am saying is that each persons use case is different. For me, I need a combination of privacy, security and ease-of-use. For others, they may let go of ease-of-use for more security. Some may even air-gap their setup, running vaultwarden in it's own isolated network. To each, their own.

Yes, but that doesn't work. Also security by obscurity is not security.

- Actions
   |- Currently banned: 0
   |- Total banned:     43
   `- Banned IP list:

Root is disable for SSH. Allow group for ssh, meaning only users with the group can ssh. Auth keys are used. But that doesn't stop people from trying.

Commend7

@somik said:
I thought the vault warden keys are encrypted as well and needs the user to enter the master password every time to decode the key as well as the passwords?

yes, with the exception of 2fa hash. there's a reason kdf algorithms exist, and you can kinda tell by how long the vault takes to unlock. which depends on your kdf（argon2id） iteration settings. i thot this was already a common knowledge among selfhosters. let's assume the scenario where the server is rooted, which is still highly unlikely since the attacker would need to:
1. target, write and compile specifically for nixos, with hardened kernel config and allat
2. escape hardened systemd service sandbox, which already provide better isolation on its own than average lazy docker setup. which is a very low bar tbh
3. escape ephemeral microvm, otherwise, no matter what you try, the executable files are mounted as ro anyway.
4. even the host os uses tmpfs for the root, with specific directories mounted from /persist btrfs subvolume. the attacker's script must be tailored to my exact setup in order to even work.
5. assuming the attacker managed to escalate to root privilege in my hypervisor parent at this point, and my idps (admittedly the setup is still pretty basic atm) didn't trigger, your password is still hashed. they'll need to swap in a malicious version of the webvault. but now it's finally a valid concern. upcoming oidc pr might be worth a look as a mitigation?

i'm just tired of the crowd that acts like slapping everything behind vpn is the only logically correct way. sure, it's easier for beginners just starting out. but in the long term, gatekeeping an enduser service behind vpn doesn't make sense at all. terrible ux. might as well go back to saas offerings at this point. even google doesn't do that for their internal services.

CloudHopper

@Commend7 said:

@somik said:
I thought the vault warden keys are encrypted as well and needs the user to enter the master password every time to decode the key as well as the passwords?

yes, with the exception of 2fa hash. there's a reason kdf algorithms exist, and you can kinda tell by how long the vault takes to unlock. which depends on your kdf（argon2id） iteration settings. i thot this was already a common knowledge among selfhosters. let's assume the scenario where the server is rooted, which is still highly unlikely since the attacker would need to:
1. target, write and compile specifically for nixos, with hardened kernel config and allat
2. escape hardened systemd service sandbox, which already provide better isolation on its own than average lazy docker setup. which is a very low bar tbh
3. escape ephemeral microvm, otherwise, no matter what you try, the executable files are mounted as ro anyway.
4. even the host os uses tmpfs for the root, with specific directories mounted from /persist btrfs subvolume. the attacker's script must be tailored to my exact setup in order to even work.
5. assuming the attacker managed to escalate to root privilege in my hypervisor parent at this point, and my idps (admittedly the setup is still pretty basic atm) didn't trigger, your password is still hashed. they'll need to swap in a malicious version of the webvault. but now it's finally a valid concern. upcoming oidc pr might be worth a look as a mitigation?

i'm just tired of the crowd that acts like slapping everything behind vpn is the only logically correct way. sure, it's easier for beginners just starting out. but in the long term, gatekeeping an enduser service behind vpn doesn't make sense at all. terrible ux. might as well go back to saas offerings at this point. even google doesn't do that for their internal services.

I was referring to rooting the host VM, (not the docker container or the Hypervisor), and once you've got root on the host you can either dump the memory heap and comb it for private keys, hijack an existing session, sniff the traffic, (which can be decrypted thanks to access to the SSL certs), or just reset the Admin Token and let yourself into the Panel, (although Panel access wouldn't give you access to the Vault, it would only let you delete it).

Also, no company I've ever worked for allows their Vaults to be accessed externally, and I've never encountered a company that isn't using a VPN solution to provide access to their internal network, so I'm not sure I understand your point about Google.

The most basic tenet of cyber security is defense in depth, which is why sensitive services like Vaults and Password Managers are always kept hidden from external access. That's not gatekeeping, it's just common sense because if your host gets compromised then both you and your users are screwed, which is the worst UX imaginable.

Commend7

@CloudHopper said:

@Commend7 said:

@somik said:
I thought the vault warden keys are encrypted as well and needs the user to enter the master password every time to decode the key as well as the passwords?

yes, with the exception of 2fa hash. there's a reason kdf algorithms exist, and you can kinda tell by how long the vault takes to unlock. which depends on your kdf（argon2id） iteration settings. i thot this was already a common knowledge among selfhosters. let's assume the scenario where the server is rooted, which is still highly unlikely since the attacker would need to:
1. target, write and compile specifically for nixos, with hardened kernel config and allat
2. escape hardened systemd service sandbox, which already provide better isolation on its own than average lazy docker setup. which is a very low bar tbh
3. escape ephemeral microvm, otherwise, no matter what you try, the executable files are mounted as ro anyway.
4. even the host os uses tmpfs for the root, with specific directories mounted from /persist btrfs subvolume. the attacker's script must be tailored to my exact setup in order to even work.
5. assuming the attacker managed to escalate to root privilege in my hypervisor parent at this point, and my idps (admittedly the setup is still pretty basic atm) didn't trigger, your password is still hashed. they'll need to swap in a malicious version of the webvault. but now it's finally a valid concern. upcoming oidc pr might be worth a look as a mitigation?

i'm just tired of the crowd that acts like slapping everything behind vpn is the only logically correct way. sure, it's easier for beginners just starting out. but in the long term, gatekeeping an enduser service behind vpn doesn't make sense at all. terrible ux. might as well go back to saas offerings at this point. even google doesn't do that for their internal services.

I was referring to rooting the host VM, (not the docker container or the Hypervisor), and once you've got root on the host you can either dump the memory heap and comb it for private keys, hijack an existing session, sniff the traffic, (which can be decrypted thanks to access to the SSL certs), or just reset the Admin Token and let yourself into the Panel, (although Panel access wouldn't give you access to the Vault, it would only let you delete it).

Also, no company I've ever worked for allows their Vaults to be accessed externally, and I've never encountered a company that isn't using a VPN solution to provide access to their internal network, so I'm not sure I understand your point about Google.

The most basic tenet of cyber security is defense in depth, which is why sensitive services like Vaults and Password Managers are always kept hidden from external access. That's not gatekeeping, it's just common sense because if your host gets compromised then both you and your users are screwed, which is the worst UX imaginable.

i'm not sure whats your point. first and foremost, the user database itself isn't decrypted server side,
this should be a common knowledge. second, google has moved to BeyondCorp after Operation Aurora incident in 2009, but that's not the point, we are talking about enduser service meant to be accessed from outside of the infrastructure. we are not talking about openbao/hashicorp vault here. you just keep repeating the same point, which has been already invalidated without adding any extra context.
also,

I was referring to rooting the host VM,

half of my previous comment was about how that is very unlikely if you do the absolute minimum to secure. and suggesting what is the remaining valid concerns assuming the worst case happened.

jmgcaguicla

@CloudHopper said:
I was referring to rooting the host VM, (not the docker container or the Hypervisor), and once you've got root on the host you can either dump the memory heap and comb it for private keys, hijack an existing session, sniff the traffic, (which can be decrypted thanks to access to the SSL certs)

None of these matter as nothing confidential flies over the wire. Scan the host memory all you want, decrypt packets to your heart's content if you have the TLS session key, you won't find anything. The vault (see /api/sync endpoint) is decrypted locally by the client.

The only (somewhat) realistic threat here is getting served a hosed copy of the client (e.g., the extension or the Web UI) that will leak the user's symmetric key or the master password upon input.

bustersg

I made a gist on how to set it up, just in case.

Anyway - I think it's fine to be a public deployment but ultimately it's up to you.

Saw the video, my company laptop also have certain in-house certs installed. May be a bit harder for me because my VW in k3s cluster but I will definely explore this mTLS.

@febryanvaldo said:
I deploy publicly but with extra protection, basic HTTP Auth.

For now short term, since VW already deployed, I think add basic HTTP Auth is good enough.> @trew said:

@bustersg said:

I deployed a public facing VW ....I dont need access password outside as I have my mobile brower save login passwords.

Advice?

You sat you don't need to access it but have made it public?

I meant all my login are saved under Chrome password manager. The reason I deploy VW now is because for the past 10 yrs i been accumulating logins as contacts in my mobile phonebook with underscores (e.g. username: _u_ss/ pwd: bb_aa_13) in my mobile in case i lost my mobile. But I feel it got to stop because chatgpt says "an app may ask permission to access your phone contact @.@"

somik

@Commend7 said:

@CloudHopper said:

@Commend7 said:

@somik said:
I thought the vault warden keys are encrypted as well and needs the user to enter the master password every time to decode the key as well as the passwords?

yes, with the exception of 2fa hash. there's a reason kdf algorithms exist, and you can kinda tell by how long the vault takes to unlock. which depends on your kdf（argon2id） iteration settings. i thot this was already a common knowledge among selfhosters. let's assume the scenario where the server is rooted, which is still highly unlikely since the attacker would need to:
1. target, write and compile specifically for nixos, with hardened kernel config and allat
2. escape hardened systemd service sandbox, which already provide better isolation on its own than average lazy docker setup. which is a very low bar tbh
3. escape ephemeral microvm, otherwise, no matter what you try, the executable files are mounted as ro anyway.
4. even the host os uses tmpfs for the root, with specific directories mounted from /persist btrfs subvolume. the attacker's script must be tailored to my exact setup in order to even work.
5. assuming the attacker managed to escalate to root privilege in my hypervisor parent at this point, and my idps (admittedly the setup is still pretty basic atm) didn't trigger, your password is still hashed. they'll need to swap in a malicious version of the webvault. but now it's finally a valid concern. upcoming oidc pr might be worth a look as a mitigation?

i'm just tired of the crowd that acts like slapping everything behind vpn is the only logically correct way. sure, it's easier for beginners just starting out. but in the long term, gatekeeping an enduser service behind vpn doesn't make sense at all. terrible ux. might as well go back to saas offerings at this point. even google doesn't do that for their internal services.

I was referring to rooting the host VM, (not the docker container or the Hypervisor), and once you've got root on the host you can either dump the memory heap and comb it for private keys, hijack an existing session, sniff the traffic, (which can be decrypted thanks to access to the SSL certs), or just reset the Admin Token and let yourself into the Panel, (although Panel access wouldn't give you access to the Vault, it would only let you delete it).

Also, no company I've ever worked for allows their Vaults to be accessed externally, and I've never encountered a company that isn't using a VPN solution to provide access to their internal network, so I'm not sure I understand your point about Google.

The most basic tenet of cyber security is defense in depth, which is why sensitive services like Vaults and Password Managers are always kept hidden from external access. That's not gatekeeping, it's just common sense because if your host gets compromised then both you and your users are screwed, which is the worst UX imaginable.

i'm not sure whats your point. first and foremost, the user database itself isn't decrypted server side,
this should be a common knowledge. second, google has moved to BeyondCorp after Operation Aurora incident in 2009, but that's not the point, we are talking about enduser service meant to be accessed from outside of the infrastructure. we are not talking about openbao/hashicorp vault here. you just keep repeating the same point, which has been already invalidated without adding any extra context.
also,

I was referring to rooting the host VM,

half of my previous comment was about how that is very unlikely if you do the absolute minimum to secure. and suggesting what is the remaining valid concerns assuming the worst case happened.

Lets say you are hosting vaultwarden from your home network. How do you access the vaultwarden web ui over the internet when it is hosted in your docker container? Are you using a SSL certificate on vaultwarden container itself or is your data still going over plaintext? What I see in most cases is that some type of reverse proxy is run on a docker container and the reverse proxy communicates with the other docker container over LOCAL network in HTTP. So why would a hacker need to hack your secure server when he can hack your IoT device, like fridge, IP cam, dishwasher, router, NAS or any of the other 50+ devices you have on your network that are much less secure? All they need is to access these devices and put a traffic sniffer.

So I agree with @Commend7 here. Dont go crazy for security on your server cause the hacker will ALWAYS exploit the weakest link. It could be something as simple as spoofing a github commit on vaultwarden github repo. They did it for one of the linux packages already...

wadhah

@febryanvaldo said:
I deploy publicly but with extra protection, basic HTTP Auth.

Just for your information, http basic auth is not secure at all (especially over http). It's just the most basic form of security.

It can be brute forced in hours/days.

Commend7

@somik said:

@Commend7 said:

@CloudHopper said:

@Commend7 said:

@somik said:
I thought the vault warden keys are encrypted as well and needs the user to enter the master password every time to decode the key as well as the passwords?

yes, with the exception of 2fa hash. there's a reason kdf algorithms exist, and you can kinda tell by how long the vault takes to unlock. which depends on your kdf（argon2id） iteration settings. i thot this was already a common knowledge among selfhosters. let's assume the scenario where the server is rooted, which is still highly unlikely since the attacker would need to:
1. target, write and compile specifically for nixos, with hardened kernel config and allat
2. escape hardened systemd service sandbox, which already provide better isolation on its own than average lazy docker setup. which is a very low bar tbh
3. escape ephemeral microvm, otherwise, no matter what you try, the executable files are mounted as ro anyway.
4. even the host os uses tmpfs for the root, with specific directories mounted from /persist btrfs subvolume. the attacker's script must be tailored to my exact setup in order to even work.
5. assuming the attacker managed to escalate to root privilege in my hypervisor parent at this point, and my idps (admittedly the setup is still pretty basic atm) didn't trigger, your password is still hashed. they'll need to swap in a malicious version of the webvault. but now it's finally a valid concern. upcoming oidc pr might be worth a look as a mitigation?

i'm just tired of the crowd that acts like slapping everything behind vpn is the only logically correct way. sure, it's easier for beginners just starting out. but in the long term, gatekeeping an enduser service behind vpn doesn't make sense at all. terrible ux. might as well go back to saas offerings at this point. even google doesn't do that for their internal services.

I was referring to rooting the host VM, (not the docker container or the Hypervisor), and once you've got root on the host you can either dump the memory heap and comb it for private keys, hijack an existing session, sniff the traffic, (which can be decrypted thanks to access to the SSL certs), or just reset the Admin Token and let yourself into the Panel, (although Panel access wouldn't give you access to the Vault, it would only let you delete it).

Also, no company I've ever worked for allows their Vaults to be accessed externally, and I've never encountered a company that isn't using a VPN solution to provide access to their internal network, so I'm not sure I understand your point about Google.

The most basic tenet of cyber security is defense in depth, which is why sensitive services like Vaults and Password Managers are always kept hidden from external access. That's not gatekeeping, it's just common sense because if your host gets compromised then both you and your users are screwed, which is the worst UX imaginable.

i'm not sure whats your point. first and foremost, the user database itself isn't decrypted server side,
this should be a common knowledge. second, google has moved to BeyondCorp after Operation Aurora incident in 2009, but that's not the point, we are talking about enduser service meant to be accessed from outside of the infrastructure. we are not talking about openbao/hashicorp vault here. you just keep repeating the same point, which has been already invalidated without adding any extra context.
also,

I was referring to rooting the host VM,

half of my previous comment was about how that is very unlikely if you do the absolute minimum to secure. and suggesting what is the remaining valid concerns assuming the worst case happened.

Lets say you are hosting vaultwarden from your home network. How do you access the vaultwarden web ui over the internet when it is hosted in your docker container? Are you using a SSL certificate on vaultwarden container itself or is your data still going over plaintext? What I see in most cases is that some type of reverse proxy is run on a docker container and the reverse proxy communicates with the other docker container over LOCAL network in HTTP. So why would a hacker need to hack your secure server when he can hack your IoT device, like fridge, IP cam, dishwasher, router, NAS or any of the other 50+ devices you have on your network that are much less secure? All they need is to access these devices and put a traffic sniffer.

So I agree with @Commend7 here. Dont go crazy for security on your server cause the hacker will ALWAYS exploit the weakest link. It could be something as simple as spoofing a github commit on vaultwarden github repo. They did it for one of the linux packages already...

ironically i'm the crazy one who do ssl cert between vaultwarden microvm and caddy vps running nixos because why not, it's only 20 loc or so. but yea good point, in the case of vaultwarden/bitwarden, server should be the least of your concern. look into graphene os/at least ios, and for desktop run secureblue, hardened nixos, qubes os, kicksecure, etc depending on your threat model, if you really want to go crazy.

CloudHopper

@jmgcaguicla said:

@CloudHopper said:
I was referring to rooting the host VM, (not the docker container or the Hypervisor), and once you've got root on the host you can either dump the memory heap and comb it for private keys, hijack an existing session, sniff the traffic, (which can be decrypted thanks to access to the SSL certs)

None of these matter as nothing confidential flies over the wire. Scan the host memory all you want, decrypt packets to your heart's content if you have the TLS session key, you won't find anything. The vault (see /api/sync endpoint) is decrypted locally by the client.

The only (somewhat) realistic threat here is getting served a hosed copy of the client (e.g., the extension or the Web UI) that will leak the user's symmetric key or the master password upon input.

I can think of countless realistic threats once the host server has been rooted by a malicious actor.

For example, it would be trivial to switch the Vaultwarden container with an EvilNginx phishing portal. Just invalidate the old sessions and then wait for the user creds to come rolling in so you can decrypt their Vault data.

So, as I keep saying, once the host server has been rooted then all bets are off

somik

@Commend7 said:
ironically i'm the crazy one who do ssl cert between vaultwarden microvm and caddy vps running nixos because why not, it's only 20 loc or so. but yea good point, in the case of vaultwarden/bitwarden, server should be the least of your concern. look into graphene os/at least ios, and for desktop run secureblue, hardened nixos, qubes os, kicksecure, etc depending on your threat model, if you really want to go crazy.

Naa, i'll stick to my windows desktop with browser addon for bitwarden (can be used with vaultwarden as well) along with using public open wifi on my old android phone when outside to connect to vaultwarden without any proxy

The minimum protection i used is use a nginx reverse proxy manager running in the same docker host that connects to vaultwarden over private internal docker network. Other then that, I'll just remember my important passwords like bank details, work emails and my own private email. The rest can be exposed. If my LET account gets hacked, I can always just create a new one or stop using LET. No big deal.

cochon

@CloudHopper said:

@jmgcaguicla said:
None of these matter as nothing confidential flies over the wire. Scan the host memory all you want, decrypt packets to your heart's content if you have the TLS session key, you won't find anything. The vault (see /api/sync endpoint) is decrypted locally by the client.

The only (somewhat) realistic threat here is getting served a hosed copy of the client (e.g., the extension or the Web UI) that will leak the user's symmetric key or the master password upon input.

I can think of countless realistic threats once the host server has been rooted by a malicious actor.

For example, it would be trivial to switch the Vaultwarden container with an EvilNginx phishing portal. Just invalidate the old sessions and then wait for the user creds to come rolling in so you can decrypt their Vault data.

So, as I keep saying, once the host server has been rooted then all bets are off

But the creds don't roll in..., apart from the web UI, the clients are sourced from Bitwarden not the self hosted VW server, and the server only ever sees/stores encrypted information, encrypted at the client not in the server.

It's more like zero knowledge end to end encryption in a messaging app, you could run your VW service in a glass display case for all to watch with no risk. As @jmgcaguicla says the only risk from a VW hack is a modification to the web interface it serves, which is why I prefer to use the vanilla BW apps and plugins after initial setup.

jmgcaguicla

@CloudHopper said:

@jmgcaguicla said:

@CloudHopper said:
I was referring to rooting the host VM, (not the docker container or the Hypervisor), and once you've got root on the host you can either dump the memory heap and comb it for private keys, hijack an existing session, sniff the traffic, (which can be decrypted thanks to access to the SSL certs)

None of these matter as nothing confidential flies over the wire. Scan the host memory all you want, decrypt packets to your heart's content if you have the TLS session key, you won't find anything. The vault (see /api/sync endpoint) is decrypted locally by the client.

The only (somewhat) realistic threat here is getting served a hosed copy of the client (e.g., the extension or the Web UI) that will leak the user's symmetric key or the master password upon input.

I can think of countless realistic threats once the host server has been rooted by a malicious actor.

For example, it would be trivial to switch the Vaultwarden container with an EvilNginx phishing portal. Just invalidate the old sessions and then wait for the user creds to come rolling in so you can decrypt their Vault data.

So, as I keep saying, once the host server has been rooted then all bets are off

That's not unique to Vaultwarden, that's for literally every application ever you stupid fuck; Vaultwarden is just more slightly resistant as long as you trust the client (hint: the web vault is not the only client).

The discussion stemmed from the incompetent idea of locking out every service behind a VPN just because you don't understand how they work, which does fuck all if the host is compromised. Stop moving the goalpost.

CloudHopper

@jmgcaguicla said:

@CloudHopper said:

@jmgcaguicla said:

@CloudHopper said:
I was referring to rooting the host VM, (not the docker container or the Hypervisor), and once you've got root on the host you can either dump the memory heap and comb it for private keys, hijack an existing session, sniff the traffic, (which can be decrypted thanks to access to the SSL certs)

None of these matter as nothing confidential flies over the wire. Scan the host memory all you want, decrypt packets to your heart's content if you have the TLS session key, you won't find anything. The vault (see /api/sync endpoint) is decrypted locally by the client.

The only (somewhat) realistic threat here is getting served a hosed copy of the client (e.g., the extension or the Web UI) that will leak the user's symmetric key or the master password upon input.

I can think of countless realistic threats once the host server has been rooted by a malicious actor.

For example, it would be trivial to switch the Vaultwarden container with an EvilNginx phishing portal. Just invalidate the old sessions and then wait for the user creds to come rolling in so you can decrypt their Vault data.

So, as I keep saying, once the host server has been rooted then all bets are off

That's not unique to Vaultwarden, that's for literally every application ever you stupid fuck; Vaultwarden is just more slightly resistant as long as you trust the client (hint: the web vault is not the only client).

The discussion stemmed from the incompetent idea of locking out every service behind a VPN just because you don't understand how they work, which does fuck all if the host is compromised. Stop moving the goalpost.

There's no need to be aggressive. I mentioned a rooted server in my initial comment so I'm not sure what you mean by saying I'm moving the goalposts.

My point is simply, you can either:

A ) Publicise your instance IP with a DNS record and leave the interface visible to web scrapers/bots etc.

or

B ) Not do that by using a VPN

Option A invites attention and attempts to root your server, especially if an exploit drops, whereas Option B doesn't. How much that matters very much depends on your perspective.

But honestly, it's just not that important. People can set things up however they want, based on their own specific requirements, and it's not my place to judge whether they're doing it "right" or not.