Are publicly available password dumps legal under GDPR When a company gets breached by hackers, often the contents of their databases will make its way onto the internet. Sometimes this will include obviously personal information such as email contents or personal data but it's quite common to see a text file with emails and passwords of the format: a.aaronson@aol.com:abcdef ... johnsmith@hotmail.com:password123 johnsmith@gmail.com:hello456 This is useful information for security professionals to test if an account uses a password that's been published in a data leak somewhere. On the other hand, the data is stolen and the individuals have not consented to their data being used for this purpose. There exist services such as Have I been pwned that allow a user to search these databases and find out if their data is included in a public data dump. Troy Hunt (who runs it) is based in Australia but if the site is available to users in Europe, it would still be covered by GDPR legislation. HIBP uses hashed passwords to maintain privacy. Under GDPR, is it legal for me as an individual to hold a copy of a leaked database and is it legal for a security company to hold it (or information derived from it). I'm based in the UK (Scotland specifically) if other laws are relevant.
I think haveibeenpwned would be legal in the EU because it carries out a task in the public interest (Art. 6(1)(e)), and it shares no more data then necessary, for example you can search for a password, but it would not show you the emailaddress which belongs to that password. It would also be legal for you to hold a copy of a leaked database, but only if you have a legitimate interest (Art. 6(1)(f)) to have it. Being a security company does not change that, but finding a legitimate interest might be easier. If you have a legitimate interest to hold a copy of a leaked database, it does not mean you can use it in any way you like. For example testing if the password still works, is very likely illegal everywhere in the EU. But I'm not familiar with the UK laws.
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
Congrats, you've done well to minimize your processing of personal data. But I think you're still processing personal data, and are subject to the GDPR. Serving a website necessarily involves processing an IP address. This IP address will typically be personal data. While you are not storing the IP address, the GDPR's definition of “processing” extends beyond storage and pretty much covers doing anything with that IP address. As far as I know this is not an entirely settled matter, but it's better to err on the side of caution and to assume that you are in fact performing a processing activity. Even a static web page can easily lead to additional relevant processing of personal data, for example if the HTML embeds resources from third party domains. Since your website is clearly targeted at the public, it does not fall under the GDPR's exception for “purely personal or household” purposes. So I think you do need a (minimal) privacy notice that contains at least the items mentioned in Art 13 GDPR. The main reason why some people try to avoid posting a privacy notice is because it must disclose your identity and contact details. But in Germany, that information has to be provided anyway due to the Impressumspflicht. As part of your GDPR compliance obligations, you must protect how data is processed by others on your behalf. A hosting provider will typically act as your data processor. For this to be legal, you need a contract / data processing agreement that fulfills the conditions in Art 28 GDPR. This contract binds the data processor to only use the data as instructed by you, and not for their own purposes. European hosting providers sometimes include the necessary terms in their terms of service / AGB, but you should check to make sure. Netcup expects you to accept their data processing amendment in your account settings. In the hypothetical case that you were not processing any personal data at all, the GDPR would not apply and it wouldn't require you to post a privacy notice. Other laws might still have information obligations, notably the German TMG and TTDSG.
The GDPR gives controllers a lot of latitude. They must decide on the correct course of action taking into account the possible risks to data subjects. Specifically, no notification of the authority is necessary if “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” In your scenario 1, you suggest that there is no breach because there is no evidence that the data was improperly accessed. This analysis is faulty: the controller is aware that the data was not properly secured, and cannot rule out that the data was improperly accessed. I would argue this fits the description of a “breach of security leading to the accidental or unlawful … unauthorised disclosure of … personal data” (compare the definition of a data breach in Art 4(12)). Thus, a data breach has happened. The question whether the supervisory authority has to be notified of that breach is more debatable. The controller must assess the likelihood of risks to the data subjects. Here, they can perhaps argue that the risk of disclosure is low. However, the nature of the breached data would also be relevant. If in doubt, the controller should make the notification. The goal of the GDPR is not to punish unlucky companies that suffer a breach, but to protect personal data. Thus, fixing mistakes and cooperating with the supervisory authorities is likely the best approach for most companies. In your second scenario, the data is sensitive – its disclosure has a high risk for data subjects. However, the risk of someone intercepting this data is debatable. Does the risk of interception balance out the sensitivity of the data? That's the data controller's call, but I don't think so. A notification would seem appropriate here. As a technical remark, simply offering HTTPS is not sufficient to prevent MitM attacks – users must be forced to use encrypted connections. If a controller sees MitM as a risk, they are required by Art 24 to take appropriate technical measures. Here HSTS and HSTS preload would prevent the connections from being downgraded to HTTP. Instead of offering insecure connections, the site would become inaccessible. A complementary strategy is to not serve content over HTTP, but have the HTTP server only issue a permanent redirect to the HTTPS URL.
How can I truly say that I 'consent' to data collection and processing when I am coerced, so to speak, by the threat of failing my courses if I do not use this novel software? There is no need for you to "consent". Consent is just one of the reasons that allows a data processor to collect your data. There are other reasons that allows the data processor to capture your data. In this case, it seems of application the "legitimate interest clause", as it is in your university's legitimate interest to capture your activity in order to evaluate you. Of course, that covers only the data collected that is relevant to that interest. They will certainly capture your identity and your answers, they may log your sessions and may try to gather some data to detect if you are somehow cheating, but they would not be allowed to check which are your favorite pornhub videos because that is not relevant for the university's legitimate interest. Art. 6 of the GDPR states: Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. This page also provides some in-depth analysis
It's hard to prove a negative, and I'm not sure which specific part of the quoted Terms you object, to, but it specifically states that content access may be done to: Comply with the law Protect its customers; and Protect the security of its business; and Protect its business interests. It's unlikely that access of information to comply with the law is illegal. At least one EU directive, Directive 95/46/EC, sets limits on the collection and use of personal information. We're concerned with the first condition for lawful data processing, and the second principle of data quality. Data processing is only lawful if the data subject has unambiguously given his consent; or processing is necessary for the performance of a contract to which the data subject is party; or processing is necessary for compliance with a legal obligation to which the controller is subject; or processing is necessary to protect the vital interests of the data subject; or processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party; or processing is necessary for the purposes of the legitimate interest pursued by the controller or by the third party, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject which require protection. The principles of data quality, which must be implemented for all lawful data processing activities, are the following: personal data must be processed fairly and lawfully, and collected for specified, explicit and legitimate purposes. They must also be adequate, relevant and not excessive, accurate and, where necessary, kept up to date, must not be stored for longer than necessary and solely for the purposes for which they were collected; special categories of processing: it is forbidden to process personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life. This provision comes with certain qualifications concerning, for example, cases where processing is necessary to protect the vital interests of the data subject or for the purposes of preventive medicine and medical diagnosis. So, let's say that someone has given their consent. It'd be at least a little questionable whether the inspection of private information could mean that they access personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life. I'm a bit less clear on US laws, but you'd probably look for laws around Personal Identifying Information, as that's where a lot of focus has been.
First of all, in a GDPR contest, the process described is not strong anonymization. It may be hard for an outsider to go from the stored record to any PII, it is much easier for an outsider to &quot;single out&quot; an individual. This means that given a known individual, one can determine whether that person is among those listed in the records, or can determine this to a significant degree of probability. For this only the algorithm and the rotating salts are needed, one need not break the hash. Note also that the GDPR specifies that if a person can be singled out with the assistance of the site operator the data is not considered anonymized. Thus this data needs a lawful basis under the GDPR, and the various other GDPR requirement all apply. However, even if the data were totally anonymized, and say just added to a count of users with this or that User Agent, the process of reading local data (including but not limited to cookies) itself requires informed consent, and so a cookie banner or other interaction with similar info under the e-Privacy directive (EPD). The EPD, being a directive and not a regulation, must be implemented by national laws, and the exact provisions in those laws may differ somewhat from country to country. But I believe that all of them require consent before any local data is read.
Earlier this year, the Internet lawyer Arnoud Engelfriet wrote a blog post about exactly this topic. As it is written in Dutch, I will summarize it here: As you also said, deleting posts breaks the flow of the archived conversation and it makes your archive incomplete. This is a problem for the freedom of expression and information. But Art. 17(3) GDPR includes an exception to the right of erasure for this situation. So posts do not need to be deleted. However, profiles are not included in this exception. So they must be removed, but they can be pseudonymized. For example replace the username with user89432, and remove all details from the profile. If other posts contain the nick of the author of an anonymized post, that is considered an journalistic, academic artistic or literary expression, so Art. 85 GDPR would apply, so the right of erasure does not apply to that. Bottom line: you only have to pseudonymize the account, if that person wants to be removed from the forum.