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.
As alt text to the image above, the DPC decided that Meta had infringed GDPR in 4 ways:
Let’s dig in.
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:
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.
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.
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.
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.
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.
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:
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.
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:
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.
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.
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).
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.
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.
We’re thrilled to announce that we’ve introduced intake and management of Freedom of Information requests into our global Rights module. As always, we’ve been collaborating with our ‘Roadmappers’ – customers,…
We’re delighted to announce that Microsoft’s Azure AD joins Keepabl’s stable of supported Identity Providers for provisioning and managing your users in Keepabl through Single Sign-On with your favourite IdP!…