Meta fined €91m for passwords in plain text

It’s turning into a busy autumn for Privacy professionals! Hot on the heels of the Dutch DPA hitting Uber with a €290m GDPR fine for transfers to the USA without a transfer tool, on 27 September 2024 Ireland’s DPC imposed a €91m GDPR fine on Meta for mistakenly storing passwords in plain text, contrary to its own policies.

We don’t have the full decision as yet, but in the meantime we can draw out 7 key lessons.

Lesson #1:  Check that your organisation doesn’t store passwords in plain text.

The DPC’s summary

As alt text to the image above, the DPC decided that Meta had infringed GDPR in 4 ways:

• Article 33(1): ‘as MPIL failed to notify the DPC of a personal data breach concerning storage of user passwords in plaintext’;
• Article 33(5): ‘as MPIL failed to document personal data breaches concerning the storage of user passwords in plaintext’;
• Article 5(1)(f): ‘as MPIL did not use appropriate technical or organisational measures to ensure appropriate security of users’ passwords against unauthorised processing’; and
• Article 32(1): ‘because MPIL did not implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including the ability to ensure the ongoing confidentiality of user passwords’.

Let’s dig in.

What happened?

On 21 March 2019, Meta published a blog admitting that it had stored passwords for hundreds of millions of users of various services, including Facebook and Instagram, in plain text.

As part of a routine security review in January, we found that some user passwords were being stored in a readable format within our internal data storage systems. This caught our attention because our login systems are designed to mask passwords using techniques that make them unreadable. We have fixed these issues and as a precaution we will be notifying everyone whose passwords we have found were stored in this way.

Put aside any feelings you may have about Meta for a moment:

• this is an organisation with a good password storage policy – don’t store them in plain text,
• they recognised they’d made a mistake,
• they found the mistake because they carried out an internal security review,
• they fixed the mistake, and
• they proactively told not just the users in question, but the whole world.

Granted the scale is off the charts and we’re talking passwords to an online service, but let’s take a moment to recognise some good policy and process right there.

Lesson #2:  Check that your organisation has good policies on security and privacy, trains on them, does internal reviews, and acts on any non-conformity including documenting the whole process.

Salt + Hash

It’s of course correct that passwords for online services should never be stored in plain text. Best practice, as recommended by all of NIST, NCSC and OWASP, is to salt and hash passwords and only store the salted hash. (There’s even pepper too!)

NIST explains why it is so important:

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive.

What’s a hash?

According to the UK’s NCSC:

Hashing means ‘Converting data into a fixed-length unreadable format that can’t easily be reversed. Commonly used to protect passwords’.

Hashing a password is a one-way conversion of the password, using an algorithm, into a seemingly random series of characters – the hash itself.

It’s not foolproof. Put a word (like ‘password’) through the same hashing algorithm multiple times and you’ll always get the same output. So a hacker, who managed to obtain the database of hash results and who knows the hash function, can enter passwords into the algorithm and compare results in a brute force attack.

Indeed, hackers might use a ‘rainbow table‘, which are tables with huge numbers of outputs from various hashing functions. If you’d just hashed, and they knew which algo you used, then your database is an open book.

Brute force attacks aren’t clever, they can take time, but they work. Which is where the salt comes in.

What’s a salt?

As OWASP explains:

A salt is a unique, randomly generated string that is added to each password as part of the hashing process. As the salt is unique for every user, an attacker has to crack hashes one at a time using the respective salt rather than calculating a hash once and comparing it against every stored hash. This makes cracking large numbers of hashes significantly harder, as the time required grows in direct proportion to the number of hashes.

Even if the hacker had an all-singing, all-dancing rainbow table, if you’ve also salted before hashing, that rainbow table is made pointless because the salt is different for each user and, as NIST et al note, it’s all about making it not worth the hacker’s time and money.

Lesson #3:  At the least, salt and hash your passwords.

Meta’s GDPR fail

Without a doubt, Meta should not have stored passwords in plain text. Accidental or not, that was clearly a failure to comply with its security obligations in Art 5 (GDPR’s Principles) and Art 32 (Security of processing).

And, as above, the DPC also states that storing the passwords in plain text was a personal data breach. This is where the full decision will be very helpful to fully understand the DPC’s reasoning.

Personal data breach

GDPR defines ‘personal data breach’ as:

[1] a breach of security [2] leading to the [3] accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, [4] personal data transmitted, stored or otherwise processed

