Welches Hash Verfahren bei Daten mit wenig Möglichkeiten?

tollertyp schrieb:
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.

Ja, aber man kann anhand eines Bewertungsdatensatzes nicht mehr sagen zu welcher Telefonnummer dieser gehört. Andersrum gehts. Man kann zu einer Telefonnummer alle Bewertungsdatensätze anzeigen.

Besser gehts nur mit einer zweiten Partei, würde ich sagen...
 
@marvin.seb Der individuelle Salt bringt dir den Vorteil, dass du damit 20.000.000 Rainbow-Tabellen erstellen musst. Für jede Möglichkeit musst du die Tabelle mit dem Salt neu berechnen. Ergo bist du nicht besser als Brute-Force. Jetzt machst du es noch langsam, so ca. 0.25s pro Hash.

20.000.000 * 20.000.000 * 0,25s / 60 / 60 / 24 / 365 = 3.170.979 Jahre

So kannst du auf die schnelle nicht alle Daten berechnen.
 
@marcOcram: Und woher weiß bei der Suche, welcher Salt verwendet werden muss?

Wenn ich einen User-Login habe, dann weiß ich, dass User X eben das Salt Y hat. Wenn jemand behauptet, User X zu sein, kenne ich das zu verwendende Salt beim Vergleich.

Kenne ich es nicht, dann kann die Prüfung lang dauern, schließlich muss ich dann einen Brute-Force-Angriff gegen mich selbst führen.
 
Stimmt natürlich. Habe den Edit erst jetzt gelesen. Damit klappt das dann naturlich nicht.
 
  • Gefällt mir
Reaktionen: tollertyp
Ja, der Ausgangspost war auch nicht ausreichend beschrieben, der Edit brachte Klarheit, hätte aber nicht geschadet dafür noch "Werbung" im Thread zu machen, ich habe ihn auch erst spät zufällig gesehen.
 
@tollertyp @marcOcram Habe schon öfters gelesen, dass die Saltinformation nicht in der selben Datenbank stehen darf. Ich sehe keine Möglichkeit, wie der Threadersteller sich vor sich selber schützen kann.
 
aluis schrieb:
Ich sehe keine Möglichkeit, wie der Threadersteller sich vor sich selber schützen kann.
Ich glaube, das ist in der Theorie auch ausgeschlossen.^^
 
aluis schrieb:
@tollertyp @marcOcram Habe schon öfters gelesen, dass die Saltinformation nicht in der selben Datenbank stehen darf.
Es gibt Hashs, da ist der Salt Teil des Hashs selbst...
Aber wenn du das gelesen hast, dann findest du das ja auch bestimmt wieder. Ich halte es für irrelevant in Bezug auf Sicherheit.
 
tollertyp schrieb:
da ist der Salt Teil des Hashs selbst
Was ja keinen Unterschied macht, ob man nun Zugriff auf einen "Superhash" hat oder nur auf einen normalen Hash und den Salt. Der Angriffsvektor bleibt gleich.
 
  • Gefällt mir
Reaktionen: tollertyp
Ach ja... die haben wohl keine Ahnung...
1697054242679.png
 
  • Gefällt mir
Reaktionen: CyborgBeta
tollertyp schrieb:
Ach ja... die haben wohl keine Ahnung...
Das mag korrekt für die Möglichkeiten bei Passwörtern sein. Aber bei nur 20 Millionen Möglichkeiten (Telefonnummern) bringt das eigentlich nichts.
 
tollertyp schrieb:
Ach ja... die haben wohl keine Ahnung...

... In einer kühlen und dunklen Umgebung natürlich 🤣 (SCNR...)

1697054846613.png


(etwas Spaß muss sein...)
 
  • Gefällt mir
Reaktionen: mental.dIseASe und tollertyp
aluis schrieb:
Aber bei nur 20 Millionen Möglichkeiten (Telefonnummern) bringt das eigentlich nichts.
Der Thread bzgl. die Frage nach dem Salt hat etwas von "Ich habe ein Lösung, aber sie passt nicht zum Problem". Es ist nicht die Schuld des Problems, dass es nicht zur Lösung passt.
 
  • Gefällt mir
Reaktionen: CyborgBeta
Gerade gelesen, eine 4070Ti schafft 9 Milliarden SHA256 pro Sekunde :)
Ergänzung ()

Mir hat der Thread auf jeden Fall Spaß gemacht... bisschen Grübeln vorm schlafen gehen. Vielleicht äußerst sich ja der Ersteller nochmal genauer.

Ich wünsche allen eine erholsame Nacht.
aluis
 
  • Gefällt mir
Reaktionen: konkretor, CyborgBeta und tollertyp
marvin.seb schrieb:
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.
Du musst konkret angeben, gegen welche Angriffszenarios du die Daten absichern willst, sonst hat es wenig Sinn, über Maßnahmen zu sprechen. Gegen Rainbow-Table-Angriffe kannst du einen Salt verwenden. Die Sicherheit der Maßnahme hängt nicht von der Geheimhaltung des Salts ab.
Du als Betreiber brauchst keinen Rainbow table erstellen, denn wenn ein Nutzer die Daten eingibt und an dich schickt, dann sind die sowieso temporär in Klartext auf deinem Server und du verarbeitest personenbezogene Daten. Wenn du das vermeiden willst, dann müssen die Daten schon beim Nutzer im Browser per Javascript gehasht werden. Vielleicht suchst du ja danach?
 
  • Gefällt mir
