Welches Hash Verfahren bei Daten mit wenig Möglichkeiten?

[Dalek]

Ganz generell, wenn die Daten die reinkommen relativ systematisch und teilweise vorhersagbar sind dann kann Hashing keine vollständige Lösung sein. Das geht einfach grundsätzlich nicht. Bei Passwörtern funktioniert das nur einigermaßen weil halbwegs gute Passwörter nicht vorhersagbar sind. Sehr schwache Passwörter kann man auch knacken wenn ein guter, langsamer Hash mit Salt verwendet wird.

Wenn man jetzt relativ vorhersehbare Daten mit so einem Passworthash speichert ist das in etwa so als ob jedes einzelne Passwort ein richtig schlechtes wäre. Es dauert dann immer noch etwas um die Hashes zu knacken, aber es ist kein wirklicher Schutz gegen einen motivierten Angreifer der die Hashes erbeutet hat.

Es gibt ein ähnliches Problem in freier Wildbahn bei Gravatar, diesem Anbieter mit dem man seinen Avatar auf verschiedenen Seiten einfach verwalten konnte. Ist heute nicht mehr beliebt, war aber mal recht populär. Gravatar hat einen md5 Hash von deiner Email benutzt um die Avatare zu laden. Am Ende hatte das die Konsequenz das man von vielen Benutzern nur aus der Avatar URL die Emailadresse bekommen konnte indem man md5 Hashes generiert und vergleicht. Die Domäne von Emails ist nicht besonders variabel, die beliebtesten Anbieter kann man einfach durchprobieren. Und dann benutzen viele Emails der Art "Vorname.Nachname@gmail.com" die man sehr gut durchprobieren kann.

Es gibt keine robuste technische Lösung hier. Telefonnummern sind strukturiert und leicht durchzuprobieren. Mit einem sehr langsamen Hash kann man die Angriffe vermutlich uninteressant machen, aber nicht wirklich verhindern.

Wenn du ein Projekt dieser Art durchführen willst, dann solltest du rausfinden ob es akzeptabel ist die Telefonnummern auch im Klartext zu speichern. Und du solltest dein System so betrachten als ob du sie im Klartext da drin hast, egal ob sie gehasht sind oder nicht.

Und noch eine Nebenbemerkung, Rainbowtables sind heute meistens irrelevant. Man kann sehr, sehr viele Hashes auf einer GPU durchprobieren. Das ist viel effizienter als Rainbowtables. Man sollte trotzdem ein Salt verwenden da in bestimmten Situationen mit guten Hashes evtl. Rainbowtables nützlich wären. Aber bei Hashes die auf einer GPU gut berechnet werden können sollte man sich keinen echten Schutz davon versprechen.

 

[ayngush]

Wenn ich mir via for i=0; i<=999999999999999; i++ eine Datenbank mit 15-Stelligen Zahlen aufbaue sind da quasi "alle" Telefonnummern enthalten und keine davon ist Personenbezogen. Der Personenbezug entsteht erst dann, wenn man auch Personenmerkmale dazu herleiten kann. Ansonsten haben einige Datenbanken mit ihren BigInt-Indizes demnächst echt ein DSGVO-Problem...

 

[Piktogramm]

@ayngush
Was darf Satire?
Als ob die Menge technisch möglicher IDs einer Datenverwaltung auch nur annähernd vergleichbar ist mit Einträgen von pseudonymen Telefonnummern. Geschweige denn, dass Anwendung in Richtung Nutzer·innen Indizes in der Regel nicht exponieren, der TE aber eindeutig beschreibt, dass nach Telefonnummern als eindeutiges Identitätsmerkmal durch Nutzer·innen gesucht und bewertet werden sollen.
Deine Spitzfindigkeit in allen Ehren, das ist aber Unfug.

 

[ayngush]

Es sollen Telefonnummern bewertet werden. Wahrscheinlich solche Spam-Nummern. Solche Anwendungen gibt es zu Hauf da draußen und keine verstößt gegen irgendwelchen Datenschutz-BlaBlubb, da eine Telefonnummer an sich betrachtet eben kein Personenbezogenes Merkmal ist. Das kann sie durch ein Kommentar eventuell werden, da muss man dann halt entsprechend moderieren. Solche Kommentare würde ich eh mit Freischaltungsvorbehalt zulassen.
Aber hört auf mir verkaufen zu wollen, dass eine Telefonnummer für sich genommen irgendwas mit einen Personenbezug zu tun hat und wenn sie das hätte, wäre eine Pseudonymisierung durch ein Hash-Algorithmus genau so unzulässig wie das speichern und verarbeiten im Klartext. Telefonnummern sind so gut wie Geburtsdatum oder Schuhgrößen oder Haarfarben. Das kann alles einen Personenbezug haben, wenn es den aber nicht hat, sind es halt nur Zahlen und Buchstaben. Nuff said.

 

[zenokortin]

Statt sich um so eine komische Hash-Speicherung Gedanken zu machen, sollte man sich lieber über Workflows bei DSGVO-Anfragen Gedanken machen. zB. wenn jemand verlangt, dass seine persönliche Phone-Nummer von der Webseite entfernt wird und Auskunft über gespeicherte Daten verlangt.

 

[floq0r]

wenn jemand verlangt, dass seine persönliche Phone-Nummer von der Webseite entfernt wird und Auskunft über gespeicherte Daten verlangt.

Ein lustiger Gedanke, wenn eine Tel nur hashed gespeichert ist dann besteht vermutlich gar keine Auskunftspflicht.

 

[zenokortin]

Ich vermute, rein die Nummer wird auch nicht problematisch sein, wenn es zB eine reine Iteration über alle möglichen Nummern ist. Aber wenn zu einer Nummer eine Bewertung existiert, vor allem eine negative kann man das schon Richtung Rufschädigung sehen. Ganz lustig wird es, wenn es auch eine Kommentarfunktion gibt.

 

[ayngush]

dann besteht vermutlich gar keine Auskunftspflicht.

Doch und zwar über die pseudonymisierten Daten und alles, was dazu gespeichert und verarbeitet wurde. Pseudonyme Daten sind halt nicht anonyme Daten und pseudonyme Daten sind genau so zu behandeln wie normale Daten und unterliegen den gleichen Regelungen.

 

[floq0r]

Verstehe