What Does A Data Breach Like This Mean?

There are a lot of things that go through people's minds about what happens with a data breach. Let's take a minute to talk about what actually happens, and how to mitigate damage on our end, as users.

Anatomy Of A Data Set

Every site we sign up for stores our data in a database. These days, a great many of them store not just our login data, but also data about where we go and what we do (this is called "analytics data" and is how your ads guess that you're interested in, say, sports bras, after spending time at UA's website). Some also store a certain amount of credit card information.

MyFitnessPal does not, themselves, store credit card data. They use a third party payment processing system called Stripe. Since they use a subscription model, they may store confirmation information from Stripe in order to connect your account back to the subscription information, so that they can correctly charge you. This confirmation information is pretty useless without other contextual items (such as the API key that MFP as a system uses to talk to Stripe), which work together in a similar way to your credit card number, plus CVV code, plus expiration date, to create a single identifier. This is why they say that your payment information is not affected by this breach.

The rest of your data that MFP uses, however, is stored in their own database (very likely a type called a relational database). These databases, for the most part, can be thought of like very complex Excel spreadsheets in that every bit of data is associated with a row and a named column. In that database, your user account is associated with a (usually) numeric ID, which denotes the row that contains the rest of your data (this ID is associated with rows in multiple tables in order to aggregate all of the data associated with you, personally).

Most of this information is stored in plain text. This post, for example, will show up in the table data more or less unchanged. If I had access to the database, I could search it for one of our usernames and be able to find it without issue.

How Passwords Are Stored (And Retrieved)

Passwords, however, are different. Since these are the keys to our individual accounts, they are (supposed to be) encrypted. There are some systems that store this information in plain text or in a reversible hash. The biggest sign of such systems include them telling you your password when you go through the forgot password flow (or upon signup).

MFP encrypts their passwords using an algorithm called bcrypt. This is a very secure, irreversible password hashing algorithm. This method adds what is called a "salt" to your password string before then going through its hashing function. This adds a layer of security, because these "salts" should be different across different systems, even if the passwords, themselves, are the same, and even when the systems all use bcrypt.

So, let's say you use the password "password123" (please don't ever use such a password), and through the underlying algorithm of bcrypt, that password alone becomes the hash "10$KsMuLxWNR6k6oB7yiX0GAe2Q7wTHlrzhF3LqtVvpyvHZf0MwvNfVu".

However, when you run through bcrypt as a whole, that same string becomes "$2a$04$JozQEYXl2SN2JpobVoMBCuXNc3xe/0p6E5bQOekdrkxvkaPaNZ1IW".

Even more, running it through again results in
"$2a$08$kOpPaIRibRKzYNmUXNoesOL9/KsKfunA.5B4k2N7ZRKEe6zCnS3hi".

What this means is that even if everyone used the same password, it would not appear so, because the salt adds a unique value into the equation. This prevents what's known as "rainbow tables" (tables of common or otherwise known passwords and a means to achieve their hashed values in various algorithms).

Now, even knowing the algorithm, you cannot "undo" the hashing to find the password (ie - you can't take one of the above bcrypt-generated hashes by themselves and find out that it becomes "password123"). In order to validate the password, you have to have the password, which can then be compared with the hash. Very (very) basically, the system has to go "I have this string value and this hash. Does this string value become this hash when I run it through my algorithm?" In other words, the system has to have the plain text string and the hash and the right algorithm and settings in order for it to work.

This means that odds are good that even if you did use the same password on multiple sites, an attacker is not likely to be able to obtain that information or match it up properly with just the hashes (as long as both the source of the data and the potential new system use secure forms of encryption, such as bcrypt).

However, it's still a good idea to have different passwords across systems, because

• if someone does get a hold of your plain-text password (such as through a phishing site), they'll have control over all of your stuff
• you never know what (if any) algorithm a site is using for their passwords, so if they're not using any or using an insecure one and suffer a breach, your plain-text password would be discoverable

What A Data Breach Like This Means

Especially with wider-spread use of better encryption algorithms and 2-factor authentication, the passwords actually aren't the most valuable piece of data obtained from a breach like this. Also, contrary to popular belief, the attackers aren't likely to care in the slightest about getting into your email account, unless you're a famous or powerful person (or you really pissed someone off and they're specifically targeting you). The value in the passwords are as a means to an end, at best.

So what is valuable?

• Any and all personally-identifiable information, including names, addresses, email addresses, phone numbers, etc. This data can be sold off to scammers who then do things like send you scare-mail or make fraudulent calls claiming that you owe the IRS thousands of dollars. It can also be sold off to unscrupulous marketers who then flood you with crap mail and phone calls. On the more sinister side, this information can be used to fake your identity.
• The data as a whole. As mentioned, personally-identifiable information is particularly valuable. Cross-reference that data from other sources, and someone has the ability to recreate far more information about a lot of people. This kind of thing is what makes the Equifax breach so terrifying.
• Financial data. This is particularly valuable (and is why anyone storing such data is supposed to be held to PCI or similar privacy standards), because its use can directly result in financial harm.
• Healthcare and education data.

One of the common uses of all of these are one goal -- identity theft. Credit card information can be used directly, while personally identifiable information can be used to fraudulently obtain credit cards, open bank accounts, make purchases, and other activities.

What's This Mean For MFP Users?

Honestly? Not as much as it could have. MFP doesn't store much in the way of personally-identifiable information, and according to UA, the only thing they got were usernames, emails, and the hashed passwords. As far as breaches go, this was large, but relatively minor. UnderArmour is going to suffer the most for this (and has already, with a 5% drop in share price). It does mean that this data is now where it shouldn't be, but frankly, it probably already was.

For the most part, the passwords were encrypted using bcrypt. As discussed earlier, this makes them less valuable. However, some of the passwords were still using the old (and broken) SHA-1 encryption algorithm. If you haven't changed your password recently, do so now and if you use that password elsewhere, assume that it's compromised and change the password for anything that uses that password. If you have changed it recently, change it again anyway.

Tips for everyone:

• If you don't already, it's a good idea to use a password manager, such as LastPass or 1Password. These generate strong, unique passwords for all of your accounts, without you having to remember them all of the time.
• Change your passwords periodically. The actual data breaches happen several weeks (or sometimes months) before they're actually discovered, let alone announced.
• Don't assume web sites are secure. In information security, there's the adage, "it's not a question of if, it's a matter of when." There is no guaranteed way to protect any data, and most companies don't prioritize security enough for them to be trustworthy (this should have been abundantly clear with the Equifax breach).
• Lock down your sensitive stuff. Call the credit score companies and disallow anything to be opened in your name. Freeze cards you don't use. etc.
• Don't give out any more information than you have to. The vast majority of places don't need things like your social security number, for example, and the ones that do should be able to give you a good, valid reason.