The hashed-emails myth: why hashing an identifier doesn't anonymize it

Evidence grade: STRONG — this is settled computer science and settled regulatory interpretation. Deterministic hashing of identifiers is pseudonymisation, not anonymisation; both the technical literature and regulators (the EU's Article 29 Working Party, the FTC) treat hashed identifiers as personal data. Vendors who claim otherwise are wrong in a well-documented way.

Somewhere in many edtech privacy conversations, a vendor says the reassuring sentence: "We don't store emails — only a hash of the email." It sounds like cryptographic non-collection: the email transformed into meaningless noise. Five minutes of understanding what a hash is dissolves the reassurance, and this page is those five minutes — written because we refused this exact design and think the reasoning belongs in public.

What a hash actually is

A cryptographic hash function turns any input into a fixed-length fingerprint, with two key properties: the same input always yields the same output (deterministic), and reversing it mathematically is infeasible. The reassurance leans entirely on the second property. The problem lives in the first.

Three attacks the reassurance ignores

1. The guess-and-check (dictionary) problem. You can't reverse a hash — but you don't need to. Email addresses are not random 128-bit secrets; they're guessable, and specific ones are known. Anyone holding the hashes who wants to know "is jane.smith@school.example in this database?" simply hashes that address and looks for a match. Computing billions of hashes is cheap; the "irreversible" fingerprint of a guessable input is a membership test, not a shield. For a school context the guess space is brutally small: a district's known address format plus a staff list reconstructs the "anonymous" table over a coffee break.

2. The linkage problem. Determinism means the same email produces the same hash everywhere it's hashed with the same function. Hashed identifiers are therefore join keys: two datasets that both "only store hashes" can be matched record-to-record. This isn't an abstract worry — hashed emails are a standard matching technology in the advertising industry precisely because they link identities across systems. The industry that most wants to track people chose hashed emails as its identifier; that fact alone should retire the anonymity claim.

3. The it's-still-an-identifier problem. Even unguessed, the hash uniquely designates one person and accumulates records about them — which is just what an identifier does. That's why regulators classify it as personal data: the Article 29 Working Party's opinion on anonymisation techniques (2014) is explicit that hashing is pseudonymisation — reducing linkability, not severing it — and pseudonymised data remains personal data under GDPR (Recital 26). The FTC has said the equivalent in plain terms: hashed identifiers are not anonymous, and treating them as such is a deceptive-practice risk.

(Salting changes the arithmetic only if the salt is secret from the attacker — which, for the vendor themselves or anyone who breaches them, it isn't. Per-record random salts with no lookup purpose would defeat matching — and also defeat the reason vendors keep hashed emails at all, which is precisely to match.)

Why this matters doubly for children

A child's identifier seeds a linkable record that outlives childhood — the linkage problem compounds over a lifetime of datasets. And the school-trust problem is sharper: "we store no personal information (just hashed emails)" claims the moral credit of zero-PII architecture while retaining a membership-testable, joinable identifier for every child. The claim isn't a lie about the database; it's a lie about what the database means.

The test, and the alternative

Evaluator's one-liner: "If I gave you a student's email address, could your systems tell me whether that student is in your data?" For deterministic hashes the honest answer is yes — and that answer is the whole story. The genuine alternative isn't better hashing; it's identifiers with no relationship to the person: randomly generated pseudonyms (an animal name assigned by the system) linked to a real child only on a roster the vendor never possesses. Nothing to guess-and-check (the pseudonym isn't derived from anything about the child), nothing to join across systems, nothing to un-anonymize — because nothing was pseudo-anonymized in the first place.

In practice

Add the one-line test above to your vendor questions — it's Q9 with teeth.
Treat "hashed" in any inventory as "collected" and evaluate accordingly.
When a vendor volunteers hashing as a privacy feature unprompted, upgrade your scrutiny — it usually signals a policy written for reassurance rather than description.

References

Article 29 Data Protection Working Party (2014). Opinion 05/2014 on Anonymisation Techniques.
GDPR, Recital 26 and Article 4(5) — pseudonymisation defined; pseudonymised data as personal data.
US FTC, Office of Technology (2024). "No, hashing still doesn't make your data anonymous." — the regulator's plain-language statement.
Narayanan, A., & Shmatikov, V. (2008). Robust de-anonymization of large sparse datasets. IEEE S&P — the linkage risk demonstrated at scale.

© Glu IO Pty. Ltd. — Wiz Kids (wiz.kids). Link freely; republication requires permission — see terms. Found an error in our reading of the research? We correct fast: tell any teacher piloting Wiz Kids.