[Fnoord]

Bitwarden has also had an external audit.

With regards to Bitwarden, it has a wordphrase on the account which only you know. You can verify this when you connect to the cloud. You can run the server within your own cloud.

With the cloud, you can assume that the government has access to the encrypted database. If you have a strong password, it will take them longer to brute-force your database. We are talking about two governments here: the US government (most password managers are from US companies and are hosted in US clouds) and your own (who can attempt to ask for the data), this is no issue, but I believe you should by default not trust them. This is important because it should be part of your risk assessment.

It would probably be easier to attempt a MITM (with help of the password manager sysadmin). I've once seen a fake Lastpass login page (back when I used Lastpass).

Almost all password managers can import/export their database to CSV. This allows you to avoid a vendor lock-in.

[octosphere]

> You can run the server within your own cloud

For me there is a tradeoff. On one hand, Bitwarden's online offering where you trust them with your data is convenient, but also a single point of failure. If their server goes offline, you can't access your passwords (And servers do go down). On the other hand you can repair your own instance if it goes down and have full control over it. The only caveat with self-hosting being the overhead. Regular non-techie people just don't have the time or intellectual curiosity to experiment with self-hosting. For me personally I just sync a Keepass database with Dropbox and call it a day.

[Fnoord]

Agreed w/your post in general.

> On one hand, Bitwarden's online offering where you trust them with your data is convenient, but also a single point of failure.

Put your network connectivity off, and try to relogin to Bitwarden. It will work. I just tried it. The only downside is that the database might not be synced (which, I admit, can be a problem).

> The only caveat with self-hosting being the overhead. Regular non-techie people just don't have the time or intellectual curiosity to experiment with self-hosting.

I don't know the password to connect to my (hypothetical) self-hosted Bitwarden instance. Because of the above though, that would not be an issue.

Hence I am going to switch to self-hosting. There's a Rust implementation with Docker image.

[benhurmarcel]

>Put your network connectivity off, and try to relogin to Bitwarden. It will work.

That's correct, but the parent comment is also correct about the single point of failure. The Bitwarden server could erase your database for some reason (bug, hack…), and it would sync on all your devices, erasing all your data.

[faitswulff]

What operational security risks do you have to be aware of when self hosting passwords?

[Fnoord]

This is a great question which everyone should ask themselves.

It has to be user-friendly enough (which Bitwarden IMO is). You need to do a CIA threat assessment yourself.

Confidentiality I solve by using WireGuard; hence I don't mind if I use HTTP or HTTPS with self signed certificate. You might be able to use Lets Encrypt instead. Integrity I solve with offsite backups of the most important data. Availability is solved by having decent uptime on my cable provider, about 25 mbit upload. I also used RAID1 on my server. My server is a Synology NAS with Docker.

If that gets compromised by hackers, they have access to private data of mine anyway. If you include the government in your threat assessment they are very likely able to get access to your server (VPS or my example). That is why I prefer to stick to my local government/jurisdiction. I'm already bound by them anyway. If they want to screw me over (including working together with US government) they can and (since we are part of Nine Eyes) likely will.

YMW(ill)V

[anarazel]

> With the cloud, you can assume that the government has access to the encrypted database. If you have a strong password, it will take them longer to brute-force your database. We are talking about two governments here: the US government (most password managers are from US companies and are hosted in US clouds) and your own (who can attempt to ask for the data), this is no issue, but I believe you should by default not trust them. This is important because it should be part of your risk assessment.

If it were just the risk of brute-forcing, I have a hard time believing this to be a real problem. Use a secure enough passphrase etc (and if that's not good enough, they could also just brute force into most of your accounts anyway). IMO the relevant thread model is more that they can convince / coerce / do it themselves the provider to change the javascript that does the client side decryption.

I use bitwarden for a good fraction of my login data, because I don't currently consider this part of my thread model...

I'm not fully convinced by bitwarden, especially the 2nd factor integration IMO isn't good enough. But I've not had enough to time to look much further.

I wish there were something that used (as a second round of encryption) a key residing on a yubikey to decrypt the password of individual entries, without going through gpg. Going through gpg just seems to complicated and fragile to me, and has annoying restrictions like not really allowing multiple yubikeys.

[Fnoord]

> IMO the relevant thread model is more that they can convince / coerce / do it themselves the provider to change the javascript that does the client side decryption.

Yes, this is the MITM I referred to in another post. I'm not sure the fingerprint phrase [1] is adequate to mitigate that danger

> I wish there were something that used (as a second round of encryption) a key residing on a yubikey to decrypt the password of individual entries, without going through gpg. Going through gpg just seems to complicated and fragile to me, and has annoying restrictions like not really allowing multiple yubikeys.

I currently use 2 YubiKeys with OTP and 2 YubiKeys plus 2 Solos with FIDO U2F on top of an Authenticator App as backup. There's backup codes as well. E-mail or SMS I prefer not to use (they don't provide SMS AFAIK but do provide Duo). I plan on fine-tuning this once I receive my new smartphone with NFC and my Somu; then I will likely remove some of these keys, reset them, and sell them.

[1] https://help.bitwarden.com/article/fingerprint-phrase/