Welches Hash Verfahren bei Daten mit wenig Möglichkeiten?

[marvin.seb]

Guten Tag,

ich muss bestimmte Nutzerdaten speichern, welche ich jedoch nicht im Klartext speichern darf. Deshalb wollte ich diese Daten hashen. Allerdings habe ich das Problem, dass es „nur“ 20.000.000 Möglichkeiten dieser Daten gibt. Wenn ich nun also via SHA256 hashe, könnte ich einfach eine Rainbow Table Attacke durchführen. Also für alle 20 Mio. Möglichkeiten den Hash generieren und dann mit der Datenbank abgleichen. 20 Mio. finde ich nicht wirklich viele Möglichkeiten und die entsprechende Rainbow Table sollte ja schnell erstellt sein.

Meine Frage ist nun, ob ihr eine Idee habt, wie ich die Rainbow Table Attacke verhindern könnten? Mir ist es wichtig, dass ich selber als Betreiber auch nicht die Möglichkeit habe auf irgendeinen Weg die gehashten Daten zu entschlüsseln.

Also wenn ich jetzt als Betreiber einen Salt berechne und diesen dann zusammen mit den Nutzerdaten hashen, dann weiß ich ja als Betreiber wie sich der Salt berechnet. Ergo könnte ich dann ja eine Rainbow Table Attacke gegen mich selber machen. Und ein Angreifer könnte ja auch an die Information kommen, wie sich der Salt berechnet.

Es ist halt auch wichtig, dass ich in der Zukunft die Nutzerdaten abgleichen kann. Also ein Nutzer gibt die Daten ein und dann werden diese gehasht. Wenn der Nutzer diese Daten nun 2 Monate später erneut eingibt, dann soll das natürlich mit dem Hash in der Datenbank verknüpft werden, welcher vor 2 Monaten erstellt wurde.

Edit: Etwas vereinfacht formuliert: Ich habe eine Webseite auf der man nach einer Telefonnummer suchen kann, um diese dann bewerten zu können. Allerdings will ich die Telefonnummer nicht im Klartext auf dem Server haben. Daher sind die Bewertungen nur mit dem Hash verknüpft. Und wenn der Nutzer die Telefonnummer im Klartext eingibt, dann wird diese gehasht und der Hash wird vom Server wiedererkannt und die Bewertungen dazu werden angezeigt. Allerdings kann es nur 20 Mio. Telefonnummern geben (Telefonnummern natürlich mehr, aber nehme das als Beispiel), weshalb ich schnell die gesamte Datenbank entschlüsseln kann via Rainbow Table. Ich als Betreiber sollte auch nicht die Möglichkeit haben mich selber mit einer Rainbow Attack anzugreifen. Denn wenn ich die Hashes einfach via Rainbow Attack entschlüsseln kann, dann kann ich die Telefonnummern auch direkt im Klartext speichern, was dann aber gegen den Datenschutz verstößt (zumindest in meinem Fall).

Vielleicht hat hier ja jemand eine Idee, wie man mit sowas umgeht.

Vielen Dank also schon mal im voraus!

 

[dermoritz]

Wichtig ist zu wissen, dass beim hashen die Daten verloren gehen. Sie sind nicht gespeichert.
Nur wenn man die Daten 1:1 nocheinmal eingibt kann man mit sehr hoher wahrscheinlichkeit feststellen ob es die gleichen daten waren.

Weiß nicht ob dies dein Ziel ist.

Zu deinem Problem: man kann dem Hash beliebige Dinge hinzufügen - die nur due weißt und damit die Möglichkeiten erhöhen. (wenn die nutzerdaten passworte sind - funktioniert das genau so - mit "salt")

Was ist dein Ziel? Und was ist geheim (darf nur der Benutzer wissen, und was darfst nur du wissen?)

 

[marcOcram]

Du nimmst für jeden Datensatz einen eigenen Salt und eine Hash-Funktion die "ewig" dauert. Damit dauert das Erstellen der Rainbow-Table pro Möglichkeit und Salt eine "Ewigkeit".

 

[CyborgBeta]

Suchst du nach einer Hashfunktion oder nach einem Komprimierungsverfahren? Das sind zwei Paar Schuhe, da ersteres ein Einwegverfahren ist.

 

[aluis]

Bei Festplattenverschlüsselung wie LUKS oder VeraCrypt geht man den Weg, dass man mehrere Runden hasht. So oft, dass es 5 bis 10 Sekunden pro Passworteingabe dauert. Für ne Webseite ist sowas aber nicht praktikabel.

 

