Hacker News Reader

Comment by 1cvmask | Hacker News Reader

Just to clarify the title. It was not a deliberate backdoor on the part of Passwordstate. It was a supply chain attack. There is some history to their security holes (most of the known ones being patched).

https://twitter.com/juanandres_gs/status/1385689464329187329

https://github.com/NorthwaveSecurity/passwordstate-decryptor...

A potential issue in the password management space is that Francisco Partners (owner of NSO Group) owns Lastpass (and LogMeIn).

https://en.wikipedia.org/wiki/NSO_Group

https://www.globenewswire.com/news-release/2020/08/31/208621...

Note: I work in the IAM and PAM space and designed dashboards for saas pass.

View on HN

Password managers seem to be the most critical software where open source and reproducible builds are needed. Are there any good FOSS password managers that can do remote sync and team permissions?

Bitwarden seems to tick the boxes you need - FOSS license, syncs via an (open source) server which you can host yourself, or use their hosted version, and there's team versions available.

It's pretty good. There's also bitwarden_rs (a rust-based server component) if you fancy a simpler self-hosting stack that doesn't require SQL server.

The solution has been audited, I believe, but audits are only valid at individual points in time. The only downside for me is the use of electron and web technologies in many of the clients - that for me is a huge attack surface of complexity that few people can fully understand and manage.

Any idea why Bitwarden insist on their installation ID generation for self hosted deployments? it strikes me as unusual, as it's not documented WHY it's necessary, or what the ID is used for, only that you're required to give Bitwarden your email address to get the necessary ID.

If they would remove this step, or at the very least explain it, I'd be more likely to deploy and use it. Critical things like password managers should be self hosted where possible, IMO, and this is a blocker preventing trivial deployments.

As far as I remember, it was used to pass API requests for third party services (like APNS) through the main Bitwarden servers so Bitwarden's secret keys for these services weren't published, but self-hosters wouldn't have to register and manage their own accounts for these services, which can be complicated and expensive (To get access to APNS you have to pay the $100/yr apple developer subscription and you can only use it for your own apps, so you would have to build and distribute, via the app store or testflight, your own build of the app.

Bitwarden says they are hashed and encrypted with your email and master key before leaving your device so it is not possible to get them even if they are ever hacked.

So far so good, but how do they protect from hacking or from Bitwarden employees the shared secrets in an organization? I understand that each member of the organization team has their own master key.

> Bitwarden says they are hashed and encrypted with your email and master key before leaving your device so it is not possible to get them even if they are ever hacked.

This part makes electron apps even a bigger problem, because if hacker owns the app that's the point where they can grab the password before it's encrypted.

The mobile clients are written in Xamarin https://github.com/bitwarden/mobile

> Are there any good FOSS password managers that can do remote sync and team permissions?

Depending on what remote sync and team permissions looks like at your end, you could perhaps get there with KeePassXC [0] (password manager) and a separate sync tool (that did your sync and, effectively, your permissions management) such as Keybase KBFS [1] or SyncThing [2].

[0] https://keepassxc.org/

[1] https://book.keybase.io/docs/files

[2] https://syncthing.net/

I use KeePass + dropbox. Works on windows and android.

I'm pretty sure you don't need to trust the syncing software, so anything should work. Someone please correct me if i'm wrong

Syncing software could perhaps do so cyphertext malleability attacks. Changing the ciphertext, and deducing information on the plaintext based on client behavior.

Perhaps they could force you into a password reset for a specific site by corrupting the correct files. That might be an interesting first step for an account takeover.

These are highly complicated, active attacks. I wouldn't worry as long as your sync service isn't literally the Russian or Chinese government.

> Perhaps they could force you into a password reset for a specific site by corrupting the correct files. That might be an interesting first step for an account takeover.

It would be interesting to see that accomplished without making it obvious (particularly: without corrupting large parts of or the entire database). KeePass encrypts the whole database.

FOSS won't help you very much unless you're willing to build your entire tool chain from vetted source.

http://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thom...

That's like saying that seatbelts don't help very much, unless you're willing to wear a motorcycling helmet, and install a roll cage in your car.

In the worst-case scenario, no, your seatbelt won't help. I'm still going to wear one.

The difference is that the interior of your car is not typically an adversarial environment.

The exact moment that you need a seatbelt is the same moment your car's interior becomes an adversarial environment.

"Adversarial" in this sense is meaningfully different than "dangerous" - at no point is your car trying to outsmart you.

You're right, the car isn't trying to outsmart anyone - physics is trying to outsmart engineers.

Nah, physics doesn't need to try :D

That really depends on your threat model. Every effort to reduce your attack surface increases the effort needed for your adveraries. Your "won't help very much" is only true for the trusting trust problems in the paper, i.e. if you need to survive state sponsored attacks

Trusting Trust actually says that vetted source isn't enough! Fortunately it's been defeated (https://dwheeler.com/trusting-trust/), such that vetted source and multiple compiler executables that are unlikely to be compromised in the same way can be enough if you use them carefully (which, to my knowledge, we don't).

this https://www.passwordstore.org/

its "just" a wrapper around gpg and git.

so add/crypt with the team and push. and you can do team shared keys if that's your thing.

oh, and passbolt is not terrible either.

I use Password Store for these use cases and with yubikey tap-to+decrypt which makes bulk exfiltration of passwords virtually impossible.

According to Wikipedia Francisco group sold out of NSO in 2019, is that correct?

Reply on news.ycombinator.com