23 And Me Has a Huge Data Incident

In October, genetic research company 23 and me suffered a data breach. This breach, according to an article on Tech Crunch, affected about half of 23 and me’s customer base. The company also stated that the hackers were able to access, “A significant number of files containing profile information about other user’s ancestry.” Larger than initially understood, this data breach is believed to have affected 6.9 million individuals in total. There may be an additional 1.4 million users affected but at the time of drafting this article, this portion of 23 and me’s customer base is still being investigated.

Who is 23 and me?

23 and me is a San Francisco, California, based company working in the fields of personal Genomics and Biotechnology. It is fair to state that you are most likely familiar with this company thanks to their television ads. By providing a sample of saliva to 23 and me, an individual can uncover a whole plethora of information regarding their ancestry. This information can help people make decisions, for example, about their health since they can better determine hereditary issues.

How did 23 and me a fall prey to such an incident?

According to 23 and me’s initial reporting of the event and disclosure provided in October the brute force attack launched by hackers was caused by customers who frequently used the same password. By matching their 23 and me account password against passwords obtained via other data breaches which occurred in the past, the hackers were able to gain the access they needed to make off with the sensitive information. This type of attack is referred to as ‘credential stuffing’.

Why is 23 and me still determining size and scope of this breach?

It is a matter of functionality and features from 23 and me that may have made this worse. 23 and me has a feature called ‘DNA Relatives’. This feature is able to provide a 23 and me customer with a family tree of their ancestors. DNA Relatives also allows the customer to automatically share information with others. This meant that personal data such as name, birth year, relationship labels, DNA shared with relatives, ancestry reports and self-reported location were among the pieces of personal information obtained without terrible difficulty once the hackers managed their way into a customer(s) profile. If the customer had even opted-in to receive updates about this feature, there is a good chance that their information was part of the incident.

What can we learn from this?

This attack was user-level based. Hackers gained access to profiles, not employee accounts. This is not as simple of a case as sending an email reminder to your staff about smart password practices. This is a mistake by 23 and me from a technical perspective.

While this does not align precisely with HIPAA or a violation in that sense, some intelligent best practices put forth by 23 and me’s technical engineers could have dissuaded attackers from this act. Two things come to mind. One important thing 23 and me should consider going forward is forcing users to choose a password with minimum requirements like length, special characters or including a number to make a brute force password attack more difficult for hackers. The second thing which comes to mind to mitigate instances like this going forward would be to force users to reset their password after a given period of time. This ensures that if a password is compromised, it will only be relevant for so long. While these 2 ideas do not make 23 and me bulletproof, it sure would have made things harder for the hackers who may not have been talented enough to penetrate these profiles if better defenses were put up.

The BEST way a user could have prevented this would be to have them enable 2 factor authentication. By forcing users into a 2FA scenario, the entire incident could have been avoided. However, 2FA can be found cumbersome by many consumers, which probably led to a decision to not use it by 23 and me. Now that the worst has been realized for the company, will they be enacting something like 2FA regardless? Time will tell!