Why is this information sensitive? The deeper Equifax problem

As the world now knows Equifax, the credit rating company and master of our fates, suffered a data breach in May and June 2017, which revealed to criminals details of 143 million people. (I would have liked to say, “143 million customers“, but that is very far from the case. We have no control at all over Equifax and other credit rating companies collecting information about us. We are neither their customers nor users.)

The revealed data includes:

  • Social Security numbers
  • Dates of birth
  • Addresses
  • Driver’s license numbers (unspecified number of these)
  • Credit card numbers (209,000 of these)

There are many important things to ask about this incident, but what I am focusing on today is why has non-secret information become sensitive? None of those numbers were designed to be used as secrets (including social security numbers and credit card numbers), yet we live in a world in which we have to keep these secret. What is going on here?

Identity crisis

Names only provide a first pass at identifying individuals in some list or database. There are a lot of Jeffrey Goldbergs out there. (For example, I am not the journalist and now editor-in-chief at the Atlantic. But there are lots of others that I also am not.) Also people change their names. Some people change their name when they get married. (My wife, Lívia Markóczy, decided to keep her name because we figure it is easier to spell than “Goldberg”.) Others change their names for other reasons.

We have three “Jeffreys” at AgileBits, but fortunately we have distinct family names. Though sometimes I think that everyone who joins the company should just go by “Jeffrey” to avoid confusion.

Anyway, names alone are not enough to figure out who we are talking about once we get beyond a small group of people. So we use other things. Social security numbers worked well in the US for some time. They didn’t change over your lifetime (except in rare circumstances) and nearly everyone had one. Dates of birth also don’t change. So a combination of a name, a date of birth, and a social security number was a good way to create an identifier for nearly every individual in the US, with the understanding that a name might change.

Sometimes it is not a person that we need to uniquely and reliably identify. Sometimes it is something like a bank account or charge account. Cheques (remember writing those?) have the account number printed on them. They uniquely identify the particular account within a bank, and a routing number (in the US) identifies the bank. The routing number is also printed on each cheque.

Things like social security numbers and driver’s license numbers are designed as “identifiers” of people. They are ways to know which Jeffrey Goldberg is which. Occasionally getting email meant for the journalist is no big problem, but if he gets himself on the no-fly list, I want to be sure that I don’t get caught up in that net. Likewise, I don’t want my doctor or pharmacist mixing me up with some other Jeffrey Goldberg who isn’t allergic to the same stuff that I am. Nor does some other Jeffrey Goldberg want the record of speeding tickets I seem to acquire.

Things like bank or charge account numbers are used to uniquely and reliably identify the particular account. While I wouldn’t mind if my credit card charges were charged against someone else’s account, they would certainly mind, and so would the the relevant bank. (I’m going to just start using the word “bank” broadly to include credit card issuers, automobile loan issuers, and the like.)

A username on some system is also an identifier. It identifies to the service which particular user or account is being talked about. I am jpgoldberg on our discussion forums. That username is how the system knows what permissions I have and how to verify my password.

Identifiers are bad secrets

Something that is designed and used as an identifier is hard to keep secret. A service can hash a password, but it needs to know which account is being talked about before it can look up any information. In many database systems, identifiers are used as record locators. These need to be efficiently searchable for lookup.

Identifiers also need to be communicated before secret stuff can happen. Bank account numbers are printed on cheques for a reason. Now really clever cryptographic protocols – like the one behind Zero Cash – can allow for transactions which don’t reveal the account identifier of the parties, but for almost everything else, account identifiers are not secret.

Identifiers are hard to change. If you depend on the secrecy of some identifier for your security, then you are stuck with a problem when those secrets do get compromised. It is a pain to get a new credit card number, and it is far worse trying to get a new social security number. Getting a new date of birth might also be a teeny tiny problem.
The point here is that, given what identifiers are designed to do, they aren’t designed to be kept secret.

Authenticators

Authentication is the process of proving some identity. And this almost always involves proving that you have access to a secret that only you should have access to. When I use 1Password to fill in my username (jpgoldberg) and password to our discussion forums, I am proving to the system that I have access to the secret (the password) associated with that particular account.

