Hashing er en envejsfunktion. Det samme input giver altid det samme output, og outputtet kan ikke regnes tilbage til inputtet. Derfor bruges hashing til at gemme kodeord og til at sammenligne værdier uden at gemme dem i klartekst. Det er en god funktion, men den gør ikke det, mange tror, den gør.
Salt
Et salt er en tilfældig værdi, der lægges til inputtet, før der hashes. Formålet er, at to brugere med samme kodeord ikke får samme hashværdi. NIST SP 800-63B-4 kræver et salt på mindst 32 bit til kodeord.
Salt hjælper mod forudberegnede tabeller. Det gør ikke mere end det. En angriber, der kender saltet, kan bare regne med det, og saltet ligger typisk i den samme database som hashværdien. Er databasen stjålet, er saltet stjålet med.
Derfor er et hashet CPR-nummer ikke anonymt
En hash yder kun beskyttelse, hvis der er rigtig mange mulige input, og de ikke kan gættes. Det er hele forudsætningen, og den holder ikke for et CPR-nummer.
Formatet er kendt af alle: DDMMÅÅ efterfulgt af fire cifre. Datodelen er begrænset af, at det skal være en rigtig dato, og løbenummeret er fire cifre. Rummet er lille, det er kendt, og det kan opregnes fuldstændigt. En angriber behøver ikke bryde hashfunktionen. Vedkommende hasher hele rummet én gang, laver et opslag og har navnet på personen bag hver eneste værdi.
Datatilsynets eget eksempel siger netop dette. Et hashet CPR-nummer er ikke anonymt.
Bemærk, at det samme gælder, selv om der er brugt salt. Saltet gør opregningen dyrere, fordi den skal gøres per post i stedet for én gang for hele databasen. Den bliver ikke umulig.
Juridisk konsekvens
Et hashet CPR-nummer er en pseudonymisering, ikke en anonymisering. Det er stadig en personoplysning, og GDPR gælder fuldt ud. Behandlingsgrundlaget skal være på plads, sletning skal ske, og den registrerede har sine rettigheder.
Det er værd at have med, hvis nogen foreslår at gemme hashede CPR-numre for at kunne genkende en kunde ved næste besøg, uden at gemme noget følsomt. Der bliver gemt noget følsomt.
Hvad man så gør
Vil man kunne genkende en person igen uden at ligge inde med nummeret, er tokenisering det rigtige værktøj. Et token er tilfældigt og kan ikke gættes ud fra formatet, fordi det ikke er afledt af værdien.
Ved en ren aldersgrænse er der en enklere vej. Er det eneste, forretningen skal bruge, at kunden er over 18, findes der flow, hvor svaret er et ja eller nej, og hvor der aldrig kommer et nummer ind. Så er der ingen hash, ingen tabel og ingen sletteregel at holde styr på.