Hash Verfahren genauer erklärt

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Es gibt Neuigkeiten! Ab sofort könnt ihr dem Donators Club auf Lebenszeit beitreten.
    Weitere Infos im Thema Donator's Club ab heute wieder verfügbar!

    • Hash Verfahren genauer erklärt

      Hallo liebe Brotfische,

      der Thread, über die Entsprrung von ReborN (Entsperrung von ReborN) hat mich zu diesem Thema inspiriert.
      Eigentlich ist das ja nur so hoch gekockt, weil er eine schlechte Hash-Methode benutzt hat (Wie soviele andere hier auch).

      Das zeigt ja eigentlich, dass man sich das auch gleich hätte schenken können. Denn schlechtes Hashing, ist fast gar kein Hashing.

      Aber woran das genau liegt und was das alles eigentlich genau ist, wird mal in diesem Thread ein wenig besprochen.

      Wir beginnen, mit dem bekannten Irrtum, dass ein Hash = eine Verschlüsselung ist.

      Was ist eine Verschlüsselung?

      Hier sollten wir zunächst auf ganz einfache Art- und Weise klären, was eine Verschlüsselung ist.
      Wir nehmen klassisch die gute alte Cäsar Verschlüsselung als Beispiel.

      Dort haben wir z.B. ein Wort "abc" und nehmen jetzt einfach immer einen Buchstaben weiter im Alphabet.
      Aus "abc" wird nun also "bcd".
      Aus "Hallo" wird "Ibmmp".

      Wow, perfekt verschlüsselt.

      Naja, nicht ganz, da es ja nur 26 Möglichkeiten gibt und man diese schnell durchprobieren kann.
      Deshalb wird diese auch nicht verwendet.

      Wir halten also fest, bei einer Verschlüsselung, verliert man keine Informationen (sieht man hier ganz deutlich, Input und Output haben die selbe Länge).
      Das ist ja auch notwendig (dass keine Information verloren geht), sonst könnten wir natürlich nicht mehr den Ursprünglichen Text rekonstruieren.

      Was ist nun Hashen?

      Nun, hier nutzt man eine mathematische Einwegfunktion (na super, toll erklärt), um eine Eindeutige Zeichenkette zu erhalten.
      Im Endeffekt können wir das mal ganz einfach an einem Beispiel exemplarisch erklären:

      Also wir nehmen den Index der Buchstaben im Alphabet (also A=1,B=2,C=3 usw).

      Dann haben wir ein Wort wie "Hi" und das kommt in unsere hash Funktion und daraus wird 8+9=17.

      Aus der 17 können wir jetzt aber gar nicht eindeutig ableiten, dass es sich ursprünglich um das Wort "Hi" gehalten hat.
      Es könnte ja auch einfach nur der Buchstabe "Q" sein.

      Und das ist ein Problem bei Hash-Funktionen, sie sollten zwar immer Eindeutig sein, aber das sind sie nicht.
      Eine große Schwäche von MD5 zum Beispiel ist, dass man schnell Zahlenkombinationen für bestimmte Hash-Werte findet.
      Man brauch für eine Passwort-Abfrage dann natürlich auch gar nicht den originalen Wert, sondern es reicht ja, dass der Hash-Wert übereinstimmt.

      Bei modernen Hash-Funktionen ist das sogar komplett unmöglich auf das ursprüngliche Passwort zu kommen, da diese eine feste Länge haben.
      Egal ob "hi" oder das komplette Werk von Goethe, wir landen bei MD5 z.B. immer genau bei 32 Stellen.
      Ganz offensichtlich gehen hier Informationen verloren.
      Aber das ist ja auch okay, weil wir ja gar nicht alle Informationen haben wollen, sondern nur sicher gehen wollen, dass wir wissen, dass unsere Eingabe mit dem Hash übereinstimmt.

      Allerdings gibt es sogenannte Rainbow-Tables, wo schon alle möglichen Passwörter gehasht wurden und man so versuchen kann, auf das Passwort zu schließen.
      Natürlich nicht immer möglich, wie z.B. bei den Büchern von Goethe...da ist ganz klar, dass wir da nichts finden werden, allerdings durch eine andere kleinere Buchstaben/Zahlen Kombination auf den selben Hash kommen können.

      Was hat es mit Salt oder Pepper auf sich?

      Also egal ob Salt oder Pepper, damit bezeichnet man im Endeffekt nur eine zufällige Zeichenkette (String), die vorne oder hinten an das Wort gehangen wird.

      Der Unterschied ist, dass ein Salt immer neu (z.B. für jeden Nutzer) generiert wird und ein Pepper, immer die selbe Zeichenkette ist (die dann aber halt nicht in der Datenbank, sondern woanders steht).

      Hat man z.B. alle seine Passwörter mit einem guten Pepper versehen und man hat nur die Datenbank, ohne Pepper, kann man damit nicht wirklich was anfangen.

      Denn
      1. Man kann die Passwörter nicht in Rainbow-Tables finden, weil diese ja nicht den Pepper berücksichtigen.
      2. Wenn der Server noch online ist, kann man sich nicht in die Accounts hacken, weil man ja nicht weiß, wie der Pepper den Hash verändert.
      Das ist zum Beispiel für SA:MP Server in meinen Augen sicherer, als den Salt direkt mit in der Datenbank zu speichern.
      Dann könnte man nämlich, wenn der Server noch läuft, wirklich Accounts knacken.

      Welche Hash-Methode denn nun?

      Hier geht man immer von dem Szenario aus, dass der Angreifer, sowohl den Salt/Pepper hat + das gehashte Passwort.
      MD5 wird ja oft verwendet, aber das hat 2 große Nachteile.
      1. Es kann sehr sehr schnell berechnet werden. Und so super schnell Passwörter knacken.
      2. Es ist nicht sehr Eindeutig. Da die Länge nur 32 Zeichen beträgt. Man kann also auch schnell andere Kombinationen finden und so Accounts knacken.
      SHA-256 oder Whirlpool sind besser, weil Punkt 2 sicherer ist.
      Allerdings sind diese Verfahren auch noch sehr schnell zu berechnen, das ist der Grund, warum diese auch nicht so gerne genutzt werden.

      Um Punkt 1 nun zu verhindern und zu schauen, dass man diese nicht so einfach bruteforcen kann, bedarf es also einer langsamen Hash-Methode.
      Und hier kommt Bcrypt bzw Scrypt ins Spiel.

      Um also wirklich sicher zu gehen, dass man theoretisch Salt/Pepper + gehashtes Passwort dem Angreifer in die Finger fallen und man Bcrypt verwendet hat, sind diese Daten immer noch relativ sicher, da es suuuuper lange dauern würde, bis man ein Passwort geknackt hätte.

      Download: forum.sa-mp.com/showthread.php?t=453544

      Schlusswort
      In diesem Sinne, kann ich nur jedem Bcrypt ans Herz legen, um wirklich sicher zu gehen, dass alle Passwörter sehr gut gesichert sind.
      Hoffe der Thread klärt ein bisschen auf, falls es Fragen oder Anmerkungen gibt, gerne einfach schreiben.


      Mit freundlichen Grüßen
      Euer Kalle :P


      Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. X/
    • Meiner Meinung nach, ist sowas wie Bcrypt in SA:MP garnicht nötig.
      Z.b. Whirlpool ist schon ziemlich sicher, und wir reden hier ja nur von einem SA:MP Server Passwort. Ich glaube nicht, dass jemand mehrere Monate oder Jahre mein Passwort brute forcet, um dann meine 500.000GTA$ auf sein Konto zu überweisen.
      Ich helfe zu allen Fragen bezüglich PAWN Scripting gerne weiter.
      Auch im Bereich JavaScript und dort der RageMP API helfe ich gern.

      Konversation: Konversation starten
      Discord: LeonMrBonnie#2251

    • LeonMrBonnie schrieb:

      Meiner Meinung nach, ist sowas wie Bcrypt in SA:MP garnicht nötig.
      Z.b. Whirlpool ist schon ziemlich sicher, und wir reden hier ja nur von einem SA:MP Server Passwort. Ich glaube nicht, dass jemand mehrere Monate oder Jahre mein Passwort brute forcet, um dann meine 500.000GTA$ auf sein Konto zu überweisen.
      Es geht hier nicht um SA:MP.

      Das geht ja viel weiter.

      In dem Meisten Datenbanken steht ja auch noch die Email dieses Nutzer oder der Nickname ist eben eindeutig.

      Es besteht jetzt eine hohe Wahrscheinlichkeit, dass der User dieses Passwort überall verwendet (nicht nur auf dem SA:MP Server).

      Das ist auch der Grund, wieso das so ein Ding im Thread über ReborN ist, es geht hier um keinen SA:MP Server der eh down ist, sondern um die Tatsache, dass es nun möglich wäre die Email Adresse von Nutzern zu knacken oder sogar auf anderen Plattformen wie Facebook/Twitter/Instagram/Breadfish etc zu hacken oder gar zu erpressen.

      Der Punkt ist, dass das User sensible Daten sind und diese mit höchster Sicherheit zu verwahren sind und das ernst genommen werden sollte. Weil man ansonsten dafür belangt werden könnte (DSGVO).

      Und um ein SHA-256 Passwort zu knacken bedarf es keine Monate. Ohne Salt/Pepper hat man das in Millisekunden dank riesen Rainbow-Tables.
      Mit Salt/Pepper dauert es je nach Rechenleistung aber auch nicht so lange, da diese Hash-Funktionen gut parallelisierbar sind (das heißt je mehr Geräte, desto schneller).

      Und man könnte leicht sich eine bestimmte Person raussuchen und fertig machen.

      Deshalb wirklich bcrypt (da es ja auch gar keinen großen Aufwand darstellt, dies einfach zu nutzen) um sicher zu gehen :)


      Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. X/