It was recently announced that MyFitnessPal suffered a breach of around 150 million records (https://www.cnet.com/news/millions-of-myfitnesspal-accounts-hacked-under-armour-says/). The breach affected usernames, email addresses and hashed passwords. There are no reports that any other personal information, such as SSN or credit card info has been impacted. It is always important for us to understand the actual types of data exposed as it changes how we look at the risk created to the users. It is important to point out that while the site may allow purchases using credit cards, the way they are processing them doesn’t actually store them.
I don’t know what process is followed in this particular instance, but many applications now use 3rd party payment processors so there is no need for the site to store credit card numbers. Instead, the payment process is offloaded to the 3rd party, which in turn helps provide better protection for the information.
If we look at what type of information was released by the organization, we can make some assumptions about things we can do to help strengthen our own applications from this type of breach. The purpose is not to berate the group that got breached, but instead to learn from their experience. We already took a quick look at processing credit cards and how taking proper steps to not store them locally helps add a layer of protection. The next most important part of the information actually breached were the passwords. Well, hashed passwords. It was interesting that the statement in the article and the email sent by MyFitnessPal to its users stated that a majority of the passwords were hashed using bCrypt. This indicates that not all of the passwords were hashed this way. Of course, we don’t know how they were hashed, or even if they were hashed, so let’s focus on the fact that the ones that were hashed were hashed with bCrypt. When we talk about storing passwords, the two most commonly recommended algorithms are bCrypt and PBKDF2.
These algorithms combine both a unique salt per hash and a work factor. Hashing algorithms are perfect for storing passwords, because we rarely ever need to reverse the password back to its original value. Instead, we can hash the user supplied password at login and then compare it to the stored original hash. Unfortunately, hashing algorithms are fast, which makes them easier to brute force because a program can generate a large number of hashes very quickly. This is why the work factor is important. It slows down the hash process to reduce the number of hashes that can be created in a specified timeframe.
When we see a breach where it is announced that the passwords were stored using bCrypt or PBKDF2, there is a better chance that the passwords won’t actually be compromised. There are some exceptions and things to think about with this.
- First, don’t make the mistake of announcing you used a certain algorithm when you didn’t. There are plenty of people that will get their hands on that data and if it is determined that the information provided was inaccurate, the fallout could be much worse than having just been honest up front.
- Second, just because the passwords are properly hashed, poorly chosen passwords are still not very protected.
Passwords are a simple, yet complex beast. Determining what a good password is can be difficult and we see all sorts of rules about them on every site. We are taught that longer passwords are better passwords. And this is usually true. But we also have to realize that using common passwords, even if long, is a bad practice. Users that choose passwords like ‘Winter 2018’ are much more susceptible to having their password cracked, even if it was hashed with these recommended algorithms. I don’t recommend blocking users from using any random password that has been breached in the past, not associated with their account. However, you could block passwords that are on the “top 1000” type lists of commonly used passwords. For those users using password managers, this shouldn’t be a problem since they can be creating long randomly generated passwords.
The other part of the breach process I want to touch on is around the response to a breach. When we think about our SDLC, we should have a part where we start thinking about response plans. This is where we think about what types of events may occur, and more importantly, who will need to be involved if those events occur. Having the right response can have a huge impact on how the organization is perceived following a breach.
The type of information provided to the customers or end users and how it is provided is critical. We have seen with other breaches where if it appears the breach was covered up, or the information is inaccurate, people will have a very negative view of the organization. Make sure your organization has taken steps to identify the right people to have involved when getting ready to send out alerts. For example, you may want to have legal, marketing, HR, or other resources available. Each has their own specialty that can help make a smooth announcement.
As developers, as we identify potential breach scenarios, we can start to consider processes to handle them. For example, if your credentials database gets breached, what steps might you take to help protect the users. FIrst and foremost, containing the breach and making sure it is over. Then, how would you force a password reset to make sure that any passwords breached are no longer useful.
Use this recent breach as an excuse to review some of your internal processes.
How are you storing passwords?
How would you handle a password breach?
Reviewing these situations every once in a while is a healthy way to ensure that your applications are up-to-date in these protections.