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).
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.
> 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].
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.
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).
Passwordstate doesn’t seem to have automatic update and the update process is mildly annoying, so I can’t imagine very many people were unlucky enough to update during the couple of days they were compromised.
Not saying this isn’t very concerning from Click Studios, just that the number is going to be a lot smaller than 29,000.
I have couple of ways of dealing with the problem.
-- Pen and paper? It is still a thing and cannot be stolen online.
-- If you are afraid your family will access it without your knowledge, use tamper evident bag and a notepad to make notes of bag serial numbers. This prevents anybody from accessing it without your knowledge.
-- Split the password into components so that even if somebody gets access to the piece of paper with the password they still can't log in. I make a note of the variable part of the password and remember a different prefixes/suffixes. I use different prefixes/suffixes for different classes of accounts. For most critical accounts I don't reuse anything.
-- Use hardware (yubikeys) as second factor, to lessen pressure on the password. Unfortunately almost nobody implements these well. In most cases it is possible to turn off the second factor without presenting second factor which basically nullifies the value of it. If you use second factor on a site that implements it well, remember to have MULTIPLE copies of it. Keep it in triplicate, one with you, one in tamper evident bag and one offsite.
Pen and paper doesn't work when you have hundreds of 20-char good passwords and it doesn't work for backups if you regularly create new ones. You need search and you need to sync the new entries to offsite backup as they are created.
Do you carry this around with you, or is it just for high-value passwords? I regularly have to log in to things, carrying a notepad of passwords with me would be inconvenient and dangerous.
Easy integration with browsers and so forth which significantly simplifies UX, especially for less sophisticated users. Built in password/passphrase generator. Mobile device support. Search and organization functions. The ability to store other kinds of secrets like ssh keys. TOTP support. I'm sure there's stuff I'm missing but those are a few things that spring to mind.
Personally, I use keepassxc + keepass2android + browser plugins + syncthing. The idea of storing my passwords in someone else's cloud gives me the heebie jeebies...
If you're optimizing for UX you're not optimizing for security. It's just how it is.
My password manager can't communicate with anything, it's local only. It runs on a separate host so no, it doesn't have any browser integration. A browser is way too complex attack surface to trust. Only way I get a password is to ssh into the isolated host, decrypt password and cut & paste.
> If you're optimizing for UX you're not optimizing for security. It's just how it is.
Security can never be perfect. It's a lesson in trade-offs.
For example, if you make security so hard or inconvenient that people won't engage in secure behaviors, then in the end you're worse off.
This is the reason password rotation has fallen out of favor lately.
If in general we did away with password managers and took your lead, I guarantee we would collectively be worse off because, for most folks, what you describe would be seen as way more trouble than it's worth.
Your black-and-white take also fails to account for varied threat models.
Remember, the most common threat model online today is service breaches leading to passwords being exposed, followed by credential stuffing. Password managers encourage practices that eliminate that threat model.
If your threat model is centered on password manager service breaches like this one, then use a solution that doesn't require cloud hosting (e.g. keepass).
So now we need to worry about device breaches, which requires hackers to go after individual users (either targeted or untargeted), which has a much higher cost/complexity. We've made the hackers job a lot harder, which is good.
And if your model is centered on device breaches, well, bad news: your browser already sees your passwords go by (among many other things), so if the device is breached, you're hooped, password manager or no password manager.
I think about making something similar. Though the direction would be in reverse.
Say a Pinephone with no way to ssh into by default that is normally powered off. No services listening on the network running on it + strict firewall.
It can only initiate connections to other devices.
Unless I want to sign a ssh key from a CA stored on it or provide a password to some of my other devices it's just powered off. All of DRAM is cleared prior to shutdown. Pinephone can boot to UI in ~2-3s so it would not be bothersome to keep it normally off, and boot up only when needed. Battery would last months for a single charge for this use case.
It would run just a few processes. Init, maybe wpa_supplicant for wifi, and a UI process. Very simple SW, extremely limited attack surface.
Pinephone has a nice feature that it can emulate any USB device, so I could connect it over USB to any machine, and just make it look like a keyboard, and just type in the username and password into a focused field, for the password filling feature.
If I want to create a short term ssh certificate and sign a SSH key for access to a customer machine, the phone would connect to my workstation/notebook/whatever directly over ssh and sign/upload the certificate.
> A browser is too complex but an OS and SSH aren't?
Yes, most certainly.
A browser is running adversarial third party code all the time as a matter of course. While browsers do a good job at isolating, expecting this to be perfect is way too fragile for a security critical requirement like putting all passwords in one basket.
An isolated and minimized OS install, much easier to harden. Never runs any code you don't know about.
They don't rely on transferring the password via an insecure channel - your clipboard.
Other applications can sniff the clipboard, you might accidentally copy another of your credentials into website or you might forget to clear it after use and then later accidentally paste it into an irc-channel.
There is also risk of visually exposing the password in the text editor, either to someone else in the room, screen sharing or screenshot from another malicious app.
A bit into the tinfoil-hat side, but it's passwords we are talking about after all.
I have a hard time imagining getting any useful (maybe I could review PRs?) work done on a smartphone, also my company didn't give me one and both they and I have a strict policy of not mixing personal and work devices.
In my case, the most critical passwords are memorized and are not stored in any other medium after the brief period that it takes to memorize it. Simply put, I saw a breach like this coming and I anticipate many more in the future. Simply put, password managers are too big of a target.
As for the rest, a written record is sufficiently secure since most of those login credentials aren't protecting anything important. I also have a tendency to avoid services that require a login.
My browser already sees all of my (web) passwords anyway. Therefore, using the browser's built-in password management reduces the number of external entities I need to place my trust in.
Though fair enough when it comes to enterprise features.
Just note them down in a book? I know, it sounds stupid, but nowadays it's a lot easier to keep a small booklet save than a digital file on a connected machine.
It is strange how people get blinded by technology and forget about oldest, most reliable methods.
I have worked as a security officer at a credit card acquirer (basically, processing credit card transactions between terminal and the bank).
The process to safeguard your PINs is extremely complex but at the very end relies on pieces of paper with passwords and key components written down, put in tamper evident envelopes and then into safes.
You're describing backups. The base derivation keys still have to exist in an HSM to be used. No one is opening a safe and hand-typing the BDK each time they need to issue a PIN encryption key.
It is not a backup. Backups are made just in case.
In case of HSM keys, the HSM itself is built to loose those keys at the least pretense. It is also not possible to retrieve the keys.
So whenever you want to provision a new HSM or even just move it couple centimeters (it looses keys when you try to move it) you have to go to the components written on paper.
It is just like a password on a website -- you have to be entering it regularly. But once you enter the password you don't need to retype it for every HTTP request.
I used to do this. It fell apart fast. Some websites require special characters and numbers and upper and lower case letters. Others actually prohibit certain special characters (weak SQL injection "prevention"). Some limit the length to 8 or 16 characters, others don't.
Then a random breach happens, and the website will force you to choose a new password.
I couldn't remember which variant of my rule I used at a particular website. This is aside from how easy my rule was to reverse engineer (which was made really clear to me once when I saw a couple of my PWs on haveibeenpwned
You can have different variants so you try one and if that's not it then you try the backup/alternative. In my case, this was only a problem with a couple of websites which I rarely used. I just did a password reset every time I wanted to log into these websites.
Then the passwords are not secret, the rule is. And figuring out a rule with a couple of examples is much easier than breaking into an encrypted, properly secured password vault.
In case I'm losing you, here's a parallel: if I ask you to pick and remember a random number between 1 and 1 billion, the odds of me figuring it out are low. But if I ask you to pick and remember 200 numbers between 1 and 1 billion, you will likely come up with "a rule", and then if I get a couple of example numbers (in a "password leak"), i can probably figure it out. The numbers are no longer secret, it's the rule that is.
That depends on the type of threat being protected against. If the threat is a mass exfiltration of passwords, this method will probably work fine since nobody will bother trying to figure out that one weird trick to get this one person's passwords when there are a few million others to work on. If the threat is someone targeting you specifically, then you might need a better system.
For somebody to guess your rule they would have to have an access to a number of your passwords.
Also, what the rules is is completely up to you. Be inventive.
If it comes to reverse engineering your rule it means you are facing a targeted attack. Believe me, you can't prevent a targeted attack by a good password.
It is better to have one rule to generate a lot of passwords that are good on their own and independent enough than have small number of passwords shared between many services.
Well it could be your own secret hashing or concatenation algorithm which you can do in your head. For example, you could use parts of the domain name to map to a specific word from a list that you've memorized. But there is an infinite number of rules you can choose from so you don't lose any security.
Agreed. Password managers are an awesome thing, and yet, thus they present an extremely juicy attack target. Too many eggs in one basket.
It's an area where the right answer is to give up some convenience for better OpSec. Use a local-only password manager that can't communicate anything to anywhere.
You does your risk assessment etc etc. For some those are not a combinatorial red flag - for you it seems they are. There are a lot of things to consider and not one of us here can possibly say they've got it all covered. No one ... ever 8)
This morning my home doorbell didn't ring and a phone alarm didn't wake someone up. Two almost unrelated fails. As a result we missed an appointment which we fixed an hour or so later.
Right let's do the analysis: Doorbell is a Doorbird. I've got it running on a ethernet connection via PoE. All my home IT stuff is on UPS. I have a decent router that I know very well. I don't skimp on my home gear and I have a quite large VMware esxi which runs my home servers and stuff. I use Home Assistant which has a Doorbird integration and when you press my doorbell all my Sonos speakers say: "Ding dong, there is someone at the door".
I got it wrong: I thought that my HA box spoke directly to my Doorbird or vv. No it doesn't - it is all done via their API and that means internets.
Today I wired up a simple door chime to my Doorbird which will ring regardless of internets. The chime cost £10. The Doorbird has a chime output which isn't latching but good enough to make a chime ... chime.
It seems to me there's a trend around "enterprise" software having weaker supply chains than the more nimble and agile tools.
Perhaps mindset related? Larger teams needed to meet enterprise needs? Or simply more focus on the sales machine to close complex enterprise deals, and less focus on securing the pipeline through which the product is made?
Solarwinds is a great example of this - "big enterprise software" used by big enterprises, and yet their whole build infrastructure was compromised as it ran with less security thinking than your average open source project (which at least discards build environments each run).
As far as getting actual password data, yes, the attack surface is the clients, and as the most common client is presumably the browser plugin, it's probably the most likely to be attacked.
From my interactions with LastPass' support, I'm not sure. They rely on security by obscurity in some parts, I wouldn't be surprised if they did in others.
I run Keepassxc in a VM with no networking enabled, and no networking stack enabled in the VM. The clipboard is shared 2-way with the host. I keep the DB on a shared volume so it can be backed up by the host machine.
Nothing is ever perfect. Password managers are good thing and vastly more pragmatic than the folksy homemade "nuclear-launch-code" alternatives some HN'ers describe here.
These days I generally don't trust any security product. They are as much malware themselves as the malware which they claim to protect you from.
- Many security software providers are hackers or ex-hackers... So you're basically paying hackers to protect you from themselves. Why should I trust software which is almost 100% guaranteed to have been written by hackers more than any other random software I might download from the internet which has maybe a less than 1% chance of having been written by a hacker?
- The software security industry is more about selling security products than actually helping to keep people and companies secure. The incentives are to sell peace of mind while keeping systems vulnerable (don't kill the goose that lays the golden eggs).
- Most security products capitalize on fear rather than genuine threats (security tools tend to show lots of false positives to draw attention to themselves or to upsell additional software).
There's a distinction between "protection" security software such as antiviruses and VPNs which indeed is an industry filled with scams and conmen, and utility security software such as password managers.
Most of the big name password managers are very good. The only one I'd recommend avoiding is lastpass, and even so they're not that bad, just strictly worse than the others.
Emphasis on big name. 1Password, Bitwarden, keepassx(c), and whatever microsoft's was called.
> Many security software providers are hackers or ex-hackers... So you're basically paying hackers to protect you from themselves. Why should I trust software which is almost 100% guaranteed to have been written by hackers more than any other random software I might download from the internet which has maybe a less than 1% chance of having been written by a hacker?
Because the hackers know how other hackers are going to try to break it. Most developers pay literally no attention to the security of their code.
I have +1000 entries in my KeePass. Some of them don't have a username associated. Or a service (passphrases to decrypt private keys for instance). I use different usernames for different aspects of my online life anyway. I also store the randomly generated "mother's maiden name" or "name of first pet" in the entry notes.
When you have a simple software managing this mental burden for you it expands your possibilities.
At that point add a 2 to the end or change your username. Worst case you have to try a few times to get in, but eventually you'll remember it's one of those sites that uses the extra version information.
As a side note, trying various passwords doesn't strike me as a great idea either. You're basically telling the site you're trying to log into your other passwords you use, along with a username. At the very least you're revealing something about how you derive your passwords, if you have some scheme.
I'd say that if I'm not sure about the right password, it's safest to go straight for a password reset function, instead of giving all my passwords or a password derivation method to some random website.
This can be an OK strategy as long as your salting algorithm is not easy enough to figure out by looking at a few password breaches that you (now or in the future) are exposed by.
It can work if you’re smart about the algorithm, but if someone can guess your algorithm by looking at a few leaked passwords, it can provide a false sense of security.
That’s a thoughtful consideration. My logic is that a personal salting algorithm could be compromised after several points of failure, whereas a password manager can be compromised by a single point of failure.
The former requires trust in myself to create a strong algorithm, and the latter requires trust in a black box.
It doesn't have to be a black box. There are open source password managers. Bitwarden and Keepassxc are two very good ones.
And keep in mind that even if you can create a reasonably strong algorithm which will both be memorable and resistant to reverse engineering, most people won't. Password managers aren't just good for professionals, they're leagues ahead of anything "mere mortals" use. My mom uses 1password -- that's not a slight, I mean that literally; I put her on my family plan.
I’m in support of password managers if they promote better security hygiene for the average user. Particularly, preventing the most heinous of all password crimes: reuse.
I use an open source password manager, but in the end, I still "trust a black box". I never looked into the source code in detail, nor would I have the knowledge to find some vulnerabilities that later can be used to expose my passwords. It might not be a black box for you, but for all intents and purposes it is for me.
I don’t need convincing arguments. A software password manager is a single point of failure, as the story demonstrates. It’s a dangerous external dependency with alluring convenience.
Until mind reading becomes reality, nothing will ever be as secure as human memory.
And your mind, or whatever algorithm you came up with, isn't a single point of failure?
You will never be one thousandth as good at securing hundreds of password as the most robust tools we have today. You may be good at remembering a couple of long, random passphrases. You can use those as a master password / encryption key.
The software mentioned in the article is not a particularly good or trustworthy password manager, so no it doesn't make sense to put it in the same lot as the actually-good ones.
Or to put it another way, if I come up with a crappy off brand version control software and backdoor it, that doesn't reflect badly on VCS, it reflects badly on me.
I admit that there might be password managers out there that provide sufficient security for some users’ threat models, but I wouldn’t trust such a sensitive compilation of data on any computing system, especially ones with network access.
If I used a password manager, it would have to be on an airgapped and password protected system, making it essentially useless for me. For me, it’s easier to memorize a password/salting algorithm that generates unique passwords to the website or service I’m using, so that I don’t have to actually memorize any passwords—only the algorithm.
This is a common take on password managers but in practice it doesn't really hold, because humans are bad at security and good password managers are really fucking good at it. That's not to say there aren't weaknesses to the password manager model, but you're overestimating them and underestimating the ones in your scheme.
I also invite you to read my response above to someone else regarding the security of such an algorithm: with some examples, brute forcing an algorithm is easier than brute forcing a master password.
The issue is that password managers skew the cost/benefit analysis of an attack, thus altering the risk profile for the individual. As long as your password creation/storage method is strong enough to thwart low motivation/low resource parties, you may be better off than being in a very attractive pot of millions of credentials.
That's why I never used and will never use a password manager... You can't get more security by trusting more intermediaries with your passwords. When it comes to anything that matters, you want to trust as few intermediaries as possible.
The more entities have access to your passwords, the less secure you are. I can't believe I even have to say it, it seems so obvious.
Why not just remember your passwords? There is an infinite number of strategies and secret rules which you can use to easily remember your passwords.
Or for low-importance services, why not just use your browser's built-in password manager? You have to trust the browser maker anyway.
If you think the concept doesn't make sense, consider that you do not understand it.
Highly respected people whose entire careers is security will disagree with you. I'm not telling you to take an argument for authority, but maybe do some introspection about who is more likely to be correct there...
Edit: Parent comment edited out some really outrageous claims, so my reply no longer makes as much sense.
Of course security folks who stand to profit from selling these password management solutions will insist that these solutions are important... After all, like you say, their whole career depends on selling 'security products' to companies and individuals. This kind of argument would never stand up in court because of conflict of interests.
About the edit, the meaning of my comment hasn't changed. I just removed the phrase "the concept doesn't make any sense" and expanded it to explain why it doesn't make any sense... It's dishonest to say that I've made an outrageous claim or changed the meaning of the comment in any way.
But it's good that expanding my reasoning has led you to reconsider the validity of your argument.
Who stands to profit from FOSS, self-hosted password management solutions (e.g. Keepass) then?
Generating long, high-entropy, unique passwords and then not relying on your brain to remember (and your fingers to type) is always going to be more secure than doing it the hard way for its own sake.
> But it's good that expanding my reasoning has led you to reconsider the validity of your argument.
What I meant is that my first sentence, which references something you removed from your original comment, sounds very out of context now.
And no, none of the folks I'm thinking of actually make money from password management solutions. Your comment sounds the same as "of course all those doctors would recommend getting vaccinated since they make a profit from selling you the vaccines".
>> And no, none of the folks I'm thinking of actually make money from password management solutions.
Not directly, but maybe their peers do. If your buddy works at Facebook, you're not going to say bad things about Facebook's business. It also applies to some extent if it's your friend's friend; group-think is a powerful effect.
>> Your comment sounds the same as "of course all those doctors would recommend getting vaccinated since they make a profit from selling you the vaccines".
Well of course that's a factor to consider. The medical industry is not immune to ulterior motives. For example, doctors have been known for over-prescribing opioids and many people actually died as a result. I'm pretty sure all these doctors thought they were doing the right thing; all their colleagues were also prescribing the same drugs.
Also many drugs which received FDA approval were later found to be unsafe, caused birth defects, deaths etc... It's foolish to suggest that anything is 100% safe and ulterior motives will certainly have a negative effect on safety.
I have several buddies who work at Facebook and i think Facebook is evil and one of the worst companies to work for in tech. They know my stance on it, now you do too, and I've disproven your opening argument.
I didn't mention opioids did i? I'm going to ignore further comments from you in this thread because this has all the hallmarks of a bad faith discussion. Assuming that's not your intention, maybe do some introspection on why that is.
> You can't get more security by trusting more intermediaries with your passwords.
I would agree, were it not for the fact that every worthwhile password manager never sends your passwords to any intermediary. There is of course some risk related to the strength of the encryption, software updates/supply chain attacks, client backdoors, etc; however, in most scenarios that is far outweighed by the additional security on a "link in the chain" which is much more likely to be attacked (better credentials - higher entropy, better rotation, and so on).
> The more entities have access to your passwords, the less secure you are. I can't believe I even have to say it, it seems so obvious.
You're right, it is obvious, that's why those entities don't have access to them!
> Why not just remember your passwords? There is an infinite number of strategies and secret rules which you can use to easily remember your passwords.
That is incredibly low entropy. This will likely prevent you from falling victim to a simple dictionary or credential-stuffing attack, but not much else.
> Or for low-importance services, why not just use your browser's built-in password manager? You have to trust the browser maker anyway.
Well, that IS a password manager. And as to why not use it, because in an enterprise environment you should probably have automatic/encrypted/signed sharing, as well as logs of who accessed a password, who modified a password, etc.
By the way, I just want to point out that your "password manager" could be "rot13 and write it down in a notebook and put it in a locked cabinet". Or it could be "put it in a text file and GPG-encrypt it". There are plenty of options available which don't involve even trusting the code of any third-party.
>> every worthwhile password manager never sends your passwords to any intermediary
Except in cases where the password manager is 100% open source, the people who wrote the password manager are intermediaries. As I said, you need to trust an additional intermediary.
And as I said, a password manager can be a physical piece of paper that only you ever see. There is absolutely no need to trust an additional intermediary unless you choose a password manager which requires that. And additionally, you can choose exactly how much trust you put in the intermediary, because there are many password managers out there to choose from.
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.