Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

github.com

Post reply on HN
Print view View original

121–130 of 162 posts

Re: Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

#121

Post by AnIdiotOnTheNet »

denysvitali wrote: post #88
AnIdiotOnTheNet wrote: post #85

Earlier quoted context omitted.

Maybe you didn't get the whole "I picked it because it was easy to install" part. Building software from source is pretty much the exact opposite of that.

It really depends. Go and Rust softwares are generally easy to build from source

I was trying out a bunch of different similar products, I was not going to set up a build environment just to test software. I immediately disqualified anything that required I build it from source.

Of the ones that didn't, very few had working install documentation and I wasn't going to fix it for them just to try out their product. I did open issues on their trackers about it for them, not that they cared since nothing has been done.

Bitwarden_rs was the one that had working install documentation that didn't require a build environment. It met our requirements in testing, so I deployed it to production.

Re: Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

#122

Post by sneak »

RedComet wrote: post #110
sneak wrote: post #58

Earlier quoted context omitted.

You are misunderstanding the issue. It's not asking before the update (as most programs that prompt you to update do). By the time that dialog box is displayed, the application has already replaced itself on disk (with code chosen arbitrarily by the bitwarden developers, or anyone in possession of their credentials), and the new code will be executed automatically without user intervention the next time the app is la…

Why don't you just disable the updater then? https://github.com/bitwarden/desktop/issues/552#issuecomment...

There's no good way to set env vars for GUI apps on macOS. I just run a private fork that patches out all of their hostnames.

Re: Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

#123

Post by sneak »

viro wrote: post #81
sneak wrote: post #58

Earlier quoted context omitted.

You are misunderstanding the issue. It's not asking before the update (as most programs that prompt you to update do). By the time that dialog box is displayed, the application has already replaced itself on disk (with code chosen arbitrarily by the bitwarden developers, or anyone in possession of their credentials), and the new code will be executed automatically without user intervention the next time the app is la…

This is NOT a RCE. Would you like me to list all of the software that does this exact thing? Chrome, Brave, Discord are some of the biggest. Nearly all electron based apps that autoupdate.

You forgot the Creative Cloud, iOS (autoupdates on by default), and the Play Store.

Those are RCE vulnerabilities, as well. Platform vendors love being able to execute whatever they like on the advertising consumption devices that don't belong to them.

Just because it feels like a different thing because it's the vendor (only in theory - TAO would like to have a word with you) doesn't make it any less a vulnerability, or any less an RCE by the strict definition. Installing the client is equivalent to installing a RAT onto your machine: it can be remotely controlled to execute any code or tools the other end wants.

Re: Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

#124

Post by sneak »

UncleMeat wrote: post #73
teekert wrote: post #63

Earlier quoted context omitted.

Ah yes, the trust-the-developers-blindly vs patch asap vs supply chain attack risks. I wonder if we have any data on what is best. I once had to re-do a Drupal install because it was very likely already being abused. Would have liked immediate auto-update in that case. Ah well.

It isn't universal, but browsers surely provide a good case study here. Most of them auto-update today. In the past, exploitation via bugs where patches existed but people didn't update was measurably common. Supply chain attacks against autoupdating browsers haven't really materialized. If the goal is to prevent the most volume of exploitation, autoupdaters clearly win.

Browser vendors have teams of experienced and professional security engineers several orders of magnitude larger than the entire Bitwarden organization. They're also bound by US law.

Re: Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

#125

Post by sneak »

teekert wrote: post #74
sneak wrote: post #69

Earlier quoted context omitted.

Password managers and OSes are things that I do not want automatically updating at the whims of some remote/foreign party whom I have never met and is bound by a set of responsibilities and laws with which I am entirely unfamiliar. Network services open to the internet at large are a horse of a different color. Ultimately, though, they could just ask. Most users probably want autoupdate, and they can opt in to that i…

