A salt hashed with user password is anonymous data for GDPR?

Question

I want to use a scheme to track the user in a anonymous way. My idea is to use the user password to hash a salt to create a identify hash and track the user through this. Theoretically, the only way that I can return from hash identify to user is if I know his password, but it is a thing that only he know, by premise. So, it's considered anonymous or pseudonymised for GDPR? \

Answer 1

The GDPR has a fairly broad concept of what it means for a data subject to be identifiable. The details are given in Recital 26:

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.

The good news is that this mandates a risk-based approach to identifiability. You don't have to prevent re-identification with absolute certainty, but you must make sure that re-identification is not “reasonably likely”.

The bad news is that “identify” does not just mean “figuring out the real-world identity of the data subject”, but also “being able to single out the data subject”.

Hashes of personal data are still personal data.

The hashed password still allows you to single out data subject, since the hash now serves as an identifier that links multiple records. Equivalently, a random ID would serve as an identifier. Depending on the information in the linked records, this could reasonably likely also allow linking to a real-world identity. I'll also point out that the GDPR explicitly notes that “online identifiers … such as internet protocol addresses, cookie identifiers or other identifiers” enable profiling and identification, and are thus a kind of personal data.

Note that it seems you have a user database that includes a password hash. This database includes rich links between the password hash and other, more directly identifying, data. Alternatively, consider that the software that collects tracking information along with this tracking identifier would also receive other information about the data subject that could allow re-identification, such as the data subject's current IP address. It would be reasonably likely that such additional information could be used to identify or single out the data subject. For this analysis, it is irrelevant whether you have any intention of singling out users – it only matters whether, under an objective analysis, the relevant means to do so exist.

Related: EDPB thinks hashed phone numbers are personal data.

There has been recent debate by regulatory bodies on the question whether hashed phone numbers are personal data. This debate was published by the EDPB binding decision regarding the Irish DPC's fine against WhatsApp, which uses hashed telephone numbers to intersect user's address books. The question in the context of the fine was whether this represents processing of personal data of users who are not WhatsApp users themselves. Originally, the Irish DPC argued that such hashes were not personal data.

However, the German, French, Portuguese, and Dutch supervisory authorities pointed out that the specific hashing approach used by WhatsApp does not provide anonymization, for example because there still is contextual information (such as the user's social graph) that would allow indirect identification (and because their hashing was pretty weak and reversible with reasonable effort). Such hashing would only be pseudonymization, not anonymization. The Hungarian supervisory authority makes the argument that WhatsApp could always re-create the hash from the original data, thus permitting re-identification of the hash. This is in line with my above argument that the hash allows singling out. Again, the hash should be considered pseudonymous, not anonymous. The EDPB upheld all these objections against the Irish interpretation as “relevant and reasoned”, and largely agreed with their merits.

Some parts of the resulting analysis are specific to issues around phone numbers, in particular that there are comparatively few phone numbers. However, a recurring point is that the hashed data cannot be viewed in isolation. It must be viewed in the context of how it is created and used, and in the context of other data that the data controller has.

Conclusion

It is possible that in some cases the hash could serve as an anonymous token. But this would require careful analysis about how the hash is created and used, and about what other data you have available and could potentially link or correlate with this token. Unless you are extremely sure that there are no means that could be reasonably likely used to perform re-identification or singling out, you should consider such tokens to be pseudonymous data. Pseudonymization is a great security measure, but such data is still personal data. I suggest reading the WP29 opinion 05/2014 on Anonymization Techniques (WP216) (PDF link). It predates the GDPR and is slightly outdated in both legal and technical matters, but still contains highly relevant guidance on the matter of proper anonymization in the European data protection context.

Aside from identifiability issues, I am concerned about using the password (or derived hashes) for anything other than authentication. Even in hashed form, this is fairly sensitive data. In most cases where you would use a password hash, you can likely use a random number instead.

Answer 2

A piece of data that cannot be used to identify a natural person, and is not linked to a specific natural person is not PI under the GDPR or most other data protection laws (such as the CCPA). Therefore, such a datum does not need a lawful basis for processing, need not be included in notices of data collection provided to the user, is not subject to erasure requests, and generally is not subject to the protections that PI must get.

However, if the otherwise non-identifiable information is linked to a user's name or other PII, such as by being stored in the same DB record or a linked record, then it becomes PI. In short if there is a reasonable way to go from ma datum to PII, it is PI.

By the way one does not "use the user password to hash a salt". One normally appends (or otherwise combines) a salt to a password, and hashs the combined string, producing a hash value. Also, it is not really good security practice to use the hash oif a salted PW for anything but login or related security verification. If it i used to identify the user in other contexts, it increases the possibility of a security hole somewhere. The GDPR requires "appropriate" security measures be taken with PI, and introducing a hole by poor practice could violate that requirement.

Response to Comment
In response to a comment by user lam3:

The GDPR, and the Data Protection authorities set up to enforce it, distinguish between pseudonymous and anonymous . If data can be used to single out a particular individual, even if it cannot be used too link to that person's real name or other identity, it is only pseudonymous and is still PI, even if not PII, and so is still protected by the GDPR.

If a piece of data, even a random number, is used to link other data about a person, it may well thereby become an identifier and thus PI. If it is reasonably possible to follow links from a piece of data to a record o0f information about a specific person, tht data is PI, and possibly PII. If re-identification can be done indirectly, through links or other information that might be available to the Data Controller or to others, then the datws remains PI and thus protected.

Also, please read the answer by Amon, particularly the concerns about using a password in the way the question and comment seem to suggest.