Heute werden wir sehen, wie Passwörter am besten in einer Datenbank gespeichert werden und wie bekannte Plattformen dieses Problem lösen.
Klartext
Wenn sich die Frage nach dem Speichern von Passwörtern stellte, bestand die erste Idee natürlich darin, sie einfach offen in das entsprechende Typenschild in der Datenbank zu schreiben. Und alles wäre in Ordnung, wenn die Kunden nicht direkt darauf zugreifen könnten. Leider funktioniert eine solche bekannte SQL-Injection manchmal immer noch in verschiedenen Webanwendungen, ganz zu schweigen von anderen potenziellen Schwachstellen. In Sicherheitsfragen ist es allgemein anerkannt, das Schlimmste anzunehmen und auch in einem solchen Fall einen Aktionsplan und Schutz zu erstellen. Wir gehen davon aus, dass der Angreifer auf die eine oder andere Weise eine Lücke in der Webanwendung gefunden hat, indem er eine Tabelle mit den Namen und Passwörtern der Benutzer entlädt und diese nach Belieben weiter entsorgt. Im Allgemeinen können seine weiteren Aktionen wie folgt sein:
- Ausführen unzulässiger Aktionen im Namen von Benutzern, die ihre Anmeldeinformationen für eine anfällige Ressource verwenden: Beispielsweise ist eine Bankkarte an ein Konto gebunden, und jetzt kann ein Angreifer sie verwenden.
- ein Versuch, das empfangene Passwort für andere Ressourcen zu verwenden: Weit davon entfernt, dass Benutzer nach den Anweisungen jedes Mal neue Passwörter für verschiedene Dienste entwickeln;
- ein Versuch, eine Regel zum Generieren eines Passworts zu identifizieren und zum zweiten Punkt überzugehen: Einige bilden eine Regel zum Generieren eines Passworts. Infolgedessen sind die Passwörter auf verschiedenen Ressourcen unterschiedlich, sie befolgen jedoch dieselbe Regel, die erkannt werden kann.
- Eskalation von Berechtigungen: Das Administratorkennwort kann auch in derselben Tabelle gespeichert werden, mit deren Wissen Sie manchmal die volle Kontrolle über den Server erhalten können.
Verschlüsselungs- Hashing
Die Idee stellt sich sofort als nicht so gut heraus. Was zu tun ist? Es wäre toll, Passwörter in verschlüsselter Form zu speichern. Selbst wenn sie entfernt werden, können sie sich nicht erholen oder verbringen zumindest zu viel Zeit damit. Hier besteht die Wahl zwischen zwei Entwicklungszweigen: Verschlüsselung von Passwörtern oder Hash. Die Entwickler haben sich für die zweite entschieden, und im Prinzip ist klar, warum. Vergleichen Sie unsere Bewerber für verschiedene Merkmale:
- Arbeitseinsatz. Die Verschlüsselung benötigt mehr Zeit und muss unabhängig von der gewählten Konvertierung bei jeder Kennwortprüfung durchgeführt werden. Eine der Anforderungen für Hash-Funktionen ist die Ausführungsgeschwindigkeit.
- Die Länge der Ausgabewerte. Das Verschlüsselungsergebnis ist variabel lang, das Hash-Ergebnis ist immer das gleiche und das Speichern einheitlicher Daten in einer Datenbank ist sehr praktisch. Ganz zu schweigen von der Tatsache, dass die Länge des Passworts in verschlüsselter Form einige Informationen über die Länge des ursprünglichen Passworts liefert. Die gleiche Länge führt jedoch zu Kollisionen, mehr dazu weiter unten.
- Schlüsselverwaltung. Für die Verschlüsselung ist ein Schlüssel erforderlich, der ebenfalls irgendwo gespeichert werden muss, und ich hoffe, dass niemand ihn findet. In jedem Fall ist die Schlüsselgenerierung und -verwaltung eine separate Geschichte (sie sollten nicht schwach sein, sie müssen regelmäßig geändert werden usw.).
- Die Möglichkeit eines Konflikts. Bei der Verschlüsselung ist auch die Ausgabe von verschiedenen Eingabedaten immer unterschiedlich. Beim Hashing ist dies nicht immer der Fall. Eine konstante Hash-Länge bedeutet, dass der Satz von Ausgabewerten der Hash-Funktion begrenzt ist, was zu einer Kollision führt. Nehmen wir an, der Benutzer war wirklich verwirrt und hat sich ein wirklich cooles langes Passwort ausgedacht, das Sonderzeichen, Zahlen und Buchstaben in Klein- und Großbuchstaben enthält. Der Angreifer gibt das nicht weniger coole Passwort "admin" in das Passwortfeld ein. Der Server hat es gehasht, um Hashes zu überprüfen und zu vergleichen. Hashes abgestimmt. Es ist eine Schande.
Mit einer Punktzahl von 3: 1 gewinnt das Hashing. Aber ist es möglich, dort anzuhalten?
Die Antwort ist nein.
Hashed Password Attacks
Also bekam der Angreifer unsere Tabelle mit Benutzernamen und Passwörtern. Passwörter werden jetzt gehasht, aber dies hält unseren Angreifer nicht auf und er beabsichtigt ernsthaft, sie wiederherzustellen. Seine möglichen Aktionen:
- dictionary bruteforce: Wenn der Angreifer mit dem Referenzkennwort des Administrators keinen Erfolg hatte, greift er zum Wörterbuch der gängigen Kennwörter und versucht sein Glück mit deren Hashes.
- Regenbogentabellen: Im Allgemeinen muss er heute vielleicht nichts berechnen und das Wörterbuch sortieren. Es wird ausreichen, sich an die im Netzwerk liegenden Regenbogentische zu wenden. Regenbogentabellen enthalten Hash-Werte, die bereits zuvor von jemandem berechnet wurden, und die entsprechenden Eingabedaten. Es ist wichtig zu beachten, dass aufgrund von Kollisionen das Kennwort, das die Regenbogentabelle bietet, nicht unbedingt das Kennwort ist, das der Benutzer verwendet. Die berechneten Werte gelten bereits für MD5, SHA1, SHA256, SHA512 sowie für deren Modifikationen und einige andere. Sie können beispielsweise hier versuchen, den Hash umzukehren.
- Umfassende Suche: Wenn dies nicht hilft, müssen Sie auf Brute Force zurückgreifen und alle möglichen Passwörter hintereinander durchlaufen, bis die berechneten Hashes endgültig übereinstimmen.
Im allgemeinsten Fall muss ein Angreifer Passwörter knacken. Und hier hängt sein Erfolg unter anderem von der Geschwindigkeit ab, mit der die Hash-Funktion berechnet wird. Einen Vergleich der Zeit der Hashes finden Sie
hier . Beispielsweise wurden Java-implementierte Hash-Funktionen unter 64-Bit-Windows 10 mit 1 Core Intel i7 2,60 GHz und 16 GB RAM millionenfach ausgeführt, um einen 36-Zeichen-Hash zu berechnen. Sie zeigten die folgenden Ergebnisse:
MD5 - 627 ms
SHA-1 - 604 ms
SHA-256 - 739 ms
SHA-512 - 1056 ms
Heute kann Bruteforce auf der GPU (sowie auf APU, DSP und FPGA) parallelisiert und um ein Vielfaches schneller ausgeführt werden. Zusätzlich zur Auswahl eines längeren Algorithmus und einer längeren Ausgabe können Sie jedoch noch etwas anderes tun.
Hash Hash
Um zu verhindern, dass ein Angreifer vorgefertigte Regenbogentabellen verwendet, gibt es eine Technik, mit der ein Kennwort mehrmals gehasht werden kann. Das heißt, wir berechnen den Hash aus dem Hash aus dem Hash aus dem Hash ... und so n-mal (es ist jedoch notwendig, sich nicht zu sehr darauf einzulassen, da der Server dies auch während der regelmäßigen Überprüfung des Benutzerpassworts tun muss). Jetzt ist es laut Regenbogentabelle so einfach, dass er das Passwort nicht findet und die Zeit für rohe Gewalt erheblich länger wird. Nichts hindert den Angreifer jedoch daran, eine Regenbogentabelle aus dem Kennwortwörterbuch zu generieren, wenn er den Hashing-Algorithmus kennt. Darüber hinaus wurden für die beliebtesten Kombinationen dieser Methode bereits solche Tabellen generiert:
""
Nach Geschmack Salz hinzufügen
Damit er dies nicht tun konnte, werden heute Passwörter mit Salzzusatz gehasht.
Ein Salt ist eine zusätzliche zufällige Zeichenfolge, die einem Kennwort zugewiesen und damit gehasht wird. Sie können das Passwort nicht aus dem so erhaltenen Hash aus der Regenbogentabelle wiederherstellen. Wenn der Angreifer das Salz und den Ausgabe-Hash kennt, ist er zu brutaler Gewalt verurteilt, und keine vorberechneten Tabellen werden ihm höchstwahrscheinlich helfen.
Passwort-Salztaxonomie:
1. Nach dem Prinzip des Salzens:
- Ein einzigartiges Salz für jeden Benutzer: Individuell für jeden Benutzer. Auf diese Weise muss jedes Passwort gelöscht werden, wenn das Salz dem Angreifer bekannt wird. Und selbst wenn zwei Benutzer gleich denken und identische Passwörter finden, sind die Hashes in der Ausgabe immer noch unterschiedlich.
- globales Salz: für alle gleich, für alle Hashes verwendet;
- beide.
2. Nach der Art der Salzlagerung:
- in der Datenbank: In der Regel werden einzelne Salze in derselben Datenbank gespeichert wie Passwort-Hashes; oft sogar auf derselben Linie;
- im Code (lesen: in der Konfiguration): Das globale Salt wird normalerweise nicht in der Datenbank gespeichert, sondern beispielsweise in der Konfiguration, so dass der Übertreter Zeit für seine Auswahl aufwenden müsste.
Wir gehen davon aus, dass die einzelnen Benutzersalze in der Datenbank gespeichert sind, das globale Salz in der Konfiguration. Der Angreifer hat Zugriff auf die Datenbank erhalten und kennt alle Hashes und die entsprechenden Salze (das globale Salz ist nicht in der Datenbank gespeichert und er kennt es nicht). Wenn alle Methoden kombiniert werden, um Passwörter in klarer Form zu erhalten, wie dies bei den ersten Systemen der Fall war, stößt er als äußerst zielstrebig auf die folgenden Hindernisse:
- Er kennt das globale Salz nicht, deshalb muss es brutalisiert werden.
- Er kennt die Salze der Benutzer, hat jedoch keine Tabellen mit diesen Salzen vorbereitet, sodass er Passwörter knacken muss.
- Dieser Vorgang dauert noch länger, da Sie n-mal Hashes ausführen müssen.
Wie speichern Passwörter verschiedene CMS?
Wordpress
Vor Version 3.x wurden Passwörter einfach mit MD5 gehasht. Jetzt wird die Phpass-Bibliothek verwendet. Standardmäßig wird dem vorangestellten Kennwort Salt zugewiesen und die resultierende Zeichenfolge wird 2 ^ 8 Mal mit MD5 gehasht.
Joomla
Vor Version 1.0.12 wurde nur MD5 verwendet. Die Phpass-Bibliothek wird standardmäßig mit Salz und 2 ^ 10 Wiederholungen bcrypt verwendet.
Drupal
Bis zur Version 6 md5 ohne Salz. Die Phpass-Bibliothek wird verwendet. Die Standardeinstellung ist gesalzen sha512 mit 2 ^ 16 Wiederholungen.
Silberstreifen
Verwendet salzigen Blowfish mit 2 ^ 10 Wiederholungen.
Umbraco
Verwendet HMACSHA256 mit Salz. Verwendet das zweite in der Konfiguration angegebene globale Salt.