And yet you are using a product at the whims of some remote/foreign party whom you have never met and is bound by a set of responsibilities and laws with which you are entirely unfamiliar. I get where you are coming from, but you clinking "update" in stead of the dev does not guarantee the safety of the update.

This is a false dichotomy. Nobody is claiming that mindlessly clicking "update" guarantees safety.

I run a private fork of the bitwarden client, anyway. Their stock one partially trusts the iteration count of the PBKDF provided by the server, and can be tricked into sending a low-iteration hash of the master password.

Re: Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

#126

Post by freeopinion »

eeZah7Ux wrote: post #31
colejohnson66 wrote: post #30

Earlier quoted context omitted.

Because sometimes people do things just because they can. Not every programming project needs to make sense.

Unfortunately fragmenting the opensource ecosystem with too many implementations harms it.

I feel the same way about ice cream. Why are there 8 different types of vanilla ice cream, including 4 from the same brand? French Vanilla, Canadian Vanilla, Vanilla Bean, Double Churned Vanilla, 3 different plain Vanilla.

This harms the ice cream ecosystem.

Re: Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

#127

Post by viro »

sneak wrote: post #123
viro wrote: post #81

Earlier quoted context omitted.

This is NOT a RCE. Would you like me to list all of the software that does this exact thing? Chrome, Brave, Discord are some of the biggest. Nearly all electron based apps that autoupdate.

You forgot the Creative Cloud, iOS (autoupdates on by default), and the Play Store. Those are RCE vulnerabilities, as well. Platform vendors love being able to execute whatever they like on the advertising consumption devices that don't belong to them. Just because it feels like a different thing because it's the vendor (only in theory - TAO would like to have a word with you) doesn't make it any less a vulnerability…

Thats not how the definition of RCE works. Under your silly logic every piece of server/client software is a "RAT". To be honest I feel like you're trying to speed run ur way to the Attrition Hall of Charlatans

Re: Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

#128

Post by [deleted] »

zzyzxd wrote: post #117
arsome wrote: post #106

Earlier quoted context omitted.

Just set up backups, enable apt unattended upgrades for major security patches and forget the rest. If you want to really get paranoid, pass it all through wireguard or ssh tunnels, but for bitwarden at least it's all client side encrypted anyways, you could probably run it on a very out of date system without issue.

Sure. But do you constantly verify backups, check hard drive health and file corruptions, practice disaster recovery? And these are just for the integrity of your _encrypted_ data. There are a lot more to do to fully secure your home infra in general. How do you secure your wireguard client key on the go? Do you monitor access logs? What about Guest Wi-Fi access, vlan separation... I don't know if worrying about all…

[deleted]

Re: Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

#129

Post by [deleted] »

zzyzxd wrote: post #117
arsome wrote: post #106

Earlier quoted context omitted.

Just set up backups, enable apt unattended upgrades for major security patches and forget the rest. If you want to really get paranoid, pass it all through wireguard or ssh tunnels, but for bitwarden at least it's all client side encrypted anyways, you could probably run it on a very out of date system without issue.

Sure. But do you constantly verify backups, check hard drive health and file corruptions, practice disaster recovery? And these are just for the integrity of your _encrypted_ data. There are a lot more to do to fully secure your home infra in general. How do you secure your wireguard client key on the go? Do you monitor access logs? What about Guest Wi-Fi access, vlan separation... I don't know if worrying about all…

[deleted]

Re: Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust

#130

Post by amaccuish »

mjthompson wrote: post #98
alias_neo wrote: post #94

Earlier quoted context omitted.

Bingo. If you're going to host services as home such as your password manager, set up a WireGuard VPN, you can use a Pi and it'll be perfectly sufficient, leave only the VPN open on the internet, VPN in from your phone, laptop, whatever for anything you need access to, and you don't need to rely on Nextcloud or Bitwarden having vulnerabilities discovered in them. I was using Nextcloud previously for password sync bec…

Why would you mount read only, out of interest? How do you keep packages up to date? And what about logging? I'd want to be logging connection attempts.

probably to save the SD card
Post reply on HN