[tollertyp]

Also ich finde da ist noch zu wenig Kontext-Wissen, um das genau zu erfassen.

Z.B. Haben die Nutzer Accounts oder keine? Warum gibt der User die gleichen Daten nochmal ein und sie werden dann "verknüpft"?

@CyborgBeta: Wie kommst du auf Komprimierung? Wohl eher Verschlüsselung?

 

[marvin.seb]

Wichtig ist zu wissen, dass beim hashen die Daten verloren gehen. Sie sind nicht gespeichert.
Nur wenn man die Daten 1:1 nocheinmal eingibt kann man mit sehr hoher wahrscheinlichkeit feststellen ob es die gleichen daten waren.

Das ist mir bekannt. Ich will ja auch, dass die Daten eben nicht in der Datenbank vorhanden sind. Ich will aber, dass ich die Daten erkennen kann, wenn diese erneut eingegeben werden, damit ich diese zuordnen kann.

Zu deinem Problem: man kann dem Hash beliebige Dinge hinzufügen - die nur due weißt und damit die Möglichkeiten erhöhen.

Du nimmst für jeden Datensatz einen eigenen Salt und eine Hash-Funktion die "ewig" dauert. Damit dauert das Erstellen der Rainbow-Table pro Möglichkeit und Salt eine "Ewigkeit".

Aber was bringt es denn den Daten beliebige Dinge oder einen Salt hinzuzufügen? Ich als Betreiber weiß doch ganz genau wie genau sich dieser Salt berechnen lässt, welchen ich dann jedem neuen Datensatz hinzufüge. Ergo bringt der Salt dann ja gar nichts, da ich damit als Betreiber selber eine Rainbow Table erstellen kann.

Und ja, ich könnte Argon2 verwenden. Aber das ist vermutlich auch nicht perfekt und kommt (erstmal) leider nicht infrage.

Suchst du nach einer Hashfunktion oder nach einem Komprimierungsverfahren? Das sind zwei Paar Schuhe, da ersteres ein Einwegverfahren ist.

Hashfunktion. Ich möchte keine Daten speichern, aber wiedererkennen und zuordnen können, wenn diese erneut eingegeben werden.

Z.B. Haben die Nutzer Accounts oder keine?

Es gibt keine Accounts. Nutzer geben nur irgendwas in eine Suche ein, ohne Account. z.B. eine Telefonnummer (nur ein Beispiel). Und dann bekommen die zu dieser Telefonnummer Bewertungen angezeigt. Aber ich will die Telefonnummern eben nicht im Klartext speichern, aber wiederkennen und mit Bewertungen verknüpfen.

 

[CyborgBeta]

@CyborgBeta: Wie kommst du auf Komprimierung?

Hatte quergelesen, aber nun ganz ...

PBKDF2-HMAC-SHA-256 mit 100.000 Iterationen sollte für sein Vorhaben ausreichend sein. Quelle: https://security.stackexchange.com/...ns-of-sha256-good-enough-for-password-storage

Salt wird nicht benötigt.

 

[marvin.seb]

Habe im ersten Post mal eine bessere Erklärung hinzugefügt.

PBKDF2-HMAC-SHA-256 mit 100.000 Iterationen sollte für sein Vorhaben ausreichend sein. Quelle: https://security.stackexchange.com/...ns-of-sha256-good-enough-for-password-storage

Salt wird nicht benötigt.

PBKDF2-HMAC-SHA-256 nutzt doch das Salting. Und ich habe dann doch als Betreiber die Möglichkeit mit PBKDF2-HMAC-SHA-256 die 20 Mio. Kombinationen zu generieren und damit meine Datenbank in realistischer Zeit zu entschlüsseln, oder nicht?

Generell frage ich mich auch wo die Grenze ist. Also wenn ich Daten speichere, bei denen ich eigentlich die Einverständnis des Nutzers benötige. Wenn ich die Daten ja hashe, ist es ja egal. Aber wenn es eh nur zwei mögliche Kombinationen gibt, dann ist es ja nicht egal. Wenn es 100 Billiarden Kombinationen gibt, dann wäre es aber egal. Aber bei 20. Mio ist das glaube noch in dem Bereich "nicht egal". Oder?

 

[CyborgBeta]

PBKDF2-HMAC-SHA-256 nutzt doch das Salting. Und ich habe dann doch als Betreiber die Möglichkeit mit PBKDF2-HMAC-SHA-256 die 20 Mio. Kombinationen zu generieren und damit meine Datenbank in realistischer Zeit zu entschlüsseln, oder nicht?

