The GDPR changes a lot of data protection law, but how will it affect dumped databases of passwords?

At the moment these can be used to work out the most common passwords, and sites can use this knowledge to prevent people choosing overly common passwords.

Will this still be allowed under GDPR, as the password databases can be considered personal data, and if not would anonymising the passwords, so that they are stored without account details fix the issue, or would the passwords still be treated as personal information?

closed as off-topic by Steffen Ullrich, Neil Smithline, S.L. Barth, Xiong Chiamiov, M'vy Feb 28 '18 at 11:03

  • This question does not appear to be about Information security within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    I'm voting to close this question as off-topic because it is a purely legal question and thus belongs to Law. – Steffen Ullrich Feb 24 '18 at 17:28
  • What password dumps are you speaking of? Ones from hacked sites? Other? – Neil Smithline Feb 25 '18 at 18:51

GDPR relates specifically to personally identifiable information, that is information that could be reasonably used to identify a person, like address, email address, user names, IP address.

If the password dump contains only a password and no username, account details or IP address, it is likely that they would not be considered PII for the purposes of GDPR.

However, remember that if you have the plain text password and someone has used something personal as their password, maybe firstname_lastname_dob , that could be construed as personally identifiable.

Standard caveat: This is not legal advice, I am not a lawyer but I am based in the EU and working on a team ensuing GDPR compliance for a company processing sensitive data.


While this is indeed mostly a legal question, as to what of it pertains to the practicalities of security:

  • Storing accounts+passwords would be information relating to an identifiable person, so definitely personal under GDPR.

  • You only need to store hashes of passwords to catch collisions. This doesn't change whether data is personal under GDPR, just turns it into pseudonymous data.

  • The most practical way to store passwords that I see for this purpose is a two-row table with the password's hash and the number of times that it's been found. Only passwords where that number is >1 should be included, as that would ensure that they can't uniquely ID anyone.

Specific implementation:

  1. The server randomly picks and periodically changes salt1
  2. The server hashes its dictionary of bad password hashes as badphash1+salt1->badphash2
  3. salt1 sent server->client
  4. The user enters the password in his client (browser)
  5. The client hashes the password, then hashes hash1+salt1=>hash2
  6. hash2 sent client->server
  7. The server requires new password (step 4) up if hash2 is IN badphash2
  8. Else the server creates user-specific salt2, sends it server->client
  9. The client hashes password+salt2=>hash3
  10. hash3 sent client->server
  11. salt2+hash3 stored on the server
  12. On login, hash(password+salt2) is checked against hash3.

This way, the salt isn't the same for all passwords. This follows best storage and best transmission practices.

IOW: There's no security reason to store plaintext passwords, not even to check for duplicates. Even that can be done on hashes without compromising anything.

  • Secure hashing of passwords involves salt. This means you can't compare hashes to find matching passwords. – Neil Smithline Feb 25 '18 at 4:08
  • It does, but sometimes you have to compromise. Just have to hash them twice - once without salt to find matches, then with salt for storage. – Therac Feb 25 '18 at 7:06
  • A hashed but unsalted password is little better than an unencrypted password. You should never store passwords as unsalted hashes. – Neil Smithline Feb 25 '18 at 14:45
  • You don't need to. Compare hashes in RAM, clear them, report if the password is OK, if it is, then store the salted hash. – Therac Feb 25 '18 at 15:05
  • (past edit time) Furthermore, salt can be applied to hashes just as it can to passwords. You can salt and hash that initial raw password's hash, then compare it to salted-and-hashed hashes in your database. The table can be precomputed, as long as it's specific to your site, and recomputed with a new salt every once in a while. – Therac Feb 25 '18 at 15:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.