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
- Man kann die Passwörter nicht in Rainbow-Tables finden, weil diese ja nicht den Pepper berücksichtigen.
- 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.
- Es kann sehr sehr schnell berechnet werden. Und so super schnell Passwörter knacken.
- 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: Github - BCrypt Plugin
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 