The password is designed to be kept secret. The server running the discussion forum doesn’t need to search to find the password (unlike searching to do a lookup from my username), so it can get away with storing a salted hash of the password. Also, I can change the password without losing all of the stuff that lives under my account. (Changing my username would require more work.) Plus, my username is used to identify me to other people using the system, and so is made very public. My password, on the other hand, is not.

What banks did wrong

The mess we are in today is because financial institutions have been using knowledge of identifiers as authentication secrets. The fact that someone can defraud a credit card issuer by knowing my credit card number (an account number) and my name and address (matters of public record) is all because at one point, credit card issuers decided that knowledge of the credit card number (a non-secret account number) was good way to authenticate.

I have not researched the history in detail, but I believe that this started with credit card numbers when telephone shopping first became a thing (early 1970s, I believe). Prior to then, credit cards were always used when the account holder was physically present and could show the merchant an ID with a signature. The credit card number was used solely as designed up until that point: as a record locator.

The same thing is true of social security numbers. Social security numbers were not secret until banks started to use knowledge of them as authentication proofs when they introduced telephone banking. Before then, there was nothing secret about them.

And on it goes

Because high-value systems use knowledge of identifiers as authentication proofs we are in deep doo-doo. And it will take a long time to dig ourselves out. But we continue to dig ourselves deeper.

It is fine to be asked for non-secret identifying information to help someone or something figure out who they are talking about. I like it when my doctor asks for my date of birth to make sure that they are looking at and updating the right records. But when they won’t reveal certain information to me unless I give them my date of birth, then we have a problem. That is when they start using knowledge of an identifier as an authentication secret.

Over the past decade or so, various institutions have been told that they can’t hold on to social security numbers, and so can’t use them for identifiers. That is a pity, because those are the best identifiers we have in the US. But what is worse is that knowledge of the new identifiers is being used for authentication.

Right now, Baskin-Robbins knows my date of birth (so they can offer me some free ice-cream on my birthday). In ten years, will I have to keep my birth date a closely guarded secret so that I don’t become a victim of some financial or medical records crime? If we keep on making this mistake – using identifiers as authentication secrets – that is where we are headed.

Incentives matter more than technology

I do not want to dismiss the technological hurdles in fixing this problem, but I believe that there is a bigger (and harder) problem that will need to be fixed first: the incentives are in the wrong place.

When Fraudster Freddy gets a loan from Bank Bertha using the identity of Victim Victor, Bertha is (correctly) responsible for the direct financial loss. The problem is that there are costs beyond the immediate fraudulent loan that are borne by Victor. But Victor has no capacity or opportunity to prevent himself from being a victim. In economics jargon, Victor suffers a negative externality.

Bertha factors in the risk of the direct cost to her of issuing a loan to a fraudster. She looks at that risk when deciding how thoroughly to check that Freddy is who he says he is. Bertha could insist that new customers submit notarized documents, but if she insists on that and her competitors don’t, then she would lose business to those competitors.

But Bertha does not factor in the indirect costs to Victor. She has no dealings with Victor. Victor isn’t a potential customer. So if Victor has costly damage to his credit and reputation that requires a lot of effort to sort out, that is not Bertha’s problem (and it certainly isn’t Freddy’s problem.)

Only when Freddy and Bertha (the parties to the original deal) have to pay the cost of the damage done to Victor (Economics jargon: “internalizing the externalities”) will Bertha have the incentives to improve authentication. I don’t have an answer to how we get there from here, but that is the direction we need to head. In the meantime, if you find yourself a victim (whether you’re a Victor, a Jeffrey, or something else entirely), Kate published a post earlier this week with tips to protect yourself until we (hopefully) do get all of this figured out one day.

On Equifax, and what to do when passwords can’t protect you

Data breaches are, sadly, old hat these days. When Watchtower lets you know one of your passwords has been compromised, you sigh and mutter a few expletives, unlock 1Password, and start generating new ones. But what happens when the compromised information isn’t so easily changed, like your date of birth or social security number? That’s exactly what happened to me and 143 million of my fellow Americans just last week.

This is scary, in part because banks use this information to validate identities in the United States. Jeffrey Goldberg, our Chief Defender Against the Dark Arts, has written about this more in-depth, but in short, identifiers banks use for authentication (including SSNs) were not meant to be kept secret. This means the identifiers that were compromised are all criminals need to open accounts in our names, rack up bills, and leave us with the tab. There’s nothing to change this time around, but you can still protect yourself. Here are some steps you can take to do just that.