Reaktionen: tollertyp
Eines sollte man sich klar sein:
Wenn das ganze ein Einweg-Hash ist, wirst du die Strategie im Nachhinein kaum ändern können - gut, du könntest aus einmal Hashen zu x-Mal Hashen willst, das kann man machen. Aber von SHA256 auf SAFEHASH1024 zu wechseln würde nicht gehen.
 
Ist das Speichern von Telefonnummern alleine überhaupt ein Problem im Sinne des Datenschutzes? Schließlich lässt sich von der Nummer ohne Kombination mit anderen Datenquellen nicht auf eine natürliche Person schließen. Und die Verknüpfung von Tel zu Namen über andere Datenquellen wäre wiederum das Problem dieser anderen Datenquellen.
 
  • Gefällt mir
Reaktionen: TomH22
@floq0r naja Telefonnummern und bewerten ohne den Service dahinter nicht zu kennen ...

welches Nutzer machen sollen ...

Also doch Nutzerdaten und nicht nur Telefonnummern ... somit hat der TE ja zwei Datensätze die miteinander verknüpft sind...
 
Hallo, danke euch für die vielen Antworten. Leider müssen meine Beiträge immer genehmigt werden, da ich noch ne bin. Dadurch entgehen euch manche Beiträge wohl. Das tut mir Leid.

Ich möchte mein Problem nun nochmal vereinfacht darstellen:

Ich habe eine Webseite, auf welcher ihr Telefonnummern bewerten könnt. Die Seiten die ihr so kennt, speichern die Telefonnummern ja im Klartext. Das finde ich nicht okay, da ich mich sehr für Datenschutz interessiere. Benötigt wird nun also eine Möglichkeit, wie ich Bewertungen zu Telefonummern hinzufügen kann und diese auch anzeigen kann, ohne die Telefonnummer tatsächlich im Klartext zu besitzen. Die Eingabe der Telefonnummer kommt immer vom Nutzer über die Suche. Natürlich würde sich das Hashing anbieten. Nutzer gibt die Nummer ein und bewertet diese. Wir speichern die Bewertung zu der gehashten Nummer. Wenn ein Nutzer nun die Bewertung einer Nummer abrufen will, gibt dieser die Nummer ein, wir hashen die und erkennen diesen Hash. Denn zuvor wurde bereits eine Bewertung zu deiser Nummer abgegeben. Nun zeigen wir diese Bewertung an.

Allerdings gibt es aufgrund dem Format von Telefonnummern nur wenige Millionen Möglichkeiten, wodurch ein Angreifer oder ich selber schnell eine Rainbow Table erstellen kann, um die Datenbank zu entschlüsseln.

Meine Frage ist nun, wie ich es hinbekommen kann, dass diese Rainbow Table Attacke kein Problem mehr darstellt und ich theoretisch über 1 Jahr dafür benötigen würde das zu knacken. Im besten Fall mehr als 10 Jahre.

Vor wen möchte ich mich schützen? Vor Angreifern und vor mir selbst. Ich möchte nämlich auch den Fall ausschließen, dass Mitarbeiter Informationen leaken oder diese Mitarbeiter selber versuchen die Datenbank zu entschlüsseln. Das darf nicht möglich sein. Also Schutz sollte von außen und innen gegeben sein.

Und selbst wenn ich einen Salt hinzufüge, dann weiß ich ja wie ich den Salt für jede Nummer berechne. Mit dieser Info kann ich dann ja auch eine Rainbow Table erstellen. Einfach mit "NUMMER + SALT (GenerierungSalt) -> Hash". Ist einfach nur eine zusätzliche Berechnung.

Denkt ihr, dass dies irgendwie machbar ist? Oder ist das technisch ein Ding der Unmöglichkeit?

floq0r schrieb:
Ist das Speichern von Telefonnummern alleine überhaupt ein Problem im Sinne des Datenschutzes?
Denke, dass dies kein wirkliches Problem darstellt. Machen ja aktuell auch viele Seiten so. Aber selbst wenn es tatsächlich kein Problem darstellt, will ich trotzdem das Maximum an Datenschutz. Und Telefonnummern sind weiterhin nur ein Beispiel. Aber ist 1:1 vergleichbar mit meinem tatsächlichen Fall.

xxMuahdibxx schrieb:
Also doch Nutzerdaten und nicht nur Telefonnummern ... somit hat der TE ja zwei Datensätze die miteinander verknüpft sind...
Wenn ein Besucher der Webseite nach einer Telefonnummer sucht und diese bewertet, dann speichere ich nur die Bewertung zu dem Hash in der Datenbank ab. Ich brauche keine Mail Verifikation oder sonstige Nutzerdaten.
 
Was ich nicht verstehe: was hält den Angreifer ab, deine Webseite mit allen möglichen Telefonnummern aufzurufen? Dazu müsste er ja nicht mal das System hacken...
 
  • Gefällt mir
Reaktionen: Arc Angeling, CyborgBeta, marvin.seb und eine weitere Person
Zurück
Oben