gdpr
In GDPR terms is the hash of a user ID considered personal data?
<blockquote>
<p>“‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”.</p>
</blockquote>
<p>Taken from <a href="https://gdpr.eu/eu-gdpr-personal-data" rel="nofollow noreferrer">https://gdpr.eu/eu-gdpr-personal-data</a></p>
<p>If I cryptographically hash (e.g. sha-512) my user's ID and give it out to a third party, do I have to delete that data when the user deletes their account? Is it considered personally identifiable data and therefore under GDPR? Or is it considered anonymized sufficiently?</p>
<p>There's no way for the third party to go from the hashed user ID to data on my service but knowing a user's ID I can always check if the data on the third party's platform is about them.</p>
<hr />
<h3>Edit</h3>
<p>Somebody asked</p>
<blockquote>
<p>It occurs to me that the OP is not just sending the id to the
third-party; what would be the point? That other data might be able to
identify the individual even without the id</p>
</blockquote>
<p>In my case, the other data definitely can't identify the user it's data related to crashes on their device.</p>

<p>You quoted the definition of personal data from Art 4(1) GDPR. This definition of identifiability is further explained in Recital 26:</p>
<blockquote>
<p>[…] To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. […]</p>
</blockquote>
<p>If the user ID is unique, then the hashed user ID will be unique as well. Thus, the hashed ID will enable “singling out”, and would still count as identifying in the sense of the GDPR.</p>
<p>You also claim that there's no way to reverse the hash. This is not quite correct. Assuming that the hash function itself is secure, then the only way to crack the hash is to brute-force the input. The difficulty of brute-forcing depends only on the entropy of the input data, not on the size of the output hash. It is thus comparatively easy to crack hashes of short low-entropy strings like sequential integer user IDs, IPv4 addresses, or weak passwords. In contrast, it would be difficult to crack long random user IDs, such as UUID version 4 identifiers created from a cryptographically secure RNG (CSPRNG).</p>
<p>Even if the hashes can't be cracked, they are not anonymous – you can link them to the original user ID, after all. The GDPR only considers data anonymized if there are no “reasonably likely” means to re-identify the data subject. If this de-identification is reversible, it's called <em>pseudonymization</em> instead.</p>
<p>If storage allows, a better technique to generate pseudonymous IDs is to create a table that maps the true ID to a CSPRNG-random ID. Unlike a hash, the random ID cannot leak extra information about the original ID. This pseudonymization technique could perhaps also be turned into irreversible anonymization by deleting the ID mapping, assuming that no “singling out” can happen.</p>
<p>Pseudonymization is a very good security measure. It is explicitly mandated whenever appropriate in Art 32 GDPR. So you should probably use it. It's just that GDPR continues to fully apply to processing of the pseudonymized data.</p>
<p>Since the pseudonymized data is the data subject's personal data, you <em>may</em> be required to delete it when receiving an Art 17 request for erasure. You may also be required to forward the request to others with whom you shared the data. However, the right to erasure has many conditions and exceptions. If you actually need to keep the data for a particular purpose, chances are good that you can keep it.</p>
