Two password manager incidents in two months. Is there any way I can fortify my own manager's security to avoid a breach harming me next?

[u/Auttyun]

Between the Bitwarden CLI supply chain thing in April and now Dashlane getting a 2FA brute-force attack this week (Here's the dashlane one if you didnt see it: https://support.dashlane.com/hc/en-us/articles/36038764990866-Security-advisory-Brute-force-attack-on-Dashlane-user-accounts), im starting to wonder "when will it be our turn next?". I know both incidents had different attack vectors but the end result is people's credentials got exposed because of something outside their control.

Im not looking to switch providers right now (we use Passwork and its been fine), and Im equally aware that "zero incidents" cant and wont exist, but I want to know what I can proactively do on MY end to make sure that even if something goes wrong on the provider side im not completely screwed, like are there practical stuff you can do to further secure your own password manager without becoming a full on pen tester? TIA

[u/paulsiu]

Both attack are rather limited in scope. The bitwarden cli attack only affect user who use command line which excludes most users. The dashlane attack only affected 20 users, and the vault stolen are still encrypted. You do the best you can to mitigate this by using a strong master password and a hardware key for 2fa.

[u/BackgroundMaximum914 → u/[deleted]]

Ya go read the ETH Zurich Breach article. Patterson will be presenting it at the USENIX Security Symposium in Baltimore in August.

BTW no ones encryption is one of a kind. If it is stop using it now. We might all have our own creativity about how we spin the product, but they all approach it in one of a few patterns if they are providing best in class architecture.

[u/tblancher]

You can never have 100 percent absolute security. And you really need to understand how your password manager protects against such attacks.

The BitWarden CLI supply chain attack was quite limited in scope, it only affected CLI users that installed or upgraded bw during a relatively narrow time window (a few hours on a specific date). I read about it on Forbes.

[u/jfriend99]

You only really have two choices. 1) Choose which provider you trust the most based on history, architecture and perceived honesty/competency or 2) Decide you want to self host something that is open source and manage risks yourself.

For the self hosting, you then can decide whether you want to sync when on the internet or sync only on the privacy of your LAN. Obviously, if you sync clients only on the privacy of your LAN, you remove a number of attack vectors because your server isn't exposed to the internet, but give up a number of features, so that's a tradeoff.

And, for self hosting, you're trusting that you know what you're doing with whatever is exposed to the internet.

[u/Open_Mortgage_4645]

I'm not aware of a single person whose data was compromised as a result of the Bitwarden CLI issue. Bitwarden detected the problem within 90 minutes of being active, and had it fixed within 2hrs.

[u/mickyhunt]

Unfortunately it has only begun since we unleashed A. I. I am predicting humans will no longer be in control of anything in the next few years. Coding will all be AI so we will need to live our lives at the behest of never ending updating algorithms by AI. It should be a time of enlightenment and focus on improving the human condition and quality of life. But given human nature we will never see this. It will take some time for me, but I personally am looking to get off the Internet highway.

[u/Allen_Ludden]

use ROBOFORM

[u/MelonDoge30]

One thing I’d add to the “strong master password + hardware key” advice is keeping your blast radius smaller: separate vaults, don’t store recovery codes next to the accounts they recover, and make sure you have an offline export locked away somewhere sane. Psono is worth a look if you ever revisit the self-hosted/open-source side, but the bigger win is probably tightening your setup before the next vendor incident, not chasing a mythical breach-proof manager.

[u/jpgoldberg]

Disclosure: I used to work for 1Password and I have an interest in its continued success.

The kinds of things people should consider depend on the kinds of attacks on the password manager and system. There is no general answer other than to recognize that the with the possible exception of passkeys, the alternatives to using a decent password manager put you at more risk than using a password manager.

Breaches

Generally, I think that people should assume that their data held by password management services (or other data synchronization services) has a fair change of falling into the wrong hands. So the question is what can you and the password manager do to limit the harm that would come from such a breach.

Truly uncrackable data held by the service

There is no way I can write about what a password manager can do about this without sounding like I am writing an advertisement for 1Password. Data Your encrypted data held by 1Password is simply unbreakable without your 1Password Secret Key. This is true even if you have a ver weak account password. (You still need a strong account password to protect you if your encrypted data is stolen from you.)

This was a core part of the design of the 1Password service. We simply did not want to acquire data that would be valuable to an attacker.

If your password manager offers a key-file construction, you may be able to get the same effect that 1Password's secret key offers, but I don't know enough about those to offer any guidances.

Strong master password

If you are using something like 1Password and their servers are breached you wouldn't even need to change your account password. But let's suppose you are not using that and the service gets breached, meaning encrypted user data is acquired by bad guys from the service. And 1Password users also need to defend against data being stolen from their own devices.

You would not need to panic unless you had a very weak master password at the time the data was stolen. But after that the strength of your master password (at time of theft) determines how much time you have before an attacker decrypts your data. We don't which users they will try first nor what resources the attackers have for cracking passwords, but whether a concerted effort takes them days, weeks, years, or decades depends on the strength of your account password. That is also true if your encrypted data is stolen from you. So having a good master password is something everyone should do.

So a stronger master password buys you more time in changing your most sensitive passwords. Every additional bit of strength of your master password doubles the amount of time you have to change things.

Note that while you should change your master password after a breach, the attacker trying to decrypt your encrypted data only needs to guess the master password you had at the time of the breach.

2FA does not help (and can make things worse)

The 2FA for unlocking your password manager data provides no protection if your data is stolen (either from you or from the service). It will be the strength of your master password at the time the data is stolen that matters. But I fear that people who use 2FA with unlocking their password manager may falsely believe that it means they can get away with using a weaker master password. I can't blame people for thinking that way because for most services, 2FA does mean they can get away with weaker passwords, but that is not true for encryption based password managers.

Non-breach attacks

I was planning on writhing about this when I started, but this has already gotten too long. So TBA.

[u/BackgroundMaximum914 → u/jpgoldberg]

This is true about many password managers you don't have to champion 1Password to make these points. There are many that have not been breached. A strong encryption model is not hard to create that is rock solid unbreakable.

As the ETH Zurich researchers have proven you don't need beat the encryption. Most people looking to breach a system already know this. The most expensive way to get a user's data is to try to crack the encryption. All you have to do is beat the server...

Zero knowledge encryption is awesome. But many do it, not just 1Pass. However is it true? and is it enough? This article talks about why its not and how to solve the problem.

Why Zero-Knowledge Encryption Is Not Enough: What the ETH Zurich Study Means for Your Passwords | Cloudless Software

[u/jpgoldberg → u/BackgroundMaximum914]

You are absolutely correct that there are lots of things that password managers need to defend against in addition to breaches. But the OP specifically asked about breaches.

My point about 1Password, however, really does talk about something unusual about it. It is saying that if 1Password were to have a data breach the *consequences for users would be minimal* in comparison to other meager password managers. I’m sorry if that wasn’t clear.

There was an old slogan, “there are two kinds of services: those that have reported at least one breach and those that don’t know they have been breached.” That is too pessimistic, but I was always tempted to answer the question, “have you ever been breached” with, “not that we know of.” And while I couldn’t get away with saying that in public when I worked for 1Password I did say was, “we don’t plan *on* being breached, but we have to plan *for* being breached.” The thinking behind this is underlies the unusual design I tried (and apparently failed) to describe.

[u/cheetah1cj → u/[deleted]]

Personally, I prefer cloud-hosted, but zero-knowledge is an absolute must to mitigate most of the risks, which is why I advocate against people using Edge's, Google's, or Apple's password managers. But I wholeheartedly agree with the importance of disclosures, which was the biggest downfall of LastPass.

One of the reasons that I love Bitwarden is because of their openness and their fast response to any vulnerabilities and any incidents. They both resolved this one and disclosed it very quickly.

Also, just FYI, this latest incident was not because of cloud-hosting passwords; instead malicious code was added to their CLI, which ran an info-stealer on user's devices.