I have been meaning to move off of Bitwarden. In the past, open source meant more secure. Still could be the case for super important projects, but that is just no longer reality. I’m considering just vibe coding my own, vibe pentesting it, and keeping it private.
https://github.com/doy/rbw is a Rust alternative to the Bitwarden CLI. Although the Rust ecosystem is moving in NPM's direction (very large and very deep dependency trees), you still need to trust far fewer authors in your dependency tree than what is common for Javascript.
I had a really bad experience with the bitwarden cli. I believe it was `bw list` that I ran, assuming it would list the names of all my passwords, but too my surprise, it listed everything, including passwords and current totp codes. That's not the worst of it though. For some reason, when I ssh'ed into one of my servers and opened tmux, where I keep a weechat irc client running, I noticed that the entire content of the bw command was accessible from within the weechat text input field history. I have no idea how this happened, but it was quite terrifying. The issue persisted across tmux and weechat sessions, and only a reboot of the server would solve the problem.
I promptly removed the bw cli programme after that, and I definitely won't be installing it again.
Password managers are all about trust, the main link is about a compromise, so it's not surprising that the first comment is also about trust too, even if it's not directly about this particular compromise.
I found the default bwcli clunky and unacceptable, and it's why I don't use it, even though I still have a BitWarden subscription.
Not to mention utter nonsense. There’s no possible way that BW CLI somehow injected command history into a remote server. That was 100% something the GP did, a bug in their terminal, or a config they have with ssh/tmux, not Bitwarden.
that's our future... with AI. Engineers that don't know the difference between client-side convenience and server-side injection, how to configure `php.ini`, or that no synchronized password manager is safe. While the OAuth scope is `*`, and CORS is what you drink on the weekend.
There is a time and place for where it makes sense and a password manager CLI written in TypeScript importing hundreds of third-party packages is a direct red flag. It is a frequent occurrence.
We have seen it happen with Axios which is one of the biggest supply chain attacks on the Javascript / Typescript ecosystem and it makes no sense to build sensitive tools with that.
Never used the CLI, but I do use their browser plugin. Would be quite a mess if that got compromised. What can I do to prevent it? Run old --tried and tested-- versions?
Quite bizarre to think much much of my well-being depends on those secrets staying secret.
Integration points increase the risk of compromise. For that reason, I never use the desktop browser extensions for my password manager. When password managers were starting to become popular there was one that had security issues with the browser integration so I decided to just avoid those entirely. On iOS, I'm more comfortable with the integration so I use it, but I'm wary of it.
Importantly IMO is the extra phishing protection that the UX is really nice if and only if the url matches what's expected. If you end up on a fake url somehow, it's a nice speed bump that it doesn't let you auto-fill to make you think, hold on, something is wrong here.
If you're used to the clunkier workflow of copy-pasting from a separate app, then it's much easier to absent-mindedly repeat it for a not-quite-right url.
I also find it far easier to resist accidentally entering credentials in a phishing site... I'm pretty good about checking, but it's something I tend to point out to family and friends to triple check if it doesn't auto suggest the right site.
I’m impressed with their feature to add the URL for next time, after manually filling on an unmatched URI. Hairs raised on neck clicking confirm though.
The 1Password mobile and desktop apps have such a nice UX that I’m happy copy pasting from and into it instead of having any of the browser extensions enabled.
I have 1Password configured to require password to unlock once per 24 hours. Rest of the time I have it running in the background or unlock it with TouchID (on the MacBook Pro) or FaceID (on the iPhone).
It also helps that I don’t really sign into a ton of services all the time. Mostly I log into HN, and GitHub, and a couple of others. A lot of my usage of 1Password is also centered around other kinds of passwords, like passwords that I use to protect some SSH keys, and passwords for the disk encryption of external hard drives, etc.
> The 1Password mobile and desktop apps have such a nice UX that I’m happy copy pasting from and into it instead of having any of the browser extensions enabled.
Also a great way of missing out on one of the best protections of password managers; completely eliminating phishing even without requiring thinking. And yes, still requires you to avoid manually copy-pasting without thinking when it doesn't work, but so much better than the current approach you're taking, which basically offers 0 protection against phishing.
In Safari on iOS I have all the main pages I use as favourites, so that they show on the home screen of Safari.
Likewise I have links in the bookmarks bar on desktop.
I use these links to navigate to the main sites I use. And log in from there.
I don’t really need to think that way either.
But I agree that eliminating the possibility all-together is a nice benefit of using the browser integration, that I am missing out on by not using it.
Which works great until tags.tiqcdn.com, insuit.net or widget-mediator.zopim.com (example 3rd party domains loaded when you enter the landing page from some local banks) get compromised. I guess it's less likely to happen with the bigger banks, my main bank doesn't seem to load any scripts from 3rd party as an counter-example. Still, rouge browser extensions still scare me, although I only have like three installed.
My approach is that for critical sites like banking, I use the site URL stored in the password manager too, I don't navigate via any link clicking. I personally am fine with thinking when my entire net worth is potentially at stake.
It's not only about how you get there, but that the autofill shows/doesn't show, which is the true indicator (beyond the URL) if you're in the right place or not.
Rouge browser extensions for example could redirect you away from the bank website (if the bank website has poor security) when you go there, so even if you use the URL from the password manager, if you don't use the autofill feature, you can still get phished. And if the autofill doesn't show, and you mindlessly copy-paste, you'd still get phished. It's really the autofill that protects you here, not the URL in the password manager.
If you have rogue browser extensions installed, the browser extension can surely read the values that got filled into the login page without having to redirect to another site.
My two most precious digital possessions - my email and my Bitwarden account - are protected by a Yubikey that's always on my person (and another in another geographical location). I highly recommend such a setup, and it's not that much effort (I just keep my Yubikey with my house keys)
I got a bit scared reading the title, but I'm doing all I can to be reasonably secure without devolving into paranoia.
We need cooldowns everywhere, by default. Development package managers, OS package managers, browser extensions. Even auto-updates in standalone apps should implement it. Give companies like Socket time to detect malicious updates. They're good at it, but it's pointless if everyone keeps downloading packages just minutes after they're published.
> Russian locale kill switch: Exits silently if system locale begins with "ru", checking Intl.DateTimeFormat().resolvedOptions().locale and environment variables LC_ALL, LC_MESSAGES, LANGUAGE, and LANG
Does it matter? Lots of groups do such checks at startup at this point, because every news outlet who reports on it suddenly believe the group to be Russian if you do, so it's a no brainer to add today to misdirect even a little.
"Discretion is the better part of valor", "Never point it at your own feet", "Russian roulette is best enjoyed as a spectator", and many other sayings seem applicable.
That isn't a smoking gun. I think it was the Vault7 leaks which showed that the NSA and CIA deliberately leave trails like this to obfuscate which nation state did it. I'm sure other state actors do this as well, and it's not a particularly "crazy" technique.
I need my passwords to be accessible from my infrastructure and my phone. How do you achieve this with KeePass? I assumed it was not possible, but in fairness, I haven't really gone down that rabbit hole to investigate.
Keepass is just a single file, you can share it between devices however you want (google drive, onedrive, dropbox, nextcloud, syncthing, rsync, ftp, etc); as long as you can read and write to it, it just works. There are keepass clients for just about everything (keepassxc for desktops, keepass2android or keepassdx for android, keepassium for iphone).
Not op but I mean you can use a public cloud with Cryptomator on top if you don’t trust your password DB on a non E2E cloud. Or you can just use your own cloud (but then no access outside or can risk and open up infra), and then any of the well known clients on your phone. Can optionally sandbox them if possible and then just be mindful of sync conflicts with the DB file but I assume you, like most people, will 99.9% of the time be reading the DB not writing to it.
I never enjoyed the Android syncthing experience, so I just plug my phone in once a month and manually copy the vault over. I don't ever edit on my phone, so I don't need two-way syncing.
In short, when I make a major password or credential change I do it from my laptop, consider that file on disk to be the "master" copy, and then manually sync the file on a periodic basis to my phone. I treat the file on the phone as read-only. Works fine so far.
To date there have been zero instances when I needed to significantly change a password/service/login/credential solely from my phone and I was unable to access my laptop.
Additionally the file gets synchronized to a workstation that sits in my home office accessible by personal VPN, where it can be accessed in a shell session with the keepass CLI: https://tracker.debian.org/pkg/kpcli
You can use an extremely wide variety of your own choice of secure methods for how to get the file from the primary workstation (desktop/laptop) to your phone.
Which is great for Hacker News users that can maintain their own infra. But if we're talking "stress free", that's not an answer for the average user...
I do when I can, but there's a learning curve, and the rest of the world is trying to move those users in a very different direction (passkeys and other bullshit).
Password habits for many people are now decades-old, and very difficult to break.
This article is borderline malicious in how it skirts the facts.
This wasn't a case where KeePass was compromised in any way, as far as I can tell. This appears to be a basic case of a threat actor distributing a trojanized version via malicious ads. If users made sure they are getting the correct version, they were never in danger. That's not to say that a supply chain attack couldn't affect KeePass, but this article doesn't say that it has.
That looks like you'd have to download and run a hacked installer that was never avaliable from an official location. That is a much lower risk than a supply-chain attack where anyone building birwarden-cli from the official repo would be infected via the compromised dependency.
Long term keepass users aren't going to be affected. If you mention software to others make sure you send them a link to a known safe download location instead of having them search for one (as new users searching like that are more at risk of stumbling on a malicious copy of the official site hosting a hacked version).
That's an AI slop article. I'm not sure how someone creating their own installer and buying a few domains to distribute it is a mark against KeePass itself.
> The beacon established command and control over HTTPS
the only thing I can't find to do with keepass is how back up it in the cloud, like if you encrypt your back up, then where do you save that password, then where do you save the password for the cloud provider?.
I've dramatically decreased my reliance on third-party packages and tools in my workflow. I switched from Bitwarden to Apple Passwords a few months ago, despite its worse feature set (though the impetus was Bitwarden crashing on login on my new iPad).
I've also been preferring to roll things on my own in my side projects rather than pulling a package. I'll still use big, standalone libraries, but no more third-party shims over an API, I'll just vibe code the shim myself. If I'm going to be using vibe code either way, better it be mine than someone else's.
It's typescript and pretty sure all of the Official Bitwarden clients are written in it.
I wrote a version in Python and then rust back before the official CLI was released. Now you can use https://github.com/doy/rbw instead, much better maintained (since I don't use Bitwarden anymore).
Edit: The CLI itself apparently does not, which will have limited the damage a bit, but if it's installed as a snap, it might. Incidents like this should hopefully cause a rollback of this dumb system of forcefully and frequently updating people's software without explicit consent.
I recently had to disable their Chrome extension because it made the browser grind to a halt (spammed mojo IPC messages to the main thread according to a profiler). I wasn't the only one affected, going by the recent extension reviews. I wonder if it's related.
> The affected package version appears to be @bitwarden/cli2026.4.0, and the malicious code was published in bw1.js, a file included in the package contents. The attack appears to have leveraged a compromised GitHub Action in Bitwarden’s CI/CD pipeline, consistent with the pattern seen across other affected repositories in this campaign.
So how likely is that these compromises will start affecting the non-cli and non-open-source tools ? For example other password managers (in the form of GUI's or browser extensions).
Remember how the White House published that document on memory safe languages? I think it’s time they go one step further and ban new development in JavaScript. Horrible language horrible ecosystem and horrible vulns.
Supply chain attacks aren't exclusive to JS just like malware isn't exclusive to Windows, it's just that JS/Windows is more popular and widespread. Kill JS and you will get supply chain attacks on the next most popular language with package managers. Kill Windows and you will get a flood of Linux/MacOS malware.
I mean, what's the future now? Everyone just vibecoding their own private tools that no "foreign government" has access to? It honestly feels like everything is slowly starting to collapse.
Also didn't Microsoft (the owner of GitHub) got access to Claude Mythos in order to "seCuRe cRitiCal SoftWaRe InfRasTructUre FoR teh AI eRa"? Hows securing GitHub Action going for them?
You had to install the CLI through NPM at a very short time frame for it to be affected. If you did get infected, you have to assume all secrets on your computer were accessed and that any executable file you had write access to may be backdoored.
Once again, it is in the NPM ecosystem. OneCLI [0] does not save you either. Happens less with languages that have better standard libraries such as Go.
If you see any package that has hundreds of libraries, that increases the risk of a supply chain attack.
So the comparison here is that you would rather trust a password manager with a CLI that imports hundreds of third-party dependencies over a first party password manager with a CLI that comes with the OS?
I don't think macOS Keychain uses NPM and it isn't in TypeScript or Javascript and, yes it does not need a CLI either.
The NPM and Java/Typescript ecosystem is part of the problem that encourages developers to import hundreds of third-party libraries, due to its weak standard library which it takes at least ONE transitive dependency to be compromised and it is game over.
> You initially complained about CLIs, not the dependency mess of the JS ecosystem.
I complained about both. What does this say from the start?
>> Once again, it is in the NPM ecosystem.
> You still have not said why this is an issue of having a CLI.
Why do you need one? Automation reasons? OpenClaw? This is an attractive way for an attacker to get ALL your passwords in your vault. The breach itself if run in GitHub Actions would just make it a coveted target to compromise it which makes having one worse not better and for easier exfiltration.
So it makes even more sense for a password manager to not need a CLI at all. This is even before me mentioning the NPM and the Javascript ecosystem.
>Why do you need one? Automation reasons? OpenClaw? This is an attractive way for an attacker to get ALL your passwords in your vault.
I need one because I am not always using a graphical interface. What exactly in a GUI do you think makes it harder/less attractive for an attacker?
If the GUI code is compromised in the same way as the CLI, it'll have the same level of access to your vault as soon as you enter your master password.
It does not much matter if it imports 300 or 30 of them, those vulns will land somewhere in those 30 with equal frequency statistically. If you are advocating developing without dependencies at all, then please start (with any language) and show us all how much you actually ship.
JS is a target of these dumb accusations because it's literally the best cross-platform way to ship apps. Stop inventing issues where there are none.
That's a wild statement. The CLI is just another UI.
The problem in this case is JS and the NPM ecosystem. Go would be an improvement, but complexity is the enemy of security. Something like (pass)age is my preference for storing sensitive data.
I have been meaning to move off of Bitwarden. In the past, open source meant more secure. Still could be the case for super important projects, but that is just no longer reality. I’m considering just vibe coding my own, vibe pentesting it, and keeping it private.
https://github.com/doy/rbw is a Rust alternative to the Bitwarden CLI. Although the Rust ecosystem is moving in NPM's direction (very large and very deep dependency trees), you still need to trust far fewer authors in your dependency tree than what is common for Javascript.
Well.. https://github.com/doy/rbw/blob/main/Cargo.toml#L16
You're still pulling a lot of dependencies. At least they're pinned though.
That's just direct dependencies. Including all the dependency tree is 785k LOC according to lib.rs. Most rust libraries include tons of others.
https://lib.rs/crates/rbw
This + vaultwarden is an awesome self-hostable rust version of bitwarden. We might as well close the loop!
I had a really bad experience with the bitwarden cli. I believe it was `bw list` that I ran, assuming it would list the names of all my passwords, but too my surprise, it listed everything, including passwords and current totp codes. That's not the worst of it though. For some reason, when I ssh'ed into one of my servers and opened tmux, where I keep a weechat irc client running, I noticed that the entire content of the bw command was accessible from within the weechat text input field history. I have no idea how this happened, but it was quite terrifying. The issue persisted across tmux and weechat sessions, and only a reboot of the server would solve the problem.
I promptly removed the bw cli programme after that, and I definitely won't be installing it again.
I use ghostty if it matters.
I love how the first comment is a complain having nothing to do with the actual subjec
Password managers are all about trust, the main link is about a compromise, so it's not surprising that the first comment is also about trust too, even if it's not directly about this particular compromise.
I found the default bwcli clunky and unacceptable, and it's why I don't use it, even though I still have a BitWarden subscription.
Not to mention utter nonsense. There’s no possible way that BW CLI somehow injected command history into a remote server. That was 100% something the GP did, a bug in their terminal, or a config they have with ssh/tmux, not Bitwarden.
that's our future... with AI. Engineers that don't know the difference between client-side convenience and server-side injection, how to configure `php.ini`, or that no synchronized password manager is safe. While the OAuth scope is `*`, and CORS is what you drink on the weekend.
I thought that CLI would be efficent when I looked for using it and then I figured it is JavaScript
Exactly. That is the problem.
There is a time and place for where it makes sense and a password manager CLI written in TypeScript importing hundreds of third-party packages is a direct red flag. It is a frequent occurrence.
We have seen it happen with Axios which is one of the biggest supply chain attacks on the Javascript / Typescript ecosystem and it makes no sense to build sensitive tools with that.
Wow. Thats crazy. Is there an extension for bwcli in weechat? BTW I didnt even know BW had a cli until now. I use keepass locally.
I don't know, I use a vanilla weechat setup
Never used the CLI, but I do use their browser plugin. Would be quite a mess if that got compromised. What can I do to prevent it? Run old --tried and tested-- versions?
Quite bizarre to think much much of my well-being depends on those secrets staying secret.
Integration points increase the risk of compromise. For that reason, I never use the desktop browser extensions for my password manager. When password managers were starting to become popular there was one that had security issues with the browser integration so I decided to just avoid those entirely. On iOS, I'm more comfortable with the integration so I use it, but I'm wary of it.
The problem is that the UX with a browser extension is so much better.
Importantly IMO is the extra phishing protection that the UX is really nice if and only if the url matches what's expected. If you end up on a fake url somehow, it's a nice speed bump that it doesn't let you auto-fill to make you think, hold on, something is wrong here.
If you're used to the clunkier workflow of copy-pasting from a separate app, then it's much easier to absent-mindedly repeat it for a not-quite-right url.
I also find it far easier to resist accidentally entering credentials in a phishing site... I'm pretty good about checking, but it's something I tend to point out to family and friends to triple check if it doesn't auto suggest the right site.
I’m impressed with their feature to add the URL for next time, after manually filling on an unmatched URI. Hairs raised on neck clicking confirm though.
Exactly. Same principle of passkeys, Yubikeys and FIDO2. Much harder to phish because the domains have to match.
The 1Password mobile and desktop apps have such a nice UX that I’m happy copy pasting from and into it instead of having any of the browser extensions enabled.
I have 1Password configured to require password to unlock once per 24 hours. Rest of the time I have it running in the background or unlock it with TouchID (on the MacBook Pro) or FaceID (on the iPhone).
It also helps that I don’t really sign into a ton of services all the time. Mostly I log into HN, and GitHub, and a couple of others. A lot of my usage of 1Password is also centered around other kinds of passwords, like passwords that I use to protect some SSH keys, and passwords for the disk encryption of external hard drives, etc.
> The 1Password mobile and desktop apps have such a nice UX that I’m happy copy pasting from and into it instead of having any of the browser extensions enabled.
Also a great way of missing out on one of the best protections of password managers; completely eliminating phishing even without requiring thinking. And yes, still requires you to avoid manually copy-pasting without thinking when it doesn't work, but so much better than the current approach you're taking, which basically offers 0 protection against phishing.
In Safari on iOS I have all the main pages I use as favourites, so that they show on the home screen of Safari.
Likewise I have links in the bookmarks bar on desktop.
I use these links to navigate to the main sites I use. And log in from there.
I don’t really need to think that way either.
But I agree that eliminating the possibility all-together is a nice benefit of using the browser integration, that I am missing out on by not using it.
Which works great until tags.tiqcdn.com, insuit.net or widget-mediator.zopim.com (example 3rd party domains loaded when you enter the landing page from some local banks) get compromised. I guess it's less likely to happen with the bigger banks, my main bank doesn't seem to load any scripts from 3rd party as an counter-example. Still, rouge browser extensions still scare me, although I only have like three installed.
My approach is that for critical sites like banking, I use the site URL stored in the password manager too, I don't navigate via any link clicking. I personally am fine with thinking when my entire net worth is potentially at stake.
It's not only about how you get there, but that the autofill shows/doesn't show, which is the true indicator (beyond the URL) if you're in the right place or not.
Rouge browser extensions for example could redirect you away from the bank website (if the bank website has poor security) when you go there, so even if you use the URL from the password manager, if you don't use the autofill feature, you can still get phished. And if the autofill doesn't show, and you mindlessly copy-paste, you'd still get phished. It's really the autofill that protects you here, not the URL in the password manager.
If you have rogue browser extensions installed, the browser extension can surely read the values that got filled into the login page without having to redirect to another site.
> What can I do to prevent it?
My two most precious digital possessions - my email and my Bitwarden account - are protected by a Yubikey that's always on my person (and another in another geographical location). I highly recommend such a setup, and it's not that much effort (I just keep my Yubikey with my house keys)
I got a bit scared reading the title, but I'm doing all I can to be reasonably secure without devolving into paranoia.
If the software gets poisoned then your YubiKey will not save you.
We need cooldowns everywhere, by default. Development package managers, OS package managers, browser extensions. Even auto-updates in standalone apps should implement it. Give companies like Socket time to detect malicious updates. They're good at it, but it's pointless if everyone keeps downloading packages just minutes after they're published.
Use the desktop or web vault directly, don't use the browser plugin.
You should use hunter2 as your password on all services.
That password cannot be cracked because it will always display as ** for anyone else.
My password is *****. See? It shows as asterisks so it's totally safe to share. Try it!
... Scnr •́ ‿ , •̀
> Russian locale kill switch: Exits silently if system locale begins with "ru", checking Intl.DateTimeFormat().resolvedOptions().locale and environment variables LC_ALL, LC_MESSAGES, LANGUAGE, and LANG
So bold and so cowards at the same time...
The worst thing is that you can't even tell if that's "real" or just a false flag.
Does it matter? Lots of groups do such checks at startup at this point, because every news outlet who reports on it suddenly believe the group to be Russian if you do, so it's a no brainer to add today to misdirect even a little.
My point is that it could still be Russia, as they know that we know it is used as a false flag.
My point is; what changes if we knew for a fact it was Russia or that it was someone else?
"Discretion is the better part of valor", "Never point it at your own feet", "Russian roulette is best enjoyed as a spectator", and many other sayings seem applicable.
Smells like blackmail from another nation..
ah yes, because everyone sets locale on their npm publish github CI job.
obvious misdirection, but it does serve to make it very obvious it was a state actor.
> but it does serve to make it very obvious it was a state actor
Lol no, lots of groups do this, non-state ones too.
That isn't a smoking gun. I think it was the Vault7 leaks which showed that the NSA and CIA deliberately leave trails like this to obfuscate which nation state did it. I'm sure other state actors do this as well, and it's not a particularly "crazy" technique.
KeePass users continue to live the stress free live.
I've managed to avoid several security breaches in last 5 years alone by using KeePass locally on my own infra.
I need my passwords to be accessible from my infrastructure and my phone. How do you achieve this with KeePass? I assumed it was not possible, but in fairness, I haven't really gone down that rabbit hole to investigate.
Keepass is just a single file, you can share it between devices however you want (google drive, onedrive, dropbox, nextcloud, syncthing, rsync, ftp, etc); as long as you can read and write to it, it just works. There are keepass clients for just about everything (keepassxc for desktops, keepass2android or keepassdx for android, keepassium for iphone).
Not op but I mean you can use a public cloud with Cryptomator on top if you don’t trust your password DB on a non E2E cloud. Or you can just use your own cloud (but then no access outside or can risk and open up infra), and then any of the well known clients on your phone. Can optionally sandbox them if possible and then just be mindful of sync conflicts with the DB file but I assume you, like most people, will 99.9% of the time be reading the DB not writing to it.
Syncthing can synchronize Keepass files between devices quite well.
I rely on this too, but counting down the days android no longer lets syncthing touch another app's files :(
I never enjoyed the Android syncthing experience, so I just plug my phone in once a month and manually copy the vault over. I don't ever edit on my phone, so I don't need two-way syncing.
It would be strange if Android locked that down further than even iOS - Keepassium on iOS can open files from any sync app IIRC
What happens if you add a new item on two devices simultaneously?
For me it is nextcloud + wireguard
In short, when I make a major password or credential change I do it from my laptop, consider that file on disk to be the "master" copy, and then manually sync the file on a periodic basis to my phone. I treat the file on the phone as read-only. Works fine so far.
To date there have been zero instances when I needed to significantly change a password/service/login/credential solely from my phone and I was unable to access my laptop.
Additionally the file gets synchronized to a workstation that sits in my home office accessible by personal VPN, where it can be accessed in a shell session with the keepass CLI: https://tracker.debian.org/pkg/kpcli
You can use an extremely wide variety of your own choice of secure methods for how to get the file from the primary workstation (desktop/laptop) to your phone.
I mean there are ways i.e. if you run something like tailscale and can always access your private network etc. but it is a hassle.
Plus, now you're responsible for everything. Backups, auditing etc.
Which is great for Hacker News users that can maintain their own infra. But if we're talking "stress free", that's not an answer for the average user...
what "infra"? keepass works locally, and just opens a database file. it works the same as any other password manager.
The average user is reusing their password everywhere, and rotation means changing the numeral 6 at the end of the password to 7.
We should be encouraging those users to switch to a password manager.
I do when I can, but there's a learning curve, and the rest of the world is trying to move those users in a very different direction (passkeys and other bullshit).
Password habits for many people are now decades-old, and very difficult to break.
> KeePass users continue to live the stress free live.
https://cyberpress.org/hackers-exploit-keepass-password-mana...
This article is borderline malicious in how it skirts the facts.
This wasn't a case where KeePass was compromised in any way, as far as I can tell. This appears to be a basic case of a threat actor distributing a trojanized version via malicious ads. If users made sure they are getting the correct version, they were never in danger. That's not to say that a supply chain attack couldn't affect KeePass, but this article doesn't say that it has.
That looks like you'd have to download and run a hacked installer that was never avaliable from an official location. That is a much lower risk than a supply-chain attack where anyone building birwarden-cli from the official repo would be infected via the compromised dependency.
Long term keepass users aren't going to be affected. If you mention software to others make sure you send them a link to a known safe download location instead of having them search for one (as new users searching like that are more at risk of stumbling on a malicious copy of the official site hosting a hacked version).
This AI generated article is not about vulnerabilities in KeePass, rather about malicious KeePass clones.
Happy 1password user for more than a decade.
It's only a matter of time until _they_ are also popped :(.
That's an AI slop article. I'm not sure how someone creating their own installer and buying a few domains to distribute it is a mark against KeePass itself.
> The beacon established command and control over HTTPS
the only thing I can't find to do with keepass is how back up it in the cloud, like if you encrypt your back up, then where do you save that password, then where do you save the password for the cloud provider?.
You save the single password in your head. All other passwords go inside Keepass.
This is precisely why I don't use BW CLI. Use pass or gopass for all your CLI tokens and sync them via a private git repo.
Keep the password manager as a separate desktop app and turn off auto update.
I've dramatically decreased my reliance on third-party packages and tools in my workflow. I switched from Bitwarden to Apple Passwords a few months ago, despite its worse feature set (though the impetus was Bitwarden crashing on login on my new iPad).
I've also been preferring to roll things on my own in my side projects rather than pulling a package. I'll still use big, standalone libraries, but no more third-party shims over an API, I'll just vibe code the shim myself. If I'm going to be using vibe code either way, better it be mine than someone else's.
Why not stick to simple/heavily vetted password managers (like keepassx)? is there some advanced feature you use?
Seamless syncing is the primary reason I stick with BW
Writing a cli with JavaScript? No thank you.
It's typescript and pretty sure all of the Official Bitwarden clients are written in it.
I wrote a version in Python and then rust back before the official CLI was released. Now you can use https://github.com/doy/rbw instead, much better maintained (since I don't use Bitwarden anymore).
Does the CLI auto-update?
Edit: The CLI itself apparently does not, which will have limited the damage a bit, but if it's installed as a snap, it might. Incidents like this should hopefully cause a rollback of this dumb system of forcefully and frequently updating people's software without explicit consent.
Also the time range provided in https://community.bitwarden.com/t/bitwarden-statement-on-che... can help with knowing if you were at risk. I only used the CLI once in the morning yesterday (ET), so I might not have been affected?
I think you had to have installed the CLI during that time-frame, then ran the brand new installed CLI to be vulnerable.
Assuming you had it already installed, you would be safe.
Their website is also incredibly bad. I am not paying for it so it might be better for paying users.
It is mind boggling how an app that just lists a bunch of items can be so bloated.
I recently had to disable their Chrome extension because it made the browser grind to a halt (spammed mojo IPC messages to the main thread according to a profiler). I wasn't the only one affected, going by the recent extension reviews. I wonder if it's related.
> CLI builds were affected [...]
> Bitwarden’s Chrome extension, MCP server, and other legitimate distributions have not been affected yet.
> The affected package version appears to be @bitwarden/cli2026.4.0, and the malicious code was published in bw1.js, a file included in the package contents. The attack appears to have leveraged a compromised GitHub Action in Bitwarden’s CI/CD pipeline, consistent with the pattern seen across other affected repositories in this campaign.
I wonder if 1Password CLI is a top priority for hackers similarly.
So how likely is that these compromises will start affecting the non-cli and non-open-source tools ? For example other password managers (in the form of GUI's or browser extensions).
I was literally thinking about installing the cli a few days ago to ease the use in a few places. Now I'm glad I didn't.
This doesn't affect the web extension, no?
Remember how the White House published that document on memory safe languages? I think it’s time they go one step further and ban new development in JavaScript. Horrible language horrible ecosystem and horrible vulns.
Supply chain attacks aren't exclusive to JS just like malware isn't exclusive to Windows, it's just that JS/Windows is more popular and widespread. Kill JS and you will get supply chain attacks on the next most popular language with package managers. Kill Windows and you will get a flood of Linux/MacOS malware.
I mean, what's the future now? Everyone just vibecoding their own private tools that no "foreign government" has access to? It honestly feels like everything is slowly starting to collapse.
Also didn't Microsoft (the owner of GitHub) got access to Claude Mythos in order to "seCuRe cRitiCal SoftWaRe InfRasTructUre FoR teh AI eRa"? Hows securing GitHub Action going for them?
Bitwarden statement - https://community.bitwarden.com/t/bitwarden-statement-on-che...
> Checkmarx is an information security company specializing in software application security testing and risk management for software supply chains.
The irony! The security "solution" is so often the weak link.
The adage that security companies are often worse at software security than the median non-security company continues to hold water.
Last month it was trivy: https://github.com/aquasecurity/trivy/security/advisories/GH...
If I run the compromised CLI, do they get all my passwords?
Exactly, that could widen the blast radius of this particular compromise significantly.
No, at least according to Bitwarden themselves: https://community.bitwarden.com/t/bitwarden-statement-on-che...
Read the article
Where does it answer this question in the article?
kinda crazy to see this comment required in this particular context, yet here we are
It's an understandable question, the article reads like an AI generated mess.
The article explains what is extracted.
The article waffles on forever and gives some generic advice.
Meanwhile, Bitwarden themselves state that end users were almost never affected: https://community.bitwarden.com/t/bitwarden-statement-on-che...
You had to install the CLI through NPM at a very short time frame for it to be affected. If you did get infected, you have to assume all secrets on your computer were accessed and that any executable file you had write access to may be backdoored.
No it doesn't?
Yes it does, under technical analysis. I don’t want to paste it here when it’s laid out in the article…
It seems to be describing what the Checkmarx vulnerability allows to be done on a GitHub Actions runner?
Can we please get a break?
Praying to the security gods.
It seems like we've have non-stop supply chain attacks for months now?
Expect to continue for years to come
This is the break right now, we will smile back on these times
Another day, another supply chain attack involving GitHub Actions.
GitHub was down too! Its uptime has been so bad recently.
It’s the new Npm
Don't GitHub Actions actually use npm?
Once again, it is in the NPM ecosystem. OneCLI [0] does not save you either. Happens less with languages that have better standard libraries such as Go.
If you see any package that has hundreds of libraries, that increases the risk of a supply chain attack.
A password manager does not need a CLI tool.
[0] https://news.ycombinator.com/item?id=47585838
> A password manager does not need a CLI tool.
A password manager absolutely does need a CLI tool??
I guess anyone/anything using a non-graphical interface should just not use a password manager for some reason?
Not to mention that a graphical application is just as vulnerable to supply chain attacks.
> A password manager does not need a CLI tool.
Why not? Even macos keychain supports cli.
The above comment is just a bunch of generalizations not meant to address seriously that's why.
So the comparison here is that you would rather trust a password manager with a CLI that imports hundreds of third-party dependencies over a first party password manager with a CLI that comes with the OS?
I don't think macOS Keychain uses NPM and it isn't in TypeScript or Javascript and, yes it does not need a CLI either.
The NPM and Java/Typescript ecosystem is part of the problem that encourages developers to import hundreds of third-party libraries, due to its weak standard library which it takes at least ONE transitive dependency to be compromised and it is game over.
You initially complained about CLIs, not the dependency mess of the JS ecosystem.
You still have not said why this is an issue of having a CLI.
> You initially complained about CLIs, not the dependency mess of the JS ecosystem.
I complained about both. What does this say from the start?
>> Once again, it is in the NPM ecosystem.
> You still have not said why this is an issue of having a CLI.
Why do you need one? Automation reasons? OpenClaw? This is an attractive way for an attacker to get ALL your passwords in your vault. The breach itself if run in GitHub Actions would just make it a coveted target to compromise it which makes having one worse not better and for easier exfiltration.
So it makes even more sense for a password manager to not need a CLI at all. This is even before me mentioning the NPM and the Javascript ecosystem.
>Why do you need one? Automation reasons? OpenClaw? This is an attractive way for an attacker to get ALL your passwords in your vault.
I need one because I am not always using a graphical interface. What exactly in a GUI do you think makes it harder/less attractive for an attacker?
If the GUI code is compromised in the same way as the CLI, it'll have the same level of access to your vault as soon as you enter your master password.
It does not much matter if it imports 300 or 30 of them, those vulns will land somewhere in those 30 with equal frequency statistically. If you are advocating developing without dependencies at all, then please start (with any language) and show us all how much you actually ship.
JS is a target of these dumb accusations because it's literally the best cross-platform way to ship apps. Stop inventing issues where there are none.
Yeah Im going to have to agree with this
> A password manager does not need a CLI tool.
That's a wild statement. The CLI is just another UI.
The problem in this case is JS and the NPM ecosystem. Go would be an improvement, but complexity is the enemy of security. Something like (pass)age is my preference for storing sensitive data.