Move to Bitwarden. It has a great free version but if you want to support them, you can pay 10 USD per year. Less than 1 dollar a month. Really reasonable.
[0] https://github.com/bitwarden/browser/issues/320
PS - If this issue does not occur for you personally, great but it does not for me and many others. Thus, it is unreliable.
One very important feature for me is having a command line interface because I have a bunch of scripts that need to be able to query the password manager. Fortunately bitwarden provides a first party CLI that seems pretty fully featured, so I was optimistic.
Anyway, I try to install bitwarden-cli through AUR and I see that one of the dependencies is nodejs.
Oh no.
Right so it's a javascript thingy. I'm a bit shocked, but then I decide that I'm being silly and it's what all the kids use these days and it's just a programming language and who cares. So I decide to push forward and install the binary version of the program (installed size is 65MB, as a comparison point lastpass also provides a CLI tool written in C that's 0.2MB installed).
Since I don't know how the tool works, I decide to launch it without argument to get the usage. It takes 0.6 seconds to display the usage. That's with a hot cache.
Oh no.
So that's the story of how I kept using pass. I know that some people will say that it's not that big of a deal, and I know that for bitwarden's devs it might make sense to implement their client that way because it lets you reuse some code and get good portability, but I just can't even. I'm running on an overclocked desktop computer capable of executing billions of instructions per second, I can play 4K videogames at 60 fps but apparently I get 1.6 UPS (usages per second) with this tool. It unironically makes me sad that this is the state of software engineering nowadays.
Reading this thread it seems like it's a mess when it comes to privacy too, so I suppose I dodged a bullet.
I didn't even know LastPass had a CLI, but it seems like it's a rewrite of the algorithm and surrounded toolset in C.
I can understand why the Bitwarden devs didn't want to go through the effort, though. The tiny minority of Linux-users that want a command-line password manager is not exactly worth a lot of development time, so I figured they just put their JS library in a NodeJS application and called it a day.
Since I do this multiple times per day I wrote a simple bash script that invokes Anyconnect and supplies the VPN credentials it pulls out of my password manager. I alias this script in my shell environment so it's as simple as typing "vpn" to get logged onto the corp network, saving the hassle of mousing around to get onto the VPN.
As for my workflow I don't have any auto-fill on my browser, I just use "pass -c my-password-entry" to put it in the clipboard and paste it from there. It's arguably less secure than having it autofilled I suppose, but it hasn't been an issue so far (and pass clears the clipboard after 45 seconds to mitigate the risk).
Then I have a bunch of scripts for starting my VPN connections, my email client etc...
I should add that my pass's GPG key is stored on a yubikey and I need to physically press the button to decrypt, so that adds a pretty good layer of protection.
So yeah, I realize that my use case is incredibly niche, but I do think that being able to use your password manager in scripts could be useful in some cases even for people who are less enamored with the terminal than I am.
For example something like
curl -u user:"$(pass SomeSecret)" https://api.website.com
Nice usage.
You could also use HISTIGNORE variable, history -d, or unset HISTFILE. Here are some examples [1]
[1] https://www.rootusers.com/17-bash-history-command-examples-i...
However, I found https://github.com/doy/rbw , and alternative OSS cli written in Rust, and it's exactly what I wanted. (Disclaimer: I liked it so much I wrote a rofi integration for it.)
Autofill is relatively poor (it fails even on HN!). Also, Lastpass has a convenient timed expiry that doesn't work (well) on Bitwarden (BW will expire the login when the browser is closed).
All in all though, I do support the recommendation, in particular, because Lastpass works extremely poorly on Firefox (at least, that's what caused my switch some time ago).
Huh, weird, it works fine for me in Firefox.
Autofill is much more customizable than LastPass afaik. You can both define how (domain)name matching should occur as you can have multiple entries to match.
This means you can have instagram.com (as website) and androidapp://com.instagram.android (as app) which will use the same autofill entry.
If you configure name matching correctly, any site should be able to provide autofill. My HN entry does match with news.ycombinator.com with default matching settings. But matching settings include hostname / domain name / starts with and even regex!
> Also, Lastpass has a convenient timed expiry that doesn't work (well) on Bitwarden (BW will expire the login when the browser is closed).
You can specify BW timeout settings. Even further, you can define if BW should lock the session (only a password is required to unlock) or if a sign-out is required. With a sign-out, you also need to provide your MFA if applicable.
Time outs can happen directly (after autofill), after an amount of time (1/5/15/30 minutes or 1/4 hours) or upon closing the browser.
So tbh, there is plenty to configure Bitwarden to suit your needs.
In what context? I found Autofill poor on Android for FF before I gave it the "draw over other apps" permissions. Otherwise I've only seen it fail on a few sites out of hundreds, mostly with weird login flows.
As for Bitwarden locking (expiring) when the browser is closed, I disable that as my system is secured so locking the vault in the browser is overkill for me.
My only real complaint with Bitwarden is the macOS app lacks TouchID support.
HN Autofill works perfectly well for me with Firefox + Bitwarden extension on macOS (I know it also works with other combinations). If it does not seem to work, select a password field. Does it for me.
https://community.bitwarden.com/t/remove-embedded-trackers-f...
> In the Mobile apps, Firebase Cloud Messaging (often mistaken for a tracker) is used only for push notifications related to sync and performs absolutely no tracking functions. Microsoft Visual Studio App Center is used for crash reporting on a range of mobile devices. In the Web Vault, Stripe and PayPal scripts are used for payment processing only on payment pages.
Compare this to LastPass where it was feeding data to Google Analytics and MixPanel, which do much more invasive levels of analysis in general.
Also, Firebase Cloud Messaging is the only way to have push notifications on Android.
Using either of their products ( outside of Firebase Analytics and maybe Firebase Auth) isn't tracking users and isn't harvesting user data. It's using tools to make apps, that's it.
Google is a malicious actor as a result of their business model and has already demonstrated their willingness to breach the GDPR with the non-compliant tracking consent prompts they use on their services, so it isn't that far-fetched to believe they can also use data from other services in ways you don't expect, especially when they can have plausible deniability.
[1] https://firebase.google.com/terms/data-processing-terms#5.pr...
I like almost every part of the experience except an annoying issue where the autofill doesn't work on firefox android (everything latest version). it shows up 10% of the time, for a few milliseconds. I've seen similar issues dating back from a year ago (https://github.com/bitwarden/mobile/issues/784). Makes me wonder how such commonly used things can be so broken for so long (see also https://news.ycombinator.com/item?id=26296339).
This setup seems fine for me. It seems faster and snappier than Lastpass, but that might just be down to the fact it's hosted on my LAN. All in all, I'm happy I moved and happy I'm now in control of such sensitive information as my passwords.
https://github.com/bitwarden/desktop/issues/552
The issue has been reported and they refuse to fix it.
This bug renders the Bitwarden encryption irrelevant, as the Bitwarden devs can always access your passwords regardless if they choose.
The Bitwarden devs can always access your passwords at any time if they choose to do so, as a result. This, to me, is as serious a vulnerability as lacking encryption in the first place.
Alternately, brute forcing the client password is straightforward due to their use of a too-fast KDF and low iteration count.
You're also right about the KDF but to be fair to them the devs say they'll accept work from a fork[0] to Argon2, if and when it's done (properly).
[0] https://community.bitwarden.com/t/switch-to-argon2/350/24
I'm not sure where the rest of your questions come from. "Do you not upgrade them ever?" does not logically follow from being opposed to the major security vulnerability that no-interaction automatic binary modification poses.
- You're on Windows and not using the Windows Store version or a "portable" version of the application - You're on macOS and not using the app store version - You're on Linux and you're using the AppImage version
Given the security-sensitive nature of the application and the target audience (mostly non-technical people), I think it's not a bad thing that this software has auto update functionality.
If you want to be free of this behaviour, you can either install the application through your system package manager/app store so you can control the update behaviour there, or run a development build of your vetted version of the source code.
If you simply reboot your computer, the new code executes.
Even still, auto update is a feature, not a vulnerability. It's the only way to get non-technical people to patch their software because people are afraid of change. Even if there's a huge vulnerability in Bitwarden, tons of people won't click the "yes update please" button because they're afraid updates change the way the tool works or break something.
Autoupdate is fine, so long as it's opt-in. It is a massive vulnerability if not, amounting to the same control as a standard remote access toolkit: full RCE.
> It's the only way to get non-technical people to patch their software because people are afraid of change.
Not only is this a factually incorrect statement, it also contains a presumption that Bitwarden's developers have some right to decide for the end user what software runs on their computer, when the end user is the final authority, for better or worse, on what code is allowed to run on the hardware they own.
I run a fork of the client now anyway, and bitwarden_rs on the server. I didn't want to deal with it but the dev responses to security reports are terrible.
Your phrasing and tone are quite harsh as others in that bug commented and seemingly agreed by the community judging by the fact you got more thumbs down reactions than thumbs up. Combined with the fact you're not even a paying customer, you really need to evaluate whether your approach was appropriate.