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.
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.
Zuletzt bearbeitet:
