I'm paying for BitWarden because I want to support them. But it's pretty clear that they're backsliding.
This is understandable, the password manager market is saturated and implementing new features like Passkeys is far from trivial.
Still, they are the only real option for a one-click mostly open source password manager that works across all the major platforms and that supports modern features.
I mean that implementing things like passkeys required a lot of front-loaded work from them, without getting any compensation. So it's understandable that they're trying to push people to get subscriptions.
I was concerned about BitWarden when it started copying or acting like 1Password. Their marketing text, features, etc., are similar. I understand there isn’t much to differentiate between Password Management tools. BitWarden was supposed to be the Open-Source alternative to 1Password and better than Keepass.
I’m a customer of both services. I started with 1Password since its early days and have been using the family plan for the past 5+ years.
I used BitWarden when starting with Teams, as it is cheaper and presumably scalable. I hope that if things grow up, we can either host it ourselves or the pricing is affordable enough.
If Bitwarden becomes as “successful” as 1Password, people/companies will actually just use 1Password.
I think, now, the idea would be to start moving all critical ones to Keepass; and use a better UX client on top of the database.
I think the thing we need to learn about security is that usability matters.
I think this is easy for pretty much anyone that's an active HN user, but is it for your parents or grandparents? It's they who matter a lot. It's why WhatsApp was so successful, it passed the Grandma check. Signal might, but onboarding is "hard" (and the nerds argue and that's all others hear and then do what... Use telegram? Lol). But it's why Matrix isn't gaining popularity, because frankly until creating servers is a one click install it's not going to get mass appeal (same for any federated app).
It's the old PGP joke: how do you decrypt a PGP email? You email the sender "I can't decrypt, can you send it without encryption?"
> Telegram strikes a good balance, and wins at the UI/UX game.
Telegram gets the "lol" because it's not default E2EE. They advertise themselves as E2EE but most people are not using this feature because it's opt in. If you're going to seriously position yourself as a security app, the defaults have to be secure. It's the bare minimum.
And E2EE isn't even available for group chats... WhatsApp is more secure (telegram also gathers metadata)...
I do think signal has stagnated while there are many things that could really be improved, including low hanging fruit like just being able to search for stickers (people do in fact care). But for the most part, I'm not sure there's anything major missing. It seems like we're willing to pay high costs to avoid small thorns. But I guess it's better to have a rock on your shoulders than a needle in your finger.
> Telegram gets the "lol" because it's not default E2EE.
I use Telegram mostly for group chats, pretty much as an IRC replacement. I think that's where it really shines. :)
Agreed that even WhatsApp is more secure, but if I remember correctly, they do not promise that metadata is E2EE (if that's even possible), and Meta harvests that.
But just to be clear, telegram is not a privacy nor security app. It's just a communication app. It's fine that you use it, but just making sure you aren't calling an orange an apple (eat whatever fruit you want, I'm not a cop).
> they do not promise that metadata is E2EE (if that's even possible),
Sure it's possible. Signal does do this as well as many VPNs, things like encrypted DNS, tailscale and so on.
It's important to remember that it's also not binary. There's a whole range of metadata is. You can leave a footprint that's a very clear image of your shoe or you can leave a footprint that's a smudge that's only approximately in the size of your shoe. If you're concerned then the difference matters a lot.
While you won't leave zero trace the aforementioned apps (like signal and mullvad) do minimize the collection to the point where it isn't very useful. I mean it's metadata that you're a person, but that's not going to be helpful to identify you. Even knowing your gender probably won't but metadata's power is in it's accumulation.
This is fair, though in my answer, I wasn't answering the question from the perspective of applicability for a general audience.
For a general audience, even Bitwarden doesn't pass the "grandma check". If you've used Bitwarden for a while you have probably been met with a stern warning about "KDF Iterations too low".
So I pitched the answer assuming "able to use Bitwarden" as a base level of tech savvy.
Also, seeing as I am on HN, I assumed the following:
1. Security matters, even if it comes at a slight cost in convenience
2. User can figure out their own syncing mechanism
I'm willing to give up convenience for security. But I do like to stress that we should try to have both as much as possible. It's a thing that is often forgotten and many times matters.
I'd definitely agree that it's not a big issue here, as password managers are more personal, though my general frustration is with things like communication where I need the other person to also be willing to make the same compromises. Though back with password managers, I do need things that at least pass the parent test (retiree but not old folks home) because their information leakage leads to my leakage regardless of my actions. So I still do think it's worth turning up the heat to push things this way.
As a different point (which I'm not trying to argue but point out) is that we also need to recognize momentum and the challenges it brings, especially to the less tech savvy. We can jump ship easily when tides change because we know how to sail on our own, but what about those that don't? I am sympathetic to those who think we just jump ship to ship because even when they follow when they look back it looks like everyone is fine. I think it's a really unfortunate issue and I think a much more difficult challenge to solve. I'm not sure if anyone has any ideas. OSS only makes it easy to jump ship, but it doesn't reduce the need to jump in the first place
I'm using passkeys in BitWarden, and they so far work everywhere, except for the Apple Developer website. That doesn't _have_ a passkey enrollment option, and instead automagically creates it in the keychain somehow.
I checked the way they are implemented in BitWarden, and it's straightforward.
BTW, the blog is disingenuous. The removal of device attestation from PassKeys was a great boon for compatibility. And the experience with resetting key storages or not having enough slots are simply bugs and/or limitations of hardware. Which was to be expected from a new technology.
> The removal of device attestation from PassKeys was a great boon for compatibility.
Did they remove attestation? The blog implies they didn't when it says: "a security key ... fail to register ... since the IDP rejected the device attestation." What they removed was a browser API that allowed the IDP to filter the available passkeys, so they could tell the user which of the available keys they would accept before they tried to enrol it.
I gather attestation is rarely used by IDP's. That makes sense - why force a low security web site like a forum to keep a list of acceptable token models. However some sites like banks and my Federal Government absolutely need guarantees on how well the secrets are managed. Without it, they will remain with their current "roll their own" solutions. Providing an API that lets their web page say "no we won't accept your North Korean made phone as an authenticator" seems perfectly reasonable to me. That would be the API that Chrome refused to implement.
I never understood the appeal of web-based password managers. KeePass all the way, all offline, no randomly changing UI, everything in a single .db file. Need syncing? Use Cloud storage service.
Notably though, Keepassium from the App Store is licensed differently than the version on GitHub. Only the Keepassium team can ever actually submit to the App Store as GPL software is banned, and so they do not accept contributions so that they have the ability to submit under a proprietary license.
My reading from the License section[1] of the Keepasium README and this Stack Exchange post[2] is that the author of KeePassium wishes to license KeePassium under GPLv3. Accepting applications licensed under GPLv3 would require that Apple provide certain forms of source code alongside App Store downloads which they are unwilling to do. As such the App Store terms of service has terminology stating that you give Apple the right to not do that, which is something that only the copyright holder(s) of a work can do. The simplest way to have clarity over who holds the copyright is to have a single author. So long as the KeePassium author is willing to assign Apple the permission implicit in submitting to the App Store, that’s fine. It just means that all other uses of KeePassium must follow the GPLv3 license.
I am not a lawyer, nor really even well-versed in IP law, and you should not take this as legal advice.
Yes, you got it right. The source code is published under the GPL, but App Store ToS impose additional restrictions that are incompatible with the GPL. So we have to dual-license the project, and only the copyright owner can do that. In order to maintain that role, we can only accept contributions with a CLA (two pages of legalese that transfer the copyright). This is obviously a deterrent for contributions: over the 5 years, I believe there were only 3 people who signed it :)
the appeal is that it's a one click solution that works everywhere. If you have multiple devices, even worse if it's a mix of Android, Iphone, Windows, Mac, Linux you now have to find some cross platform sync solution on every device, the autofill functions of the various plugins don't work half the time, it usually ends up being an annoying mess. And if you need secure credential sharing with family members it's ten times more complicated yet again.
When you enabled the browser plugin, it would completely cover the input box, preventing you from using basic browser functionality meant to prevent you from using an alternative while it's enabled.
I'm also not sure what utility the premium features are.
There's the encrypted files, but they don't live in a vault. It seems that most obvious use case (being that you only get 1G) is to attach photos to IDs. But the implementation is silly. It's encrypted on their cloud where you download a copy and it then lives unencrypted on your device.
It seems silly that this is the implementation considering your passwords live in a local vault where you don't need a network connection.
Idk, I do want to support them but it does concern me when developers do not think about details, especially when it comes to security. The little things matter a lot.
I haven't looked at their clients repo [1] thoroughly, but I guess it's a good thing the bulk of their client apps are licensed under GPLv3 and can be easily forked.
This is disappointing. I use gopass for my personal passwords, but had moved family passwords to Bitwarden, and selected that hosted provide becauser it was open source.
I will continue to vote with my wallet, with other open-first solutions like ente and etesync.
Part of why I do this is so that if the company changes direction, the community can potentially fill in.
With the momentum behind vaultgarden, maybe open clients will flourish too.
Disappointing that a website that touts itself for, among other things, "Open Source News", is missing the core definition issue in that headline: what is at issue here has zero to do with how open or closed the source code is. It's only related to how free/libre the license is.
That's a big deal to some, no doubt, but it's important to be precise about language in cases like this, especially since folks will undoubtedly assume that this means secret user-hostile things will now be embedded in the source code, sight-unseen.
> Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.
Tempest in a teapot.
What about reporting a bug and chill? Instead of immediately jumping the gun and flooding the issue tracker of the one company that still tries with preaching? What is this going to achieve? Of course they locked it. Shame on everyone who commented some RMS-inspired lament into their issue queue.
What the CTO said is that, "build [failure] with bitwarden_license directory removed" is a bug. It doesn't change the fact that the SDK is not released under the free license.
Open source developers should think twice before accepting VC funding. The VC then own them.
I'm paying for BitWarden because I want to support them. But it's pretty clear that they're backsliding.
This is understandable, the password manager market is saturated and implementing new features like Passkeys is far from trivial.
Still, they are the only real option for a one-click mostly open source password manager that works across all the major platforms and that supports modern features.
Isn't passkey support already in? I am using that in day-to-day basis. Bugs exists, but it is not that far.
I mean that implementing things like passkeys required a lot of front-loaded work from them, without getting any compensation. So it's understandable that they're trying to push people to get subscriptions.
Enpass is supported on all platforms and you can decide how and where you want to store your passwords (local up to cloud infras)
> > for a one-click mostly open source password manager
Enpass is open source? Since when?
Recent and related:
Bitwarden is no longer free software - https://news.ycombinator.com/item?id=41893994 - Oct 2024 (71 comments)
I was concerned about BitWarden when it started copying or acting like 1Password. Their marketing text, features, etc., are similar. I understand there isn’t much to differentiate between Password Management tools. BitWarden was supposed to be the Open-Source alternative to 1Password and better than Keepass.
I’m a customer of both services. I started with 1Password since its early days and have been using the family plan for the past 5+ years.
I used BitWarden when starting with Teams, as it is cheaper and presumably scalable. I hope that if things grow up, we can either host it ourselves or the pricing is affordable enough.
If Bitwarden becomes as “successful” as 1Password, people/companies will actually just use 1Password.
I think, now, the idea would be to start moving all critical ones to Keepass; and use a better UX client on top of the database.
Related:
Bitwarden is no longer free software
https://news.ycombinator.com/item?id=41893994
BitWarden leaves open source community https://news.ycombinator.com/item?id=41896750
What alternatives do you recommend?
KeepassXC.
https://keepassxc.org/
Recently switched over from a premium Bitwarden account to it. Import from Bitwarden was a breeze.
Note that KeepassXC only writes to a local encrypted db file. Syncing that across devices is left to you. I used Syncthing for that.
Bad news there. https://forum.syncthing.net/t/discontinuing-syncthing-androi...
I've used this long-running fork and been pleased, and it's on F-Droid. https://github.com/Catfriend1/syncthing-android
> Syncing that across devices is left to you. I used Syncthing for that.
So it doesn't really solve my problem
That works fine for a single user, but it doesn't work for sharing secrets between multiple users
I think the thing we need to learn about security is that usability matters.
I think this is easy for pretty much anyone that's an active HN user, but is it for your parents or grandparents? It's they who matter a lot. It's why WhatsApp was so successful, it passed the Grandma check. Signal might, but onboarding is "hard" (and the nerds argue and that's all others hear and then do what... Use telegram? Lol). But it's why Matrix isn't gaining popularity, because frankly until creating servers is a one click install it's not going to get mass appeal (same for any federated app).
It's the old PGP joke: how do you decrypt a PGP email? You email the sender "I can't decrypt, can you send it without encryption?"
> Signal might, but onboarding is "hard" (and the nerds argue and that's all others hear and then do what... Use telegram? Lol).
I refuse to use Signal because their message history functionality is too restrictive for me.
Telegram strikes a good balance, and wins at the UI/UX game.
If you are Android, see Molly: https://github.com/mollyim/mollyim-android
Telegram gets the "lol" because it's not default E2EE. They advertise themselves as E2EE but most people are not using this feature because it's opt in. If you're going to seriously position yourself as a security app, the defaults have to be secure. It's the bare minimum.And E2EE isn't even available for group chats... WhatsApp is more secure (telegram also gathers metadata)...
I do think signal has stagnated while there are many things that could really be improved, including low hanging fruit like just being able to search for stickers (people do in fact care). But for the most part, I'm not sure there's anything major missing. It seems like we're willing to pay high costs to avoid small thorns. But I guess it's better to have a rock on your shoulders than a needle in your finger.
> Telegram gets the "lol" because it's not default E2EE.
I use Telegram mostly for group chats, pretty much as an IRC replacement. I think that's where it really shines. :)
Agreed that even WhatsApp is more secure, but if I remember correctly, they do not promise that metadata is E2EE (if that's even possible), and Meta harvests that.
But just to be clear, telegram is not a privacy nor security app. It's just a communication app. It's fine that you use it, but just making sure you aren't calling an orange an apple (eat whatever fruit you want, I'm not a cop).
Sure it's possible. Signal does do this as well as many VPNs, things like encrypted DNS, tailscale and so on.It's important to remember that it's also not binary. There's a whole range of metadata is. You can leave a footprint that's a very clear image of your shoe or you can leave a footprint that's a smudge that's only approximately in the size of your shoe. If you're concerned then the difference matters a lot.
While you won't leave zero trace the aforementioned apps (like signal and mullvad) do minimize the collection to the point where it isn't very useful. I mean it's metadata that you're a person, but that's not going to be helpful to identify you. Even knowing your gender probably won't but metadata's power is in it's accumulation.
This is fair, though in my answer, I wasn't answering the question from the perspective of applicability for a general audience.
For a general audience, even Bitwarden doesn't pass the "grandma check". If you've used Bitwarden for a while you have probably been met with a stern warning about "KDF Iterations too low".
So I pitched the answer assuming "able to use Bitwarden" as a base level of tech savvy.
Also, seeing as I am on HN, I assumed the following:
1. Security matters, even if it comes at a slight cost in convenience
2. User can figure out their own syncing mechanism
That's totally fair and I actually do agree.
I'm willing to give up convenience for security. But I do like to stress that we should try to have both as much as possible. It's a thing that is often forgotten and many times matters.
I'd definitely agree that it's not a big issue here, as password managers are more personal, though my general frustration is with things like communication where I need the other person to also be willing to make the same compromises. Though back with password managers, I do need things that at least pass the parent test (retiree but not old folks home) because their information leakage leads to my leakage regardless of my actions. So I still do think it's worth turning up the heat to push things this way.
As a different point (which I'm not trying to argue but point out) is that we also need to recognize momentum and the challenges it brings, especially to the less tech savvy. We can jump ship easily when tides change because we know how to sail on our own, but what about those that don't? I am sympathetic to those who think we just jump ship to ship because even when they follow when they look back it looks like everyone is fine. I think it's a really unfortunate issue and I think a much more difficult challenge to solve. I'm not sure if anyone has any ideas. OSS only makes it easy to jump ship, but it doesn't reduce the need to jump in the first place
You can use Vaultwarden. And official server implementation is open-source still.
No support for passkeys, either.
I wouldn't trust passkey myself [0] [0]: https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
I'm using passkeys in BitWarden, and they so far work everywhere, except for the Apple Developer website. That doesn't _have_ a passkey enrollment option, and instead automagically creates it in the keychain somehow.
I checked the way they are implemented in BitWarden, and it's straightforward.
BTW, the blog is disingenuous. The removal of device attestation from PassKeys was a great boon for compatibility. And the experience with resetting key storages or not having enough slots are simply bugs and/or limitations of hardware. Which was to be expected from a new technology.
> The removal of device attestation from PassKeys was a great boon for compatibility.
Did they remove attestation? The blog implies they didn't when it says: "a security key ... fail to register ... since the IDP rejected the device attestation." What they removed was a browser API that allowed the IDP to filter the available passkeys, so they could tell the user which of the available keys they would accept before they tried to enrol it.
I gather attestation is rarely used by IDP's. That makes sense - why force a low security web site like a forum to keep a list of acceptable token models. However some sites like banks and my Federal Government absolutely need guarantees on how well the secrets are managed. Without it, they will remain with their current "roll their own" solutions. Providing an API that lets their web page say "no we won't accept your North Korean made phone as an authenticator" seems perfectly reasonable to me. That would be the API that Chrome refused to implement.
It does support passkeys.
iOS application doesn't: https://github.com/keepassium/KeePassium/issues/297 Neither does the Android app: https://github.com/PhilippC/keepass2android/issues/2099
Well that SUCKS!
I never understood the appeal of web-based password managers. KeePass all the way, all offline, no randomly changing UI, everything in a single .db file. Need syncing? Use Cloud storage service.
> Use Cloud storage service.
It works until you have conflict edits on different device and need merging.
I stick to adding entries on my desktop and distributing copies to my clients. Its better for me to limit syncing between devices.
Can it fill passwords in iPhone Safari?
Yes, via the KeePassium client:
https://github.com/keepassium/KeePassium
As with all iOS apps, there’s no guarantee that the open source app code on GitHub corresponds to what you install from the App Store.
I have been very satisfied with KeePassium, it integrates with all the cloud storage providers I’d want and the app itself works well.
Notably though, Keepassium from the App Store is licensed differently than the version on GitHub. Only the Keepassium team can ever actually submit to the App Store as GPL software is banned, and so they do not accept contributions so that they have the ability to submit under a proprietary license.
My reading from the License section[1] of the Keepasium README and this Stack Exchange post[2] is that the author of KeePassium wishes to license KeePassium under GPLv3. Accepting applications licensed under GPLv3 would require that Apple provide certain forms of source code alongside App Store downloads which they are unwilling to do. As such the App Store terms of service has terminology stating that you give Apple the right to not do that, which is something that only the copyright holder(s) of a work can do. The simplest way to have clarity over who holds the copyright is to have a single author. So long as the KeePassium author is willing to assign Apple the permission implicit in submitting to the App Store, that’s fine. It just means that all other uses of KeePassium must follow the GPLv3 license.
I am not a lawyer, nor really even well-versed in IP law, and you should not take this as legal advice.
[1] https://github.com/keepassium/KeePassium?tab=readme-ov-file#...
[2] https://opensource.stackexchange.com/questions/9500/is-apple...
Yes, you got it right. The source code is published under the GPL, but App Store ToS impose additional restrictions that are incompatible with the GPL. So we have to dual-license the project, and only the copyright owner can do that. In order to maintain that role, we can only accept contributions with a CLA (two pages of legalese that transfer the copyright). This is obviously a deterrent for contributions: over the 5 years, I believe there were only 3 people who signed it :)
GPL software isn't banned. Is this just your speculation?
Yes, with integrations like Strongbox
You can do the same with Bitwarden by having the vault in your local computer.
Agreed. Too many places where things can go wrong.
the appeal is that it's a one click solution that works everywhere. If you have multiple devices, even worse if it's a mix of Android, Iphone, Windows, Mac, Linux you now have to find some cross platform sync solution on every device, the autofill functions of the various plugins don't work half the time, it usually ends up being an annoying mess. And if you need secure credential sharing with family members it's ten times more complicated yet again.
Ongoing thread that points to gasp the actual GitHub issue and not some rando site's take https://news.ycombinator.com/item?id=41893994
I left Bitwarden as soon as they started using dark patterns in their UI. They got in the way instead of enhancing the user experience.
What dark patterns have you observed that I should keep an eye out for?
When you enabled the browser plugin, it would completely cover the input box, preventing you from using basic browser functionality meant to prevent you from using an alternative while it's enabled.
Making it seem like you can use a premium feature, only to present you with a "You need to upgrade" view after a few steps.
Eg for Keypass and authenticator.
I'm also not sure what utility the premium features are.
There's the encrypted files, but they don't live in a vault. It seems that most obvious use case (being that you only get 1G) is to attach photos to IDs. But the implementation is silly. It's encrypted on their cloud where you download a copy and it then lives unencrypted on your device.
It seems silly that this is the implementation considering your passwords live in a local vault where you don't need a network connection.
Idk, I do want to support them but it does concern me when developers do not think about details, especially when it comes to security. The little things matter a lot.
I wonder when they are going to start blocking official clients from using things like vaultwarden.
I haven't looked at their clients repo [1] thoroughly, but I guess it's a good thing the bulk of their client apps are licensed under GPLv3 and can be easily forked.
[1] https://github.com/bitwarden/clients
This is disappointing. I use gopass for my personal passwords, but had moved family passwords to Bitwarden, and selected that hosted provide becauser it was open source.
I will continue to vote with my wallet, with other open-first solutions like ente and etesync.
Part of why I do this is so that if the company changes direction, the community can potentially fill in.
With the momentum behind vaultgarden, maybe open clients will flourish too.
Disappointing that a website that touts itself for, among other things, "Open Source News", is missing the core definition issue in that headline: what is at issue here has zero to do with how open or closed the source code is. It's only related to how free/libre the license is.
That's a big deal to some, no doubt, but it's important to be precise about language in cases like this, especially since folks will undoubtedly assume that this means secret user-hostile things will now be embedded in the source code, sight-unseen.
The licence is the definition of Open Source.
So there's nothing.
> Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.
Tempest in a teapot.
What about reporting a bug and chill? Instead of immediately jumping the gun and flooding the issue tracker of the one company that still tries with preaching? What is this going to achieve? Of course they locked it. Shame on everyone who commented some RMS-inspired lament into their issue queue.
Your comment is misleading.
What the CTO said is that, "build [failure] with bitwarden_license directory removed" is a bug. It doesn't change the fact that the SDK is not released under the free license.
EDIT: citation EDIT2: s/CEO/CTO/