Menu blog

How to Respond to Password Database Theft

by Ross Kinder

There's been some renewed interest in a database of passwords that was stolen from LinkedIn a few years ago.

That got me thinking about how companies should respond when consumer password databases are exposed. Because it just keeps on happening.

The Risk

The risk is pretty straight forward: people re-use their passwords. And so the same person who used “cissp53176” as their password for LinkedIn probably also used “cissp53176” for Active Directory.

The incident history, both public and not, shows many instances of attackers using exposed passwords in database dumps to gain or escalate access to companies.

There is also direct risk to companies when when personal accounts are compromised. It is distressingly common for staff to use personal accounts for work. Many people don't clearly separate their personal and professional IT environments. Who among us hasn't on occasion used a personal Dropbox account to transfer a file?

What is more, the defender's burden is high–you must defend all of your accounts, while the attacker needs to find only a single shared password.

Response #1: The Email

A fairly common corporate response is to send an internal email with some combination of compassion and threat:

We really care about you, our employee, and because we care so much about you we really want to make sure you don't lose your stuff, so please change your password at $SITE right away.

The problem with this email is that it doesn't address the issue of re-use. A reasonable recipient might say “I don't really use LinkedIn for anything important, so I don't need to take action.”

Then the threatening part:

Remember when you signed our 28-page policy document during your annual security training? Remember how it said THOU SHALT NOT REUSE YOUR PASSWORD? Don't make us fire you! 'Cause we can fire you if you violate any one of our hundreds of policies. Because we're the security team and we're important.

This kind of message is both ineffective and mean. It is ineffective because fear is a terrible way to get people to make good decisions, and mean because few people are really getting fired for carelessness (absent bad intent, that is).

But the real problem with these messages is the numbers. Even if these messages were 99.9% effective at preventing password re-use (which they aren't), the adversary now has a list of possible accounts and their passwords. Only one password needs to be reused for the attacker to win. In other words, begging people not to reuse their passwords has no substantial effect until 100% of people comply.

Response #2: Gettin' the Goods

Another reasonable approach is to try to get your hands on the actual password database and figure out if your user's passwords are in it.

I've worked on collecting and analyzing password databases a few times (although nowhere near as much as others). It is surprisingly difficult to get right. A few of the many reasons this is tricky:

  • The people probably (hopefully!) didn't use their work email addresses, so the email address isn't a good identifier.

  • It is surprisingly tricky to match up different versions of the same name. For large data sets and large organizations you'll suffer from both false positives and false negatives. (There are many people named Sally Jones, most of whom don't work for you. Similarly, Sally Jones McGillicuddy on Facebook may be Sarah Jones or Sarah McGillicuddy in Active Directory.)

  • The data may be in the form of password hashes, not the passwords themeselves. Both you and attackers can purchase the computing power required to reverse the hashes commercially, but it can be costly and tricky.

  • Your own passwords are probably (hopefully!) stored as hashes rather than the passwords themselves, which makes it tricky to see if an employee actually did re-use their password.

  • Again with the numbers. Defenders have to address every password database theft, but attackers need only expoit one. Futher some/many password databases may not be accessible to defenders because most defenders aren't willing to break the law to get them.


This problem gets considerably worse when you consider insiders–people with inside knowlege of, or access to, your network. They may have considerably more personal motivation to attack, the knowledge to target specific people, and access to non-public information, such as a company directory.

They may have physical or logical access to the non-public parts of your network, which are more likely to be protected only with a password.

Depending on how widely shared the password database is, and depending on how the passwords are stored, the technical skill required to exploit the database isn't nessesarially beyond the skills of a typical insider-attacker.

But but but … Two factor!

“But,” you say, “we've just rolled out two-factor authentication at our company so even if the bad guy got hold of our passwords, it wouldn't matter to us.”

Having a second factor undeniably improves the situation, but it doesn't eliminate it. A couple reasons:

  1. Most 2FA is implemented at network control points, but not within a network. So you might need 2FA to get into your VPN, but you don't need it to get into the intranet. This is a practical consideration given the user frustration with MFA, but it doesn't protect you at all from someone who is already inside.

  2. Your security approach is probably belt-and-suspenders. The password is the belt and the multi-factor authentication is the suspenders. So, at the very least, you're relying only suspenders with no belt.

  3. Two factor authentication schemes are only as strong as their fallback mechanism. Consider if an attacker, in posession only of a user name, password and basic biographical details, could reset or re-provision your 2FA scheme.

  4. Many 2FA schemes introduce third-party trust. Consider a 2FA scheme that uses, or can fall back to, SMS. Access to your user's account with the mobile provider is sufficient to redirect SMS messages to the attacker. Consider that the user's password in the exposed database may not match their corporate password but it may still match the password they used with their mobile carrier.

Some Crummy Advice

There are no perfect or even good answers here, but there are a few practical steps you can take in response to a password data breach.

  1. Offer solutions. Don't just tell your users not to reuse passwords, tell them how to not reuse passwords. Don't complicate the subject. The only reasonable advice is “Use a password manager.”

  2. Treat your users like the adults they are. Explain the reasons for your concern directly. They understand more about their threat model than you do.

  3. Prepare. Understand how you'll search for affected users following a public password dump and understand how you'll respond. Bear in mind that a breach might affect every single one of your users.

  4. Have Reasonable Password Policies. Password re-use may be the result of over-zealous password policies. NIST has relaxed its recommendations.

I don't really like any of this advice, but it’s the best I've got. I'm asking you to spend too much time & effort on activities that won't do a particularly good job of reducing your risk.

At, we believe that the right way to fix this problem is to eliminate the password all together. With no credential to re-use, third-party password database theft might not require any response at all.