Question: 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?

Answer: 
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.