Keep it on ice

A security freeze is available to anyone — for a fee — and may be free for victims of identity theft. A credit freeze will prevent anyone from viewing your credit report and prevent any new accounts from being opened in your name until you lift the freeze (either permanently or temporarily). Here in Texas, fees are waived for victims of identity theft. Otherwise, it’s $10 to place the freeze on an account and $10 each time you lift it. These fees will vary by state, so be sure to check what fees apply in your state.

A fraud alert is less intrusive (and free), but it also provides less protection. With a fraud alert, businesses can still request and view your credit report, but must verify your identity before they issue new credit. This is usually done by contacting you directly, but some discretion is given to creditors to decide how they want to verify identities making a fraud alert less reliable than a security freeze. You can place a 90-day fraud alert for any reason and renew it when it expires. If you have already experienced identity theft and have filed a police report, you may be eligible for an extended fraud alert, which lasts seven years.

Constant vigilance

Whether or not you’ve been directly affected by this breach, monitoring your credit is important. Just like you monitor your online accounts for unauthorized access, you should always take advantage of resources available to you and keep an eye out for unrecognized activity on your credit report. All Americans are entitled to a free credit report from each credit reporting agency (CRA) every year. Many banks and credit card providers also offer free credit monitoring to their customers, which will alert you to any changes on your credit report. Although credit monitoring will not prevent identity theft or stop unauthorized accounts from being opened, these services will inform you of changes to your credit report allowing you to take appropriate action quickly.

Always be prepared

In essence, Experian, TransUnion and yes, Equifax, have control over our access to the standard-issue American Dream. Data held by these companies is used to determine if we qualify for a mortgage or a car loan. Employers and landlords may also perform credit checks to determine who to hire or rent to. CRAs are required to correct inaccurate information, but it’s up to us to monitor our credit reports for errors and take action to correct them. If you find an error on your credit report, Patrick McKenzie has some great advice in this Twitter thread:

He also published a blog post to help you set things right and, if you find yourself needing somewhere to store that paper trail Patrick helped you create, you can stash copies in 1Password for safe keeping. If everything looks fine now, don’t sit back. We know 1Password customers care deeply about data security and, though your credit report isn’t secret, it still contains important data and ensuring that data is accurate is how you protect it. Take the time to check it regularly and take action when needed, both in the wake of this breach and always.

If you’d like to learn more about protecting yourself from identity theft, both state and federal agencies offer free resources and services to American consumers:

Federal Trade Commission
State Attorney General’s Office
The Consumer Financial Protection Bureau

Be your own key master with 1Password

Encryption is great. By magic (well, by math) it converts data from a useful form to complete gibberish that can only be turned back into useful data with secret number called a key.

I happen to think that the term “key” that we use for encryption and decryption keys is a poor metaphor, as it suggests unlocking a door or a box. Cryptographic keys are more like special magic wands that are essential to the process of transforming data from its useful (decrypted) form to gibberish and back again. Read more

Enigma machine

Bcrypt is great, but is password cracking “infeasible”?

There are a lot of technical terms that mean something very specific to cryptographers but often mean something else to everyone else, including security professionals. Years ago I wrote about what it means to say that a cipher is “broken”. Today’s word is “infeasible”.

The news that sparked this lesson is the use of “computationally infeasible” in an announcement by Slack. Slack has announced that their hashed password database had been compromised, and their message was excellent: They clearly described what was available to attackers (usernames, email address, hashed passwords, and possibly phone numbers and contact information users may have added); they offered clear and useful instructions on what users should do (change passwords, enable two-step verification), and described what they have done and what they will be doing. And – most relevant for the technical discussion here – they have told us how the passwords were hashed.

In this case they said:

Slack’s hashing function is bcrypt with a randomly generated salt per-password which makes it computationally infeasible that your password could be recreated from the hashed form.

It is terrific that they chose to use bcyrpt for password hashing. bcrypt is among the three password hashing schemes that we recommend for sites and services that must store hashed passwords. The other two are PBKDF2 and scrypt. But Slack’s use of the term “computationally infeasible” here illustrates that one must be very careful when using cryptographic technical terms.

If you have a weak or reused password for Slack, change it immediately. Here is a guide to using 1Password for changing a password. And because the Slack app on iOS makes use of the 1Password App Extension, it is easy to use a strong and unique password for Slack.