Let’s look at each of those 4 limbs:

1. A ‘breach of security’
   It seems the DPC either decided that failure to comply with Arts 5 and 32 is, in itself, a breach of security as that term is used in the definition of personal data breach, or the breach was that internal users who were not meant to see plain text passwords could do.
2. ‘leading to’
   This indicates there must be causation between the breach of security and the accidental, unlawful or unauthorised actions in the next limb.
3. ‘accidental or unlawful destruction, loss, alteration, unauthorised  disclosure of, or access to’
   The DPC’s wording is careful in stating they agree no external party saw the passwords. The DPC presumably saw the unauthorised access as the ability for internal users to see plain text passwords when they should not have.
4. ‘personal data‘
   It’s not a personal data breach if there’s no personal data. But passwords are certainly personal data.

Lesson 4:  Have good monitoring and logging on your tech stack so you can confidently and quickly ascertain whether unauthorised access has happened and, if so, when and the extent of such access. It’s gold dust when a breach happens.

Was notification necessary?

The DPC’s announcement states that Meta did not notify the DPC of the personal data breach. The DPC does not refer to any failure to communicate the breach to individuals, presumably because Meta took the steps it mentioned in its blog and did reach out to affected individuals.

However, was this a notifiable breach in the first place?

Meta’s blog contains very clear statements that the passwords were not exposed externally or improperly accessed or abused:

• ‘To be clear, these passwords were never visible to anyone outside of Facebook and we have found no evidence to date that anyone internally abused or improperly accessed them.’
• ‘Our investigation has determined that these stored passwords were not internally abused or improperly accessed.‘
• ‘While no passwords were exposed externally and we didn’t find any evidence of abuse to date, here are some steps you can take to keep your account secure:‘

And the DPC seems to agree: ‘These passwords were not made available to external parties.’

Again, this is where the full decision will be interesting to read because Art 33(1) states (our emphasis):

In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.

• One can see Meta running the argument that, while there was a security fail, it led to no risk to the individuals in question.
• One can also see the DPC running the argument that, before the security fail had been identified, there was an open vulnerability likely to result in a risk to individuals. (Presumably the DPC felt that other security measures protecting the database, such as role based or least privilege access, use of MFA, monitoring and logging, obligations of confidentiality and data protection in employment contracts, training etc were not sufficient to reduce that to ‘unlikely’.)

Lesson 5:  Make sure you have a robust risk assessment policy and procedure setting out your methodology and practices from how you define risk, the risk factors you will look for in particular, how you will identify risks, contain them, react to them, to how you will communicate about them and learn from them. Keepabl’s Breach Management solution and Privacy Policy Pack have you covered.

Lesson 6:  Make sure you don’t have a single point of failure with just one security tool or layer of security. Multiple steps protecting personal data might include a firewall only allowing trusted services to access the relevant system, not having systems publicly available, using least privilege access so that only those who need access can access (maybe no-one needs access to some data?), enforcing MFA on that access, monitoring that access and storing relevant logs for the appropriate period, alerting when suspect activity takes place, and of course salting and hashing passwords.

Failure to document a breach

The DPC also states Meta failed to document the breach as required under Art 33(5), which states:

The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article.

While Meta’s blog in no way documents the breach to the level required in GDPR, it also suggests that Meta did have extensive documentation on which passwords were in plain text, which users were affected, the fix put in place, communications made, and other remedial steps. The documentation must not have been sufficient in some way.

Again, we’ll need to see the full decision on this aspect.

Lesson 7:  Make sure you document your breaches, at least including all information required by GDPR (for example in a Breach Management solution such as Keepabl).

A UK precedent

Just as a comparison, back in 2019 the online bank Monzo announced that encrypted PINs, for a reported half a million customers, had been visible in plain text to some of Monzo’s engineers. Monzo had fixed that oversight, audited the database and confirmed that no fraud had resulted and no unauthorised access had taken place, communicated that to affected customers and recommended they change their PIN in any event. The UK ICO told the FT it was aware of the news. No fine or enforcement action resulted.

The full decision

As the DPC notes, they: ‘… submitted a draft decision to the other Concerned Supervisory Authorities across the EU/EEA in June 2024, as required under Article 60 of the GDPR. No objections to the draft decision were raised by the other authorities.‘

We’re looking forward to seeing the full decision to understand more about the personal data breach aspect.