Ich glaube, das Problem ist hier, dass es ganz einfach zu wenige Kombinationsmöglichkeiten gibt, also die Passwörter/Eingaben zu kurz sind. ... Mag mich aber auch irren.^^

 

[tollertyp]

Er meint damit, dass du einen Salt für alle und kein individuelles Salt bräuchtest.

Also Daten, die das Einverständnis des Nutzers erfordern, darfst du ohne Erlaubnis auch nicht einfach als Hash speichern. Wenn es z.B. personenbezogene Daten sind, dann kannst du ja immer noch auf die Person schließen - zwar mit höherem Aufwand, aber das ist an der Stelle ja egal...

Also es würde helfen, wenn du Details liefern würdest.

@CyborgBeta: Wir wissen ja nicht, wie viel Text da zu einem Hash transformiert wird. Ist es das Geburtsdatum? Die Handy-Nummer? Die komplette Anschrift normalisiert ohne Leerzeichen?
Der Angreifer wird es wohl wissen. Erschreckend, dass wir als helfende unwissender sind als die Gefahr.

 

[xxMuahdibxx]

Mal eine ganz dumme Idee..

Wie gewährleistet du es wenn ein User seine Logindaten vergisst aber eine Löschung seines Profils verlangt.

Du willst ja keinen Zugriff haben musst aber personenbezogene Daten ganz anders händeln..

 

[tollertyp]

Wobei es sich ja offensichtlich gar nicht um Login-Daten handelt. Sonst wäre ein individuelles Salt ja kein Problem.

Edit: Ach es geht um Telefonnummern?

 

[CyborgBeta]

Der Angreifer wird es wohl wissen. Erschreckend, dass wir als helfende unwissender sind als die Gefahr.

Ich verstehe ehrlich gesagt auch noch nicht, was @marvin.seb genau verhindern möchte ... also, was wovor (wie) geschützt werden soll.

 

[tollertyp]

Ich habe den Edit im Eröffnungspost wohl vorher noch nicht gesehen.

Also meiner Meinung nach:
Ob die Telefonnummer gehasht gespeichert wird befreit dich nicht von der Erlaubnis. Hast du grundsätzlich eine Erlaubnis die Telefonnummern zu erfassen?
Ich meine grundsätzlich hört es sich ja für mich wie eine typische Seite wie tellows.de an.

 

[aluis]

Ich hätte eine Idee:

Schritt 1: Telefonnummer als SHA256
Schritt 2: Tabelle mit Spalte (1) SHA256 der Telefonnummer und einer Spalte (2) mit einer Zufallszahl
Schritt 3: Die gewünschten Daten sind zu finden über den SHA256 aus Spalte 1 + Spalte 2

Um beim Beispiel zu bleiben, hast du jetzt statt 20 Millionen nun 20 Millionen*20 Millionen. Genug um zu sagen, du kannst die gewünschten Daten nicht einer Telefonnummer zuordnen. Bei Bedarf Schritt 2 und 3 als Schritt 4 und 5 wiederholen. Ergibt 20 Millionen * 20 Millionen * 20 Millionen. usw...

Regenbogentabelle ausgeschlossen

 

[tollertyp]

Und wo speicherst du das Salt, oh, Sekunde, das nennen wir ja jetzt Zufallszahl?

 

[aluis]

Und wo speicherst du das Salt, oh, Sekunde, das nennen wir ja jetzt Zufallszahl?

Es geht ja nur um die Information. Klar kann der Programmierer auch gleich die eingegebene Telefonnummer abgreifen.

Für mich klang der Thread so, dass man abstreiten kann, die Telefonnummer den Arbeisdaten zuordnen zu können.

 

[tollertyp]

Also der Sinn ist doch, dass wenn zu der Telefonnummer neue Bewertungen dazu kommen, diese dann auch zugeordnet werden, und gleichzeitig dass wenn nach der Telefonnummer gesucht wird, alle Bewertungen angezeigt werden.

 

[CyborgBeta]

Hier ist eine ganz gute Zusammenfassung: https://doubleoctopus.com/security-wiki/encryption-and-cryptography/salted-secure-hash-algorithm/

Kurz gesagt schützt Hash + Salt (oder Nonce...) vor Wörterbuchattacken und Rainbow-Tables.

Allerdings können die Eingabedaten nicht geschützt werden, wenn jemand Zugang zu der Datenbank bzw. zum Hash + Salt hat und die Eingabedaten zu kurz sind.