Slack 1Password login Slack 1Password extension

If you would like to see how to use Slack’s two-step verification with 1Password take a look at our handy guide on doing just that.

 

But now back to what is feasible with password hashing.

One way hashing

When services that you log into store your password they should never store those as unencrypted “plaintext”. If they are stored as plaintext it means that anyone who can get their hands on that data file can learn everyone’s passwords. For example, Molly (one of my dogs) uses the same password on Poop Deck as she does on Barkbook. So if Patty (my other dog) learns Molly’s Poop Deck password, she can use it to break into Molly’s Barkbook account as well. This is why it is important not to reuse passwords.

Now suppose that Molly uses the password “rabbit” on Barkbook. (Have I mentioned that Molly is not the smartest dog in the pack?) Barkbook shouldn’t store just “rabbit”, but instead should store a one way hash of rabbit. A cryptographic hash function will transform something like “rabbit” into something like “bQ67vc4yR024FB0j0sAb2WKNbl8=” (base64 encoded).

One of the features of a cryptographic hash function is that it should be quick and easy to compute the hash from the original, but that it should be infeasible to perform the computation in the other direction. That is it should be pretty much impossible to go from “bQ67vc4yR024FB0j0sAb2WKNbl8=” back to “rabbit”. And it is.

Guessing versus reversing

With any halfway decent cryptographic hash function is it infeasible to compute the original from its hash if the original is chosen at random! But if you can make some reasonable guesses about the original then you can use the hash to check your guesses. Because passwords created by humans are not chosen at random, then it does become computationally feasible (and often quite practical) to discover the original based on the hash.

The actual formal definition of “one-way” for a cryptographic hash function, H(x), includes the requirement that x be the output of a uniformly distributed sampling of the domain of H. That is, considering all of the things that you can hash (under some set length), you need to pick something at random.  Otherwise a hash function might be invertible. Human created passwords do not meet that requirement and so the “computational infeasibility” of inverting a one way function isn’t applicable when its input is not chosen at random.

So now let’s correct Slack’s statement:

Slack’s hashing function is bcrypt with a randomly generated salt per-password which makes it computationally infeasible that a randomly created password could be recreated from the hashed form.

Modified Slack statement.

This, of course, is why you should use 1Password’s Strong Password Generator for creating your passwords. When your password is chosen randomly with a large set of possibilities, then it really is computationally infeasible to discover the password from the cryptographic hash.

Slowing down guessing

I mentioned that (for now) bcrypt, scrypt, and PBKDF2 are good choices for password hashing. Once the final results are in from the Password Hashing Competition and the dust has settled, we will probably have a good successor to those three. These are built upon cryptographic hash functions, but are designed for hashing specifically for when their input is not selected randomly.

Because cryptographic hashing is something that we have computers do a lot of, one of the things that we want is that it be fast. We want to be able to perform lots and lots of SHA-256 hashes per second without straining a computer’s memory. But if an attacker is going to be guessing passwords to see if they produce the right hash, we want to slow down the hashing. PBKDF2, scrypt, and bcrypt are all designed to require much more computation than a regular hash function to compute a hash. This can slow down an attacker from performing millions of computations per second to just thousands. The actual speed depends on many things, including the hardware that the attacker brings to bear on the system. scrypt, additionally, places specific demands on memory.

So the use of bcrypt means that attackers will need to do more work than they otherwise would to guess passwords stolen from Slack. That is a good thing, but it is not an “infeasible” amount of work.

What’s infeasible?

I started out by saying that I was going to talk about the word “infeasible”, but so far I have just been using it a lot. This is because its definition is abstract, subtle, and hard. I am not going to give a full definition, but I am going to try to get reasonably close. The discussion that follows is inherently technical, and nobody will blame you if instead of reading further you just wish to watch us pour ice water over ourselves. (Remember, that was a thing just last year.)

Welcome back to this article. It get’s progressively more arcane from this point onward.

The notion of infeasible depends on the relationship between the amount of work the defender has to do to secure the system compared to the amount of work that the attacker has to do to break it. A bank vault may take a minute to unlock if you know the combination, but it may take days to break through if you don’t. With cryptographic systems it can take just a fraction of a second to decrypt data if you have a key, but many times the age of the universe to do so if you don’t have the key.

Security parameters

What we want is the amount of work the attacker has to do to be vastly disproportionate to the work that the defender must do. It turns out that this can be stated mathematically, but first we need to introduce the notion of “security parameter” if we want our definition to stand the test of time instead of depending on the speed and power of current computers. So we will talk about how much work the defender and the attacker have to do in proportion to some security parameter.

Let’s pick, for purposes of exposition, an encryption system that operates at a security parameter of 56. The amount of computation that the the defender has to do to decrypt some data with the key is proportional to 56, but the amount of work that the attacker has to do to decrypt the data without the key is proportional to 2⁵⁶. Fifty-six is much much smaller than 2 raised to the 56th power, but today even 2⁵⁶ operations is within the reach of many attackers. Thirty years ago it was within the reach of just a few.

So now let’s suppose that we want to double this security parameter to 112. How much of a work increase might this cause the defender? You might be thinking that it doubles the cost to the defender, but the system I’m thinking of actually tripled the cost to the defender. Tripling the cost for double the security parameter may not seem like a good deal, but doubling the security parameter increased the work of the attacker by another 2⁵⁶, for a total of 2¹¹². This puts it well outside the reach of even the most resourceful attacker for a long time to come.

When we doubled the security parameter in that example, the work to the defender increased linearly while the work to the attacker increased exponentially. We want the work required of the attacker to increase exponentially with the security parameter while for the defender we increase it linearly or polynomially.

Doing time, time, time in an exponential rhyme

If the security parameter is n, we will tolerate it if the amount of work the defender must do is proportional to na for any a > 1. That’s what we mean when we say the work is “polynomial in n“. So if the work goes up with the square or cube of n we might grumble and seek more practical systems, but no matter how big the power that n is raised to gets, this is still a polynomial expression. An algorithm that works this way is called a “polynomial time algorithm”.

For the attacker we want the number of computations needed to be proptional to an expression in which n is in the exponent. So if the work to the attacker is proportional to b for any b > 1, so that the work is exponential in n. (Those of you who know this stuff, know that I’m leaving some things out and am taking some shortcuts.)

It might seem that a “big” polynomial get us bigger numbers than a “small” exponential, but no matter how much a polynomial function starts out ahead of an exponential, the exponential will always catch up. Let’s compare the exponential  y=1.1ˣ with the polynomial y=x⁶ + 2. For values of x below a few hundred, it looks like the polynomial is the runaway winner.Plot of polynomial taking early lead over exponentialBut we inevitably reach a point where the exponential function catches up. For the particularly examples I’ve given, the exponential catches up with the polynomial when x is about 372.73.

Plot with exponential catching up

Finally, if we go just a bit beyond the point where the exponential overtakes the polynomial, we see that the exponential completely flattens the polynomial.

Plot on scale where exponential flattens polynomial

Some computations will take a number of steps that are polynomial in n (“polynomial time algorithms”), and others will be exponential (“exponential time algorithms”). We say that a task is infeasible if there is no polynomial time algorithm to complete it with a non-negligible chance of success. I have not defined what a non-negligible chance of success is, but as the article appears to be growing in length exponentially, I will leave that discussion for our forums.

When we have this sort of asymmetry, where the work done by the attacker grows exponentially with the security parameter, but grows at most polynomially for the defender, there will always be some security factor beyond which the work to be done by the attacker is so enormously larger than what the defender must do as to just not be an option for any attacker.

Quibbling over terminology

Now that we have a workable definition of “infeasible” and a better understanding of what cryptographic hash functions do, we can take a closer look at Slack’s statement. First let me repeat that their overall statement was excellent, and I fully sympathize with the difficulty involved in writing something about security that is correct, clear, and usable. I’ve taken some shortcuts in my exposition on any number of occasions, and I’ve made my share of errors as well. My point here is not to criticize but instead to use this as an opportunity to explain.

Given what we believe about cryptographic hash functions it is infeasible to discover x if you are only given the hash of x but only if x is chosen at random. Furthermore this is true of any (decent) cryptographic hash function and is not limited to the slow functions that are recommended for password hashing. That is, we don’t need bcrypt or PBKDF2 for that property to hold.

The limits of slow hashes

