[HN Gopher] Bitwarden_rs: Unofficial Bitwarden compatible server...
___________________________________________________________________
Bitwarden_rs: Unofficial Bitwarden compatible server written in
Rust
Author : xearl
Score : 215 points
Date : 2021-03-18 10:18 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| teekert wrote:
| I set it up in a couple of minutes using Docker-compose with
| Traefik. I love that Bitwarden has clients and plugins everywhere
| (FF and iOS being most relevant to me) and I can self-host. The
| sweetspot for me. I have had too many conflicts with my KeepassXC
| database on Nextcloud in the past, time for a solution with
| integrated sync.
|
| Btw the "custom server" setting is a bit hidden, it is behind the
| cogwheel in the upper left in most cases.
| AnIdiotOnTheNet wrote:
| My company used to use the unmaintained "CorporateVault", but
| switched to Bitwarden_rs after Flash (which CorporteVault used
| for copying to the clipboard) was deprecated. Bitwarden_rs was
| chosen because it had a relatively painless install compared to
| pretty much everything else I looked at, requiring only one
| Docker container. It's not bad.
| rubatuga wrote:
| You don't even need docker if you build from source
| AnIdiotOnTheNet wrote:
| 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.
| rubatuga wrote:
| Lmfao, you assume that docker is easy to install
| vangelis wrote:
| It's not?
| AnIdiotOnTheNet wrote:
| Docker was an apt install, it wasn't exactly what I would
| call difficult.
| smoldesu wrote:
| Rust is designed to be built from source, and the
| development toolchain is light enough to keep on a VPS if
| that's your bag. If you have Cargo installed, compiling and
| installing from source is easier than using NPM.
| alias_neo wrote:
| > and the development toolchain is light enough to keep
| on a VPS
|
| Or, you know, in a Docker container...
|
| I build pretty much everything that's not C/C++ and/or Go
| using a Docker container now.
|
| When you're working in a team, it's also an amazing way
| to share the build environment
| AnIdiotOnTheNet wrote:
| I couldn't care less about Rust. The fact that this
| project used it is irrelevant to me and I have no desire
| to setup a Rust build env.
| [deleted]
| denysvitali wrote:
| It really depends. Go and Rust softwares are generally easy
| to build from source
| dbt00 wrote:
| Yes but coming from a go or rust neophyte to trusting
| that you've installed correctly from source is probably a
| higher bar than knowing that you've run a container
| correctly.
| AnIdiotOnTheNet wrote:
| 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.
| hda111 wrote:
| You give in trust your company's passwords to a random dude's
| open source project that was never audited professionally.
| Seems a very risky thing to do.
| Black101 wrote:
| a simple rsync client that could extract passwords from the data
| would be nice
| anaganisk wrote:
| Why not just get down to the basics write it yourself, like use
| rsync | pgp/openssl aes | rg/grep, isn't that what you want
| basically?
| Spivak wrote:
| Bitwarden has a CLI tool which is pretty good.
| Black101 wrote:
| what I mean is that why do you need bitwarden at all?
| masklinn wrote:
| Ensure that the data is stored securely, integrate with the
| various password-manager hooks of OS and browsers, generate
| passwords, ...
| michaelt wrote:
| There are many other options for password management that
| are very similar.
|
| Writing them down in a notebook next to your computer. A
| homebrew system like e-mailing GPG-encrypted files to
| yourself. Your browser's built in password saving and sync
| features. A password-protected Excel spreadsheet on your
| dropbox.
|
| Compared to a notebook, I can access my passwords from my
| phone if the need arises, and they're encrypted and backed
| up should I lose my phone.
|
| Compared to a homebrew system, someone else has done the
| work and made a cross-platform system with nice browser
| extensions, sensible defaults, and so on.
|
| Compared to my browser's sync features, there's peace of
| mind because it's not a free feature from a corporation
| famous for nonexistent customer service and sketchy
| tracking practices.
|
| Compared to dropbox, the price is trivial (as they only
| have to store a few kilobytes of data) and it's focused on
| security.
| f154hfds wrote:
| This is going to sound sketchy because any software project
| involving cryptography is automatically sketchy unless it
| has hit some nebulous and ill-defined 'accepted' status,
| but I've been working on a CLI tool to manage my passwords
| for a while that I'm honestly not ready to share, but the
| architecture so far is very simple:
|
| Each 'service block' is an encrypted file consisting of
| service name, service password (autogenerated), kv-store,
| some metadata for regenerating new passwords. The key to
| each service block is the hash of a primary password. The
| name of the 'service block' file is the hash of the service
| name. All of the service blocks are stored together in a
| folder that can be rsynced wherever.
|
| My worry is obviously in the crypto. While I'm not doing
| anything too fancy I worry about timing attacks because an
| attacker will have the full encrypted block so the system
| is vulnerable to that sort of thing.
| steviedotboston wrote:
| Something about running your own password manager server seems
| very risky to me.
| sneak wrote:
| The desktop[1] and mobile clients have a local database, so if
| the server is offline, you still have all of your data, you
| just can't sync.
|
| [1]: Note that the Bitwarden desktop client has a major remote
| code execution vulnerability that the developer has closed
| WONTFIX, so I don't recommend running the stock one without
| patching that out (as well as the spyware they embed in it).
| teekert wrote:
| Any more information on your claims? This is the first time I
| hear of this...
| sneak wrote:
| https://github.com/bitwarden/desktop/issues/552
| teekert wrote:
| 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.
| sneak wrote:
| 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 if
| they so desire. It's really a matter of consent, and
| forcing decisions down users' throats.
|
| Most people probably don't understand or believe that
| they are granting these applications' vendors permanent
| remote access to their computer.
|
| Honestly, I _wish_ it were only a matter of trusting the
| developers. Unfortunately, it 's a matter of trusting the
| developers, anyone from anywhere in the world who can
| compromise their keys/credentials, and anyone in
| meatspace who can coerce them to misuse those
| keys/credentials (such as military, police, et c). That,
| it turns out, is a rather large set of people, especially
| when you factor in the number of state level actors from
| every country big enough to have an intel agency
| sufficiently competent to own some small software house
| full of c# weenies running windows (the bitwarden devs).
| teekert wrote:
| 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.
| sneak wrote:
| 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.
| UncleMeat wrote:
| 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.
| sneak wrote:
| 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.
| bri3d wrote:
| Not linking to the "major RCE vulnerability" is
| sensationalist posting at its finest.
|
| I can assume you are referring to... the automatic updater?
| https://github.com/bitwarden/desktop/issues/552
| ryan29 wrote:
| What other options would there even be for updates? That
| bug report describes every updater I've ever seen.
| sneak wrote:
| 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 launched, which happens
| automatically if the computer is rebooted (like if there
| is a momentary power failure, or you hit "okay" on an OS
| update, or your battery dies and later you plug it back
| in to power).
|
| This grants the developers (as well as anyone who can
| compromise their credentials) unlimited remote access to
| your entire password vault the next time you unlock it.
| bri3d wrote:
| Sure, I see where you're coming from. I think your
| approach makes you come off as not very credible, though.
| Plus, it puts developers on the defensive and won't cause
| them to cooperate.
|
| A simple "I'm not comfortable with code on my machine
| being updated remotely without my approval, because I
| believe an attacker could infiltrate the supply chain"
| explains the problem you're having more precisely and
| turns into a simple feature request (turn off the auto-
| updater - which is already possible, as documented in
| that thread!) rather than trying to convince an entire
| industry that a commonly accepted practice (installation
| of signed remote updates) amounts to 0day RCE by putting
| them on the defensive.
| viro wrote:
| 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.
| sneak wrote:
| 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.
| viro wrote:
| 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
| RedComet wrote:
| Why don't you just disable the updater then?
|
| https://github.com/bitwarden/desktop/issues/552#issuecomm
| ent...
| sneak wrote:
| 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.
| malsanton wrote:
| I love this project, but something has always bothered me about
| it. For something as critical as your entire set of passwords,
| aren't you essentially trusting this person you've never met to
| not just take all of them when you use the server?
|
| For example, one day a malicious maintainer could flip a switch
| that simply updates the docker image to send thousands of
| peoples' entire vault somewhere and then disappear, no?
| jillesvangurp wrote:
| You are in control here. It's like every other bit of software
| you run yourself: it's your problem to do it properly.
|
| 1) if you worry about people replacing the docker image you are
| using, build your own. It's not hard. Alternatively, use a
| specific version of the docker image by specifying the version
| or the hash (if you are really paranoid). Of course after you
| review the Dockerfile. Minimum at least glance through the
| Dockerfile.
|
| 2) bitwarden has import/export functionality (client side) so
| if your server disappears for whatever reason, you can still
| export your passwords from the client side.
|
| 3) if you don't trust the OSS code, audit it or at least look
| through it. That's the whole point of OSS. Build it from source
| if you must. File bugs. Look at the issue tracker. You can
| choose not to but if something happens it's your problem; not
| somebody else's problem.
|
| 4) The vault is encrypted and the server never handles or sees
| the decrypted content (see 3 to verify this). Other people's
| ability to break that encryption depends on you using a secure
| master password.
|
| 5) Or just pay Bitwarden to host passwords for you and rely on
| their terms of use, SLAs, support, good reputation, and what
| not. That's probably the best option if you want ass coverage
| for professional usage. Their pricing is very reasonable for
| small setups. And probably sharing passwords with a large group
| of users is just a spectacularly bad idea to begin with. A
| couple of key users, should cost you max 20/month. Not really
| worth dedicating devops time for self hosting unless you have a
| really good reason to. If you do, see 1-4.
| o-__-o wrote:
| Bitwarden server phones home every install. In order to
| remove the phoning home bit, you must recompile the entire
| codebase. I wonder if this rust alternative makes that easier
| to remove...
| hda111 wrote:
| 4) this not 100% true. To get someone's passwords you just
| have to compromise their bitwarden_rs to include a malicious
| web client that sends the master password to the attacker if
| the user logs in. This is a different story of course when
| the web client is never used. Then it is impossible to get
| the passwords because it's encrypted at client side.
| ClumsyPilot wrote:
| "3) if you don't trust the OSS code, audit it or at least
| look through it. That's the whole point of OSS."
|
| Thats an outright fantasy, every day I rely on like 50 pieces
| of software written in 20 different languages and frameworks.
| They are updated multiple times a month. How many man hours
| would it take? 1000 a week?
|
| Proffesional developers couldn't find heartbleed for years,
| you really think anyone would notice a hidden backdoor in
| software like this withing a year?
| jillesvangurp wrote:
| The keyword in that sentence is trust. Either trust or
| check. Your choice.
|
| Most people choose to trust certain software providers
| based on their reputation. But if you have serious doubts
| and you don't check, that would be your problem.
|
| Whining about an open source project maybe being insecure
| basically means either check it or don't use it. Nobody is
| twisting your arm to risk your passwords on some wonky self
| hosted setup. Your problem if it blows up in your face.
| That's also what it spells out in a typical OSS license
| (that would be the section talking about limited
| liability). That's another thing people tend to not check
| that they probably should pay some attention to. Using the
| software means accepting that it's your responsibility.
|
| If like most you are unable to make a sound judgment on
| this front; consider paying a service provider providing
| you a service. That would be Bitwarden in this case. They
| kindly provide a free version even. Easy choice IMHO.
|
| Heart-bleed slipped through the cracks for a while and then
| certain software providers lived up to their reputation by
| providing fixes in a timely fashion. And certain others
| messed up by not doing that. I care more about how
| developers act when something like this happens than the
| fact that it happens.
|
| OSS software providers are no different than other
| providers when it comes to trust. Except you have the
| option of looking at their code. Lots of people doing that
| builds trust. I tend to look at things like number of
| stars, commit frequency, and other things when deciding to
| use a random Github thing. When it comes to software that
| is safety critical, I prefer the scrutiny of an active
| community of developers. That just increases my level of
| trust.
|
| IMHO Bitwarden's trustworthiness just went up by virtue of
| there being multiple implementations of the thing and
| apparently a growing community of users and developers
| depending on these things. I'm already using it and vastly
| prefer this over some closed source solution with opaque
| development processes. I probably would not self host but
| it is nice to have that option available.
| ClumsyPilot wrote:
| I am not taking a stab at bitwarden or OSS, but this
| talking point about trust is total tripe.
|
| It is a choice to obey the law of gravity? Because Its
| physically impossible for one person to check all
| security critical code they come in contact with even if
| they know every single programming language and have a
| Phd in cryptography. So stop with the accusatory language
| about 'whining' and pontification about choice.
| Graffur wrote:
| Who is whining? OP even said they love the project.
| They're just asking a question.
| prophesi wrote:
| With the official Bitwarden repos, this is solved by having
| reputable teams periodically run security audits. Sadly,
| it's unlikely this Rust implementation will be audited any
| time soon.
| killingtime74 wrote:
| Especially since bitwarden itself is already open source. This
| is a great learning project probably but not great for use
| Nullabillity wrote:
| The official Bitwarden server depends on MSSQL.
| joaopms wrote:
| The greatest thing about this implementation is its
| simplicity. I actually deployed this server for my personal
| use because everything lives in one Docker image and not a
| lot of them like the official implementation. I do understand
| that the official implementation helps with scalability and
| more, I just don't need it.
| sneak wrote:
| You self-host it. The data is going to your own server.
| BiteCode_dev wrote:
| Same with basically any part of your infra.
|
| What prevents Postgres mainteners to just still all your DB ?
| Nginx mainteners to redirect your web traffic ?
|
| Ultimately, it boils down to a balance between trust in the
| author, the community or your own checking process.
| novium wrote:
| If I'm not mistaken it should be mostly fine as long as you
| trust the desktop/phone versions of Bitwarden not to send off
| the (unhashed) key to the server
|
| Edit: Noting that there have been discussions about the default
| number of iterations.
| https://github.com/bitwarden/jslib/issues/52
| sneak wrote:
| Note also that the bitwarden desktop app has a remote code
| execution vulnerability that the developers refuse to fix,
| which means that the developers can, at any time, replace
| your local copy of the bitwarden desktop app with a different
| version that could steal all your passwords in exactly the
| manner you describe.
|
| You can patch the bitwarden client (and also take the
| opportunity to remove the spyware they have embedded in it,
| as well), or use a program like LuLu or Little Snitch to
| block it from communicating with anything but your own
| selfhosted bitwarden_rs instance.
| hanniabu wrote:
| Even if the takeaway from that conversation was that sha256
| is good enough, it concerns me how the Bitwarden team handled
| that issue.
| danmur wrote:
| The main problem I can see is entering your login in the web
| interface. I still use it though.
| kayson wrote:
| I had the same concern. There's also the matter of supporting
| upstream development, which the maintainer does address in his
| readme. I ended up paying for a premium subscription of vanilla
| Bitwarden, which I self host. Sure it's overkill on resources
| and number of containers, but it's still insignificant. It
| seems slightly more safe to trust a company that depends on the
| software for revenue, if I'm going to use it without auditing
| the source. I've also e-mailed their support quite a few times,
| and they're great. It just doesn't feel right to me to do that
| while using a free custom backend to avoid the cost...
| ianpurton wrote:
| You can avoid this by only storing part of your password in
| Bitwarden. The random part.
|
| Then when you log into somewhere add another secret (which you
| keep in your head) to the end of the password you stored in
| Bitwarden.
|
| Switch on 2FA everywhere you can.
|
| Sleep at night.
| CivBase wrote:
| That's actually a cool idea for a password manager in
| general. After logging in, you input a "salt" value that is
| appended to the end of all your passwords. That value is
| never sent to the password server, so even if the server is
| compromised your associated accounts aren't.
| jaegerma wrote:
| There's actually a name for that: pepper
|
| Instead of a salt, which is random for each entry and has
| to be stored along the hash, one single pepper is added to
| each password before hashing and kept secret.
| paulryanrogers wrote:
| You could restrict its network access to only your LAN. Though
| in that case you could only sync within your LAN.
| Macha wrote:
| Isn't this true for any service? We're just trusting that the
| bitwarden/server image or bitwarden.com won't do the same?
|
| Also this is only a risk if you use the provided Web vault. If
| you use the desktop, mobile or browser extension clients, it
| would require both Bitwarden LLC and dani garcia to conspire
| against you as the server doesn't control code those clients
| run and the API only provides it data in encrypted format.
|
| Finally, if you're that worried you can pin the container
| version by hash and only update when you are confident in the
| new version
| jamescontrol wrote:
| Yes, but if a company does this, they are essentially killing
| themselves. They have presumably spent a lot of time creating
| a company, gain customers etc, whereas a single(?) maybe
| anonymous open source developer does not have that much to
| lose.
| arkitaip wrote:
| The single dev has their reputation and professional career
| to lose whereas companies can and regularly engage in all
| kinds of legal and or judo to avoid any responsibility
| towards users.
| cromka wrote:
| A single dev is an exploitation sitting duck. They can
| get hacked, they can be stoled from, they can be targeted
| by the NSA (or FSA, ...), they can make a small but fatal
| mistakes, and I doubt they conform to the level of
| policies that companies like FAANG impose on their
| security-critical teams.
|
| And all of the above are very good plausible deniability
| excuses, such that this single developer could, after
| all, be malicious and still not loose his reputation
| simply by claiming he got targeted by a 3rd party.
|
| Let that sink in: a single developer and their PC is a
| gatekeeper of everyone's safety.
| alpaca128 wrote:
| > if a company does this, they are essentially killing
| themselves
|
| ...or they have to do it because of the NSA and weirdly 99%
| of users don't care or don't have the means to do anything
| about it.
|
| Companies aren't trustworthy, they are bigger targets but
| also targets with thicker armor.
|
| I just go with the offline route, KeepassXC runs well
| enough for me and is compatible with phones. I need to
| handle data sync myself but it's not like I change or add
| new passwords every day.
| mnutt wrote:
| This is the use case that something like sandstorm.io tries to
| solve, by locking down system calls on the backend and (slowly
| but surely) CSP on the frontend. I don't think BitWarden has
| been ported yet, though.
| foepys wrote:
| Is sandstorm active again? A few years ago there was some
| news about the company behind it running out of money and
| abandoning the project if I remember correctly.
| mnutt wrote:
| It transitioned to a community project and is active again.
| The original contributors are still involved, just to a
| lesser degree.
| Majromax wrote:
| With any password manager, encryption happens client-side. A
| malicious or compromised host could make off with your
| _encrypted_ vault, but that would not by itself compromise
| passwords.
| colejohnson66 wrote:
| OP is arguing that the software could be changed to upload
| your encrypted version as usual, but also silently upload
| your unencrypted version. Either unintentionally (bug) or
| intentionally (tin foil hat saying NSA)
| Majromax wrote:
| That would require changes to the client as well, however,
| and as I understand it bitwarden_rs still uses the standard
| client-side Bitwarden addon/applications/apps.
| chillfox wrote:
| You could always write your own password manager if you are
| that paranoid.
| rbut wrote:
| The same could be said of every docker image on dockerhub, or
| any open source project on github, or any distro of linux.. I
| could keep going.
|
| Unless you review the source code of everything you use, and
| compile it yourself, there's always that risk.
| ryan29 wrote:
| Isn't the same thing true for every password manager? What's
| stopping LastPass from pushing an update that steals all my
| passwords? What's stopping Chrome from auto-updating to a
| version that sends every password I enter to Google?
|
| It's not fair to single out just Bitwarden IMO.
| throwaway8581 wrote:
| Because of the way bitwarden works, I think as long as the
| client is secure, compromise of the server is not a major
| concern except for data loss. Your vault is encrypted client-
| side.
|
| The real threat is that someone takes control of the bitwarden
| browser extension and pushes a malicious update.
| vbezhenar wrote:
| > The real threat is that someone takes control of the
| bitwarden browser extension and pushes a malicious update.
|
| That's why I don't use any KeePass extensions. I just don't
| trust browser enough to be able to get any of my passwords.
|
| I'm thinking about writing my own extension which will
| communicate with KeePass in a way that suits me (basically:
| when I'm pressing button in browser, it'll popup KeePass
| window with search field filled with server domain. Then I
| can either auto-type password from KeePass or copy it to
| clipboard, either way I'm only using KeePass and browser
| extension have no way to get any information.
| fencepost wrote:
| I think there's a relevant xkcd about this, though
| technically it's about standards.
|
| I'd absolutely use KeePass for a long term storage password
| vault (with appropriately obscure reminders so I could
| recall the password), but the ecosystem of many unofficial
| free implementations for integration into browsers, phones
| (IIRC), etc. makes me twitch.
| Shish2k wrote:
| I switched to using this because keepass didn't have a good way
| of syncing its database with iOS devices, and the official
| bitwarden server has too many moving parts (including MS-SQL with
| no support for open source databases??) - aside from missing ssh-
| agent support, I'm loving all of it :)
| chipsa wrote:
| SQL isn't as portable as people would like. Especially when
| you're trying to stay high performance as you're dealing with
| millions of customers. Once you start building for a specific
| SQL server, it hard to switch to another variant.
| polote wrote:
| There is really something broken in the dev word. Why are people
| wasting their time rebuilding things that already exists ?
|
| If that was a side project to learn Rust, to learn the API of
| bitwarden, or to add new features I would understand, but that
| doesn't seem to be the case.
|
| I'm really curious why? "perfect for self-hosted deployment where
| running the official resource-heavy service might not be ideal"
| is that really the reason ?
| colejohnson66 wrote:
| Because sometimes people do things just because they can. Not
| every programming project needs to make sense.
| eeZah7Ux wrote:
| Unfortunately fragmenting the opensource ecosystem with too
| many implementations harms it.
| coldtea wrote:
| People don't always give a fuck about the "opensource
| ecosystem", they just want to program something they find
| fun...
| eeZah7Ux wrote:
| Unfortunately a lot of people don't give fucks about
| others.
|
| Publishing a weekend fun project on github and taking
| contributors away from from other projects is not always
| nice.
|
| If it's just a "fun project" put a clear warning that
| it's not meant to be trusted, used, contributed to.
|
| Github, by design, defaults to showing issue trackers &
| so on, giving the impression that a project is "real".
|
| Then you go looking for something to use and find 100
| half alive projects instead of 2 good ones.
| coldtea wrote:
| > _Then you go looking for something to use and find 100
| half alive projects instead of 2 good ones._
|
| That can be solved with curation. Where are the curating
| organizations/websites?
| anaganisk wrote:
| Whatever happened to opinions of people, likes and
| interests. So what if its fragmented? Isn't forking a
| crucial thing in open-source anyone can build and support
| whatever the fuck the want. There are thousands of other
| tech forums why do we need hacker news to fragment tech
| community.
| freeopinion wrote:
| 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.
| eeZah7Ux wrote:
| Absurd comparison.
| Philip-J-Fry wrote:
| No it doesn't. People are free to pick the best
| implementation to suit their needs.
| ClumsyPilot wrote:
| When all implementations are half-assed and none of them
| do it properly. However they have plenty of flamewars and
| ideological arguments #LinixDesktop
| Cu3PO42 wrote:
| Because it's fun? Because they just felt like it?
|
| Why are people wasting their time watching movies, reading
| books or doing literally anything that doesn't create immediate
| value?
|
| Beside all of that, the reason given is an extremely good one.
| The official server deployment suggests you should have
| multiple GB of free RAM for it. Bitwarden_rs uses orders of
| magnitude less. Right now it's sitting at 20MB on my server.
| fraktl wrote:
| I run Bitwarden official on a Hetzner dedicated box, the
| machine costs ~40EUR a month, Bitwarden usage does not even
| register as statistical error, therefore resource consumption
| is really not such a concern.
|
| There's really no objective reason to use bitwarden_rs.
| Subjectively - we can do whatever we like, I'm not trying to
| challenge anyone into providing their reasons or into
| justifying their decisions, there's no right or wrong here.
| Cu3PO42 wrote:
| Interesting. I haven't tried running the official server, I
| just went by what they list on their website [1]. It says
| "Minimum 2GB", "Recommended 4GB". To me this suggested
| massive resource consumption: my server with a bunch of
| services including bitwarden_rs running uses just about
| 1GB.
|
| [1] https://bitwarden.com/help/article/install-on-premise/
| inetbowser wrote:
| You answered your question yourself. Not everybody has a
| business-grade server rack at home (bit of an hyperbole but you
| get the point).
|
| "Why are people wasting their time rebuilding things that
| already exists ?" This is very subjective. There are many
| people (like me) who use bitwarden_rs for exactly the reasons
| it was created (low memory usage, etc.) so it definitely wasn't
| a waste of time.
| Shish2k wrote:
| The official server is a cluster of microservices including MS-
| SQL of all things -- bitwarden_rs is a single self-contained
| service which Just Works
| fraktl wrote:
| I love Bitwarden. It's a great piece of software and it's
| reasonably priced. We use it at my place of work (I pushed to
| install and use Bitwarden on the company level). I also tried the
| Bitwarden_RS, it does the same work however it's not suited for
| company use as it lacks the feature to create groups. There's an
| open issue that provides a workaround, however that workaround
| proved to be unusable. I tried to reach out to maintainers to see
| whether the feature could be implemented and paid for their
| effort but.. let's just say the answer was "No.".
|
| Long story short - we use official Bitwarden and are paying for
| it and couldn't be happier. Bitwarden_RS looks like a cool toy,
| but I can't see any reason why anyone would run it. It's good for
| personal passwords, but Bitwarden itself offers free service so
| there's no need to venture down the self-hosted road.
| fullstop wrote:
| I ran bitwarden_rs for a bit on a digital ocean node, but
| ultimately decided to buy a premium membership because it was
| less than $5/mo and I think that they will do a better job
| securing the system and keeping things up to date than I would
| in my spare time.
| Macha wrote:
| > It's good for personal passwords, but Bitwarden itself offers
| free service so there's no need to venture down the self-hosted
| road.
|
| It's a trust issue. I don't trust my passwords on someone
| else's server. I don't trust free services to remain free
| forever. I don't trust paid services to not increase the fees
| 4x over a few years.
|
| The alternative to bitwardenrs or bitwarden/server is not
| bitwarden.com for me given the areas I'm concerned with, it's
| going back to KeePass + Syncthing.
|
| I think the reticence to provide the group features in
| bitwarden_rs may come from being unwilling to too blatantly
| step on the toes of Bitwarden LLC by producing a $0 drop in
| alternative to their paid service. bitwarden_rs is open source
| and bitwarden/server is _mostly_ open source (Some SSO related
| features are not), so it seems worthwhile to get along and not
| need to fork the ecosystem.
| StavrosK wrote:
| Agreed, especially with how easy bitwarden_rs is to deploy (I
| wrote a three-line file and deployed it to my Dokku server
| and that was it).
| fraktl wrote:
| > It's a trust issue. I don't trust my passwords on someone
| else's server.
|
| They don't have your decryption key, therefore they save
| encrypted blobs and have no means to obtain your password.
| This takes care of trust issue - it simply is not an issue
| and never will be.
|
| Even if malicious employee does something out of the ordinary
| or "hacker" gets the database, they still have the impossible
| task of breaking the encryption (which for all intents and
| purposes is impossible as of right now).
|
| This returns us back to my starting point - there's *no
| objective* reason to use bitwarden_rs, apart from curiosity
| and/or convenience. I'm not saying it SHOULD not be used. We
| are all free to make choices as we see fit and don't need to
| justify them, however the reasons you listed are not reasons
| at all because the concerns you have don't exist.
| dsissitka wrote:
| > ...therefore they save encrypted blobs and have no means
| to obtain your password.
|
| Sure they do. The web vault. Plenty of functionality isn't
| available anywhere else.
| rbut wrote:
| I run bitwarden_rs for exactly the reason you stated, for
| personal passwords.
|
| It took a few seconds to add to my portainer (docker) server
| and now I host my vault and keep it safe within my LAN.
| chrismorgan wrote:
| I run bitwarden_rs for my own passwords because I want to run
| my own stuff for anything like passwords. (Previously I used
| KeePassX, and my biggest issue with it was that it was mostly
| tied to one device, depending on whatever file-based sync you
| might set up, and I never did--barring backups--so it was only
| ever on my main laptop, not on any secondary laptop or phone
| unless I jumped through some hoops to use one of the backups.)
|
| I don't run the official Bitwarden server because its system
| requirements are much too high for my liking.
|
| Meanwhile, bitwarden_rs uses ~24MB disk space, ~24MB RAM, and
| <0.03% CPU on my single-core Vultr box.
|
| Oh yeah, one other practical reason I couldn't/wouldn't go with
| bitwarden.com's free plan: I've got a few TOTP things in my
| vault, gotta pay for that.
| [deleted]
| imwillofficial wrote:
| Even if using this, remember to get a bitwarden license. It's $10
| for a whole year and keeps their dev afloat.
| dastx wrote:
| Please please please do this. I have plenty of issues with
| their prioritisation but at the end of the day, Bitwarden is
| extremely cheap, and is a great product. There is little to no
| reason to not pay that $10 a year.
| FlyingSnake wrote:
| Another satisfied user of `bitwarden_rs` here, and I can vouch
| for it. I migrated from LastPass and couldn't be more happier.
| The setup is pretty simple and I even managed to migrate it to a
| new server without any hassles. All the apps work flawlessly.
|
| The peace of mind in having all your sensitive data under your
| control is totally worth it.
| Barrin92 wrote:
| I mean at the end of the day your data is encrypted before it
| leaves your device and unless someone breaks encryption you can
| display it on a banner ad on Times Square and it doesn't make a
| difference.
|
| Personally I think hosting the server locally doesn't give much
| benefit because I'm more likely to screw things up than
| Bitwarden is on that front.
| [deleted]
| jamienicol wrote:
| Personally, having my sensitive data under my own control (but
| internet facing) terrifies me. I know enough to know that there
| are risks, and yet wouldn't have a clue about how to make it
| secure.
| pavon wrote:
| My self-hosted bitwarden server is only accessible from the
| LAN. Since the full password database is cached locally on
| each client, you can use it to lookup existing passwords just
| fine without a connection to the server. Bitwarden does
| require a connection to the server to add passwords, as it
| isn't a distributed architecture, so this setup does prevent
| you from adding new passwords while you are out and about,
| but I don't have the need to do that often, and in the rare
| occasions when I do, I write them on scrap paper in my wallet
| till I get home.
| indigo945 wrote:
| For home use, and to a limited extent - when all your users
| are proficient - for corporate use, I really enjoy pass
| (https://www.passwordstore.org/). It has a decentralized
| architecture where passwords are synchronized via git,
| making it excel at situations where you need to generate or
| store secrets on the go. Unfortunately, the Windows client
| is not stellar, and the (unofficial?) Android app doesn't
| seem to have an option to encrypt secrets using more than
| one key, limiting its use for most teams.
| justusthane wrote:
| I got really excited about pass for a bit and almost
| switched to it, until I realized I was likely increasing
| my attack surface because in addition to trusting the
| developer of pass, I also had to trust the developer of
| whatever other third-party clients I was using with it
| (such as the iOS client).
|
| Switched to Bitwarden instead.
| technorange wrote:
| I would set it up locally on raspberrypi with PiVPN and only
| allow specific IP (bitwarden IP) to be accessible via that
| VPN connection. Also you will need self-signed cert installed
| on the devices where you want to access bitwarden if you dont
| have a public domain.
| Nextgrid wrote:
| My concern about this is less about making it secure but
| _keeping_ it secure. Zero-day vulnerabilities are a thing and
| you can never be 100% safe against those, so the next best
| thing is to have good monitoring in place so you get alerted
| when something nefarious is going on. This unfortunately
| requires 24 /7 monitoring that's better left off to a
| dedicated team.
| viro wrote:
| I had to same thought so I put behind a VPN. a little less
| convenient. but WAY more secure
| yepguy wrote:
| Just connect to it via wireguard or tailscale instead of
| exposing it to the entire internet.
| alias_neo wrote:
| 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 because
| my password manager needs WebDAV, it was too much to
| maintain so I wrote a small server in Golang using the
| WebDAV library and it sits behind NGINX which handles the
| auth. I run Minio (S3 compatible) for syncing our family
| photos from our phones and Folder Sync app on Android. They
| both run on a VM and write out to a ZFS pool.
|
| I have a Pi 3B+ running Raspbian mounted read-only as a
| WireGuard VPN for remote access, and we use the official
| WireGuard app. VPN is always on because we have fast,
| symmetric fibre, and we don't need to worry about trusting
| public networks.
| mjthompson wrote:
| 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.
| amaccuish wrote:
| probably to save the SD card
| zzyzxd wrote:
| > The peace of mind in having all your sensitive data under
| your control is totally worth it.
|
| I used to have some illusions that "if I self host, I am in
| control", and "if I don't connect my home infra to the
| internet, I am safe". Later I realized neither is true.
|
| I can't trust all the consumer grade devices in my network, I
| don't trust a software just because it is open source. And I
| don't have time to keep up with all the security patches and do
| security auditing / vulnerability scan routinely...etc.
|
| It is fine to self host hobby stuff for fun, but professionally
| managing sensitive data is a full time job.
| the_duke wrote:
| Agreed, managing secure servers is a full time job.
|
| The situation with Bitwarden is a bit different though.
| Secrets are encrypted on the clients, the server never sees
| decrypted data.
| arsome wrote:
| 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.
| zzyzxd wrote:
| 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 these considered being
| paranoid. End of day it's about risk management, and
| personally, the benefits of selfhosting does not justify
| the effort I will need to put into maintaining it.
| [deleted]
| [deleted]
| hda111 wrote:
| It's not _everything_ encrypted. The server sees what
| domains you have passwords for. So there is a lot of
| metadata visible on the server. You have to trust the
| server also if you use the web client because the web
| client is loaded from the server. It could leak all your
| data if the server is compromised and you log in via web.
| holtalanm wrote:
| I switched to Bitwarden when LastPass changed their policy for
| multi-device users. I'm happy to say the transition was
| completely painless.
| CraigJPerry wrote:
| Even their CSV import worked flawlessly and my CSV export from
| Lastpass looked like a train wreck to parse but everything is
| present and correct in bitwarden.
| jarenmf wrote:
| Same here. I switched from LastPass and I really like the UX
| more than LastPass. It is less intrusive and feels more
| polished and snappier.
| nwah1 wrote:
| The UX is actually kind of bad. I think it is electron-based,
| the menus are far from a work of art, and the folder
| management seems very primitive.
|
| But that said, it is by far the best product despite this.
| sofixa wrote:
| What do you mean Electron based? There's no such thing as
| an "Electron-based UX".
|
| Bitwarden clients have the same UX across OSes and
| platforms ( browser extension, mobile app, thick client".
| The thick clients are indeed Electron based.
| mjthompson wrote:
| I think what was being said is the fact an app uses
| Electron rather than being native can diminish UX. I
| think it was clear enough from the post, at least from
| context.
|
| I'm actually a bit confused by 'the same UX across OSes'.
| What does this mean? The mobile UI is completely
| different to the desktop apps and web app.
| arsome wrote:
| I was about to complain about how their mobile UI made me
| click a tiny button in the top right instead of using the
| massive button that did something entirely useless, went
| to check what the button actually was and found out
| they've now fixed it.
|
| Props to the Bitwarden guys for fixing the only thing
| that really bothered me with the UI.
| sirtaj wrote:
| I switched over when I realised the Lastpass browser
| integration was chewing up CPU and significantly slowing down
| my browsing experience.
| koheripbal wrote:
| Did you consider KeePass or one of the variants?
| cocoa19 wrote:
| I do use KeePass for work, since we're not authorized to put
| passwords on the cloud, but device synchronization and
| browser auto fill is a pain.
|
| For personal, Bitwarden is much better. Browser plugins just
| work, android auto fill just works, passwords synchronized
| across devices, support for auto filling payment information.
| 2FA support.
| scaladev wrote:
| Did you try KeePassXC? It's much more actively developed
| and runs circles around the original KeePass:
|
| -- it's a native application (starts instantly on less
| powerful machines)
|
| -- can check your accounts against haveibeenpwnd.com
| database
|
| -- has full browser integration which works flawlessly IME
|
| -- can store SSH keys and work as an SSH agent
|
| https://keepassxc.org/
|
| edit: it does not support synchronization, I misremembered.
| Sorry.
| hojjat12000 wrote:
| I'm using KeePass. On Linux, windows and android and Google
| drive to sync the database. it is a hassle. The graphics look
| terrible. And most of the times the keeweb plugin doesn't
| really work on Firefox and I have to copy paste the password.
| But I have been using it for a long time now and got used to
| it. The best thing about it is the plugin system. I would not
| suggest it, I think bit warden does all of this and is a lot
| more user friendly.
| FlyingSnake wrote:
| I use KeePass on one of my projects and I find Bitwarden much
| better than KeePass. We're moving to Bitwarden soon to keep
| it seamless across teams.
| ErneX wrote:
| I use it and it's great. Best way to self host it imo.
___________________________________________________________________
(page generated 2021-03-18 23:02 UTC)