Zwei Regeln, die sich zu widersprechen scheinen
Jede Security-Einführung sagt: Speichere niemals einen ungesalzenen Hash. Jeder Upload-Prozess einer Werbeplattform impliziert: Gib uns einen schlichten SHA-256 des normalisierten Werts. Wer zum ersten Mal mit Audience-Uploads zu tun hat, fragt zu Recht, welche der beiden Regeln falsch ist. Keine – sie lösen entgegengesetzte Probleme.
Wofür ein Salt da ist
Ein Salt ist zusätzliches Material, das vor dem Hashen in die Eingabe gemischt wird, damit identische Eingaben unterschiedliche Digests ergeben. Genau darum geht es beim Speichern von Zugangsdaten: Zwei Nutzer mit demselben Passwort bekommen unterschiedliche Hashes, und vorberechnete Nachschlagetabellen sterben. Salting ist der Standard, weil in diesem Kontext Unverknüpfbarkeit das Ziel ist.
Warum Matching das Gegenteil braucht
Audience-Matching funktioniert gerade deshalb, weil identische Eingaben identische Digests ergeben. Du hasht john@example.com auf deine Weise; die Plattform hasht ihren eigenen Datensatz zu john@example.com auf dieselbe Weise; die Digests fallen zusammen – und dieses Zusammenfallen ist der Match. Mische einen Salt hinein, den nur du kennst, und deine Digests passen zu nichts auf der Welt: eine vollkommen sichere Liste mit null gematchten Nutzern. Deterministisches, ungesalzenes Hashing ist keine Plattform, die es mit der Sicherheit nicht so genau nimmt – es ist der Mechanismus, der seine Aufgabe erfüllt.
Die Konsequenz, die du tragen musst
Ein ungesalzener Digest über einen kleinen Schlüsselraum ist konstruktionsbedingt schwach. Besonders Telefonnummern: den nationalen Nummernplan durchzählen, alles hashen – und die "anonymisierte" Spalte liest sich für jeden mit dieser Tabelle wie Klartext. Das lässt sich nicht beheben, denn die Schwäche und das Matching sind dieselbe Eigenschaft. Daraus folgt die Handhabungsregel: Eine Upload-Datei ist Transportformatierung, kein Schutz. Zugriff beschränken, bewusst teilen, nach Kampagnenende löschen. (Die lange Fassung dieses Arguments steht in unserem Leitfaden "Hashing ist keine Anonymisierung".)
Wo welche Regel gilt, in einer Tabelle
| Kontext | Salt? | Warum |
|---|---|---|
| Passwörter, Zugangsdaten | Immer | Unverknüpfbarkeit; Nachschlagetabellen aushebeln |
| Audience-Uploads bei Werbeplattformen | Nein | Matching verlangt deterministische Digests |
| Interne pseudonymisierte Analysen | Keyed/gesalzen | Du kontrollierst beide Seiten, nutze also einen geheimen Schlüssel |
Die dritte Zeile ist den Einschub wert: Wenn du Hasher und Matcher zugleich bist – wenn du Datensätze innerhalb deiner eigenen Systeme zusammenführst –, gibt es keine Plattform, gegen die abgeglichen werden müsste, und ein Keyed Hash verschafft dir echten Schutz. Halte nacktes SHA-256 den Uploads vor, die es verlangen.
Wo Hash Data hineinpasst
Hash Data erzeugt die Standard-Digests, die Audience-Uploads erwarten, direkt in Google Tabellen – mehrere Algorithmen als Formeln, dazu =HASHPHONE(), das in einem Schritt auf E.164 normalisiert und hasht. Was es nicht ändern kann, ist die Physik oben – und genau deshalb steht diese Seite neben dem Produkt, statt so zu tun, als wäre es anders.
Quellen
- EDSA-Leitlinien 01/2025 zur Pseudonymisierung – gelesen am 20.08.2026