Slow hashes – specifically designed for password hashing – are built because we know that passwords are not chosen at random and so are subject to guessing attacks. But slow hashes have their limits, and with the notions that have been introduced above, we can now talk about them more clearly. Using a slow hash like PBKDF2 slows things down for both the attacker and for the defender. And the amount of slow-down is roughly the same for both the attacker and for the defender.

If we increase the security parameter (number of iterations) for PBKDF2 the computational cost rises linearly for both the attacker and for the defender. This is unlike the security parameters we use elsewhere in cryptography, where we would like a small (linear or perhaps polynomial) increase in cost to the defender to create a large (exponential) increase for the attacker.

Let’s see how that works out with a concrete, if hypothetical, example. Suppose it is using 40,000 PBKDF2 iterations. Now suppose that you add a really randomly chosen digit to the end of your Master Password. Adding a single random digit will make an attacker do 10 times the amount of work that they would have to do to crack the original password. Adding two digits would make the attacker have to do 100 times the work of the original. Making a password just a little bit longer (with random stuff) makes the work required by the attacker increase exponentially. That is the kind of proportion of work that we like.

Now suppose 1Password uses 40,000 PBKDF2 iterations in deriving your Master Password. To get the same additional work as adding a single digit to your password, you would need to increase the number of PBKDF2 iterations to 400,000. And to get the equivalent of adding two digits, you would need to increase the number of iterations to 4,000,000. Once we have a goodly amount of PBKDF2 iterations, there isn’t that much gained by increasing it by an additional ten or twenty thousand. But there is much to be gained by even a small improvement in a Master Password.

PBKDF2 is terrific, and it is an important part of the defense that 1Password offers if an attacker gets a hold of your encrypted data. But you must still pick a good Master Password because the security parameter is linear for both the defender and the attacker. Unless there is a breakthrough in the slow hashing competition, a strong Master Password will always be required in order to ensure your security can withstand the test of time.

Viewing Drupal from the 1Password Watchtower

1Password WatchtowerWhen a large number of websites are discovered to have been vulnerable, as is the case with websites running recent versions of Drupal, people need clear and unambiguous advice that you can act on. And so, our clear and unambiguous advice is:

If you have a username and password on a site which has been using Drupal for its content management, you should change that password. You will need to change that password everywhere you use it, not just on the potentially affected sites.

Our Watchtower service within 1Password for Mac and Windows will recommend password changes for a number of sites that we detect as using Drupal. Here you can see what that will look like.

Drupal Watchtower example

We should also make it clear that none of our systems are affected by the Drupal vulnerability. We don’t use Drupal.

Site administrators know best

We don’t know the status of any particular site other than it appears to be running Drupal. Therefore, if our advice conflicts with advice you received from the administrators of a site, follow their recommendations.

We don’t know when a site gets fixed

Some vulnerable Drupal systems may have been fixed on October 15. Others may still not be fixed yet. Our tests are only capable of determining whether a website is using Drupal (and even that test is imperfect).

Merely patching Drupal is not sufficient for sites that may have been compromised. That is because an attacker using the vulnerability may have left a “backdoor” in a site allowing them back in even after the original vulnerability has been fixed. This makes it yet more difficult to determine whether a site remains vulnerable.

We don’t know if a site has been compromised

Drupal icon 400pxJust because a site has been vulnerable doesn’t mean that it has been compromised. However, it appears that automated attacks have been systematically breaking into vulnerable sites and planting “back doors” that would allow the attacker a way back in at any time in the future. So we should assume that most Drupal sites which weren’t patched very quickly on October 15 have been compromised.

A password compromised anywhere must be changed everywhere

If you reuse the same password on more than one site, you will have some extra work cut out for you. Let me explain why.

Suppose that Molly (one of my dogs) has used the same password on Bark Book as she does on Sprayed By a Mink Anonymous, and let’s also suppose that Bark Book gets compromised by Mr Talk (the neighbor’s cat).  Molly will need to change her password on both the compromised site (BarkBook.com) and on the uncompromised site (SprayedByMinkAnon.org) . That is because Mr Talk can use what he has learned from Bark Book against all of the sites and services that he thinks that Molly may be using. I must also report that Mr Talk, along with everyone down wind, can easily guess that Molly may well be visiting SprayedByMinkAnon.org.

Molly should take this opportunity to work towards having a unique password for each and every service. 1Password will remember those for her. The closer she gets to having a unique password for each site, the less of a headache the next big incident will be.