Imagine, if you will, that dreaded day when you read in the news that the password manager you use has suffered a cyberattack and user data may have been obtained. Imagine feeling some sense of reassurance that the breach isn’t as bad as first thought, only to learn some time later that actually, it was worse than it was initially made out to be. Or, don’t imagine at all, because it happened. Is it game over for password managers? I sincerely hope not.

While the breach and subsequent handling of the LastPass data breach in 2022 could (and probably will) make a great case study in the Cybersecurity Strategy and Governance subject that I teach on JCU Singapore’s Bachelor of Cybersecurity programme, I want to use this post to focus on defending the password manager and understanding how it’s better than the likely alternative. To do that, I’m going to look at three main points:

• Well designed password managers are quite resilient to breaches
• A password manager makes responding to a compromise more efficient
• Older password management methods are far worse and password-less systems aren’t a silver bullet

Let’s get stuck in.

Breach resilience

We have a reasonable idea from publications commenting on the LastPass breach on exactly what problems face them and their users. The good news is, some of these issues could be mitigated further to prevent problems in the future. To understand this, though, we must first understand how a password manager works.

How a password manager works

The idea of a password manager is very simple: it can be hard to safely generate and remember complex passwords whilst avoiding duplication of passwords across websites, so get a computer to do it for you, instead. If you protect that password manager’s data well enough and combine it with assistive technologies like auto-fill, then you can centrally store the passwords, fetching and using them whenever you need them. LastPass and its competitors do it, Google does it in both its browser and on Android, and lots of other browsers do it too.

So what information to store, and how to keep it safe? This depends on the use case, but in general, the password manager needs to know:

• Where the password is for (e.g. the domain of a website or a particular login URL)
• What complexity requirements/constraints should be applied (because shockingly, some sites restrict what can go into a password)
• What other credentials need to provided at the same time (e.g. username, e-mail address, account number)

A most basic password manager will let you search for these and get the info you need, so you can use it to login to the service you want. A better password manager will improve convenience for you by automatically filling out the required fields for you. There are other value-added features too, like detecting if your account is among a breached dataset, sparing you the effort of checking ';--have i been pwned? yourself.

Now, obviously, this data is important, and if breached, compromises at least one authentication factor, which in some cases may be the only factor in place. We don’t want that. So, we have to encrypt this data, being very careful about the conditions under which we decrypt it and hand it over to things like browsers. I’m not going to focus on the “in-use” part of protecting such data, as that is a problem that exists for all handling of data, but when it comes to encrypting the data itself, this is typically done with a “master password”. In possession of that, you can “unlock” all the other credentials. Yes, we use one password to protect a bunch of other passwords.

It doesn’t sound great when worded so simply, but there are benefits to doing it this way. For example, the master password can have strict complexity requirements yet be the only one you have to remember. Recovery methods can be applied to it. Additional authentication factors can be required in order to use it. Keys could be used rather than a password. The security features of the user’s system (TPM, fingerprint reader, OS authentication methods) could also be used to protect and restrict use of the master password.

Mitigating data breaches

For me (and for many other cybersecurity professionals and journalists), the biggest issue with the LastPass data breach was the way in which LastPass stored user “vaults” (what they call the data objects containing site, account and password information). While passwords were encrypted by the master password, other pieces of information were not. This leaks useful information to an attacker, meaning an attacker can identify vaults, sites and accounts that are more lucrative and focus their attention on cracking (or otherwise obtaining) the master password for the relevant vault.

So, the good news is that vaults must be individually attacked, but the bad news is there’s unencrypted information that helps direct those attacks and even inform other targeted activities such as phishing and social engineering.

A better solution would be encrypt all of the users data, right? Yes, but it may introduce some inconveniences that might also turn into vulnerabilities. For example, by encrypting all the data, one would need to provide the master password before being able to see if a record for a particular site exists. That might result in more frequent use of the master password, which might increase its exposure and risk of compromise. Do note my liberal use of the word “might” here.

With this in place, the provider can’t offer services such as password breach detection (seeing if any of your managed passwords were leaked due to a hack of a particular site) without going to extra lengths. It seems reasonable to have to put in extra effort to ensure anonymity of such checks, and to defer triggering a warning until a time when the vault is unlocked by the user.

We could layer the protection by only decrypting some information by default, and requiring additional authentication to actually decrypt the passwords. However, this would require key derivation and the master password is still subject to attack. But, if implemented well, it would allow password manager services to reassure users that all data is encrypted, and that some of it is never decrypted on their servers, ever.

The one-line solution to make data breaches less of a problem, then, is to encrypt more of the data. LastPass could do that. Others could too. Some probably already do. Thus, we can rest a little easier knowing that if implemented properly, a leaked password vault isn’t too big of a deal, especially if protected by a good master password or even something a little stronger.

Breach response

This section will be shorter than the previous one, because the argument is very simple. What should you do when you learn that the password to an account may be compromised? You change it!

A password manager knows all of your passwords, all of your other relevant credentials and where they are for. Therefore, it should be easy, even trivial for the password manager to assist you in changing any or all of those passwords on sites that may be affected by a breach, even a breach of the manager itself.

If we assume that the resilience discussed in the previous section slows down an attacker, then we bought ourselves enough time to render the data they’re attacking useless, and we did it quicker than a user could do by hand. This sits somewhere between a convenience function offered by the password manager and the kill switches that we’re starting to see in digital banking.

Still better than the alternative

If we stop using password managers, then what? Go back to identical or trivially different passwords across multiple sites? Not to mention that unmanaged passwords will probably become less complex again. Computers keep getting faster, such that an adequately complex password 5 years ago doesn’t cut it in 2023, because attackers can throw huge amounts of hashing resources at the problem and we can’t guarantee that all password stores use the latest hashing methods with good salt and multiple rounds. Beyond that, common usernames and e-mail addresses make identifying potential duplicate/similar passwords relatively straightforward.

An example

First, let’s assume that a user self-manages their passwords and has the foresight not to use the same password on every site. However, they only achieve this by making simple changes to the one password they already remember. A simple example of this data and its “crackability” is illustrated in the below table:

If an attacker successfully cracks any of these accounts, then they might launch an attack against other leaked accounts that share the same e-mail address, and rather than use the a wordlist or full search space, they might use the password they already cracked with a limited number of insertions, deletions and replacements. If this is the case, then cracking is closer to working on a one- or two-character password rather than the full-length password, which is comparatively trivial.

Let’s imagine now that these passwords are all managed by a password manager instead:

It seems Bobby chose their own password for one site, and perhaps that one is not as strong as the others. But, if any one of these passwords does get cracked, it gives no real basis for cracking any of the others (so long as Bobby doesn’t manually set similar passwords on other accounts too).

If the site, username and email fields in the password manager vault weren’t encrypted, then an attacker could go after all of these accounts even if Bobby had used unique e-mail addresses for all of them, but at least the passwords are different and must be attacked independently. If the same e-mail address is used, then an attacker doesn’t need the vault information; they can build a list of accounts owned by a particular e-mail address based on fields found in leaked user databases, assuming such leaks are out there.

No more passwords?

It would be nice to switch everything to passwordless. You might think that based on this article, I’m not in support of that, but that’s not the case. I believe that cryptographic keys in combination with multiple non-password-based authentication methods are much better than passwords. But, I accept that even with all the advances we’ve made, it will be a long time before all systems and services move away from passwords, even if momentum is building. To refer back to the silver bullet analogy I made in this article’s introduction, we cannot just “pull the trigger” and switch to passwordless. So, until that long journey concludes, we need password managers, and we need to keep improving their resilience to attacks.

Final thoughts

It’s a shame that the LastPass breach may have hurt confidence in password managers. Hopefully the damage (both in terms of user accounts and reputation) is limited and lessons have been learned that make LastPass and other password managers stronger moving forward.

If you don’t like relying on a centralised service to maintain your password security, then you can do it yourself, all open source too! The pass utility uses PGP keys and git to manage a repository of encrypted credentials. If setup properly, you can benefit from master passwords, hardware security tokens and more. You can even share passwords between multiple users, thanks to the asymmetric cryptography of PGP keys, which is great for admins sharing access to legacy, single-account devices or services. GUIs exist as a frontend for these tools too, such as the multi-platform qtPass application.

Doing this all yourself, however, means that you bear the responsibility of managing it. The free nature of the tools, combined with the lower uptake vs browser-integrated or value-add commercial password manager services, means that you’re more likely to hit snags, corner cases and annoyances that you have to work around. Take this from somebody who has done it: it can be done, but I’m not recommending it. And if the data gets destroyed or compromised somehow, you probably have nobody to scream at except yourself.

In closing, before you write-off password managers, try to find out more about how your password manager actually does things, and see if the defences and remediation tools offered restore your confidence in using them, because until the lass password is used for the last time, we still need them.