Ja, der String-Vergleich (und/oder Index-Lookup) kann grundsätzlich preisgeben, wie viele identische führende Bytes der in der Datenbank gespeicherte Passwort-Hash und der aus dem eingegebenen Passwort berechnete Anteil sind.
Im Prinzip könnte ein Angreifer damit iterativ ein Präfix des Passwort-Hashs lernen, Byte für Byte:Zuerst findet er einen Hash, der sein erstes Byte mit dem Hash in der Datenbank teilt, dann einen, der seine ersten zwei
Nein, das spielt mit ziemlicher Sicherheit keine Rolle.
Wieso den? Nun, aus mehreren Gründen:
-
Ein Timing-Angriff kann dem Angreifer ermöglichen, einen Teil des Passwort-Hashes des Benutzers zu erfahren. Ein gut gestaltetes Passwort-Hashing-Schema (unter Verwendung von Salt und key stretching ). ), sollte jedoch sicher bleiben (vorausgesetzt natürlich, dass die Passwörter selbst nicht leicht zu erraten sind), selbst wenn der Angreifer das gesamte kennt Passwort-Hash. Somit sind selbst wenn der Timing-Angriff erfolgreich ist, die Passwörter selbst sicher.
-
Zur Durchführung des Angriffs muss der Angreifer Passwörter übermitteln, deren Hashwert ihm bekannt ist. Der Hash-Wert hängt vom Salz ab. Daher ist dieser Angriff nicht möglich, es sei denn, der Angreifer kennt das Salt irgendwie schon.
(Es stimmt, dass bei den meisten Sicherheitsanalysen von Passwort-Hashing-Schemata davon ausgegangen wird, dass es sich bei dem Salt um öffentliche Informationen handelt. Dies liegt jedoch nur daran, dass solche Analysen vom oben erwähnten Worst-Case-Szenario ausgehen, bei dem der Angreifer bereits eine Kopie davon erhalten hat die gesamte Benutzerdatenbank, Salts und Hashes und all das. Wenn der Angreifer den Hash noch nicht kennt, gibt es keinen Grund anzunehmen, dass er den Salt kennt.)
-
Selbst wenn der Angreifer das Salt kennt, muss er, um den oben beschriebenen iterativen Angriff durchzuführen, Passwörter generieren, die zu einem Wert mit einem gewünschten Präfix gehasht werden. Für jede sichere Hash-Funktion besteht die einzige praktische Möglichkeit darin, einen Fehler auszuprobieren, was bedeutet, dass die dafür benötigte Zeit exponentiell mit der Länge des Präfixes skaliert.
In der Praxis bedeutet dies, dass, um ausreichend viele Bits des Hashs zu extrahieren, um einen Offline-Brute-Force-Angriff darauf durchführen zu können (was nicht alle sein müssen; nur mehr als die effektive Menge an Entropie in der Passwort), muss der Angreifer etwa so viel Rechenarbeit leisten, wie nötig ist, um das Passwort selbst zu knacken. Für ein gut gestaltetes Passwort-Hashing-Schema und ein sicher gewähltes Passwort ist dies nicht machbar.
-
Was der iterative Angriff kann dem Angreifer im Prinzip die Möglichkeit geben, den größten Teil der Brute-Force-Berechnung lokal an seinem Ende durchzuführen, während nur eine relativ kleine Anzahl von Passwörtern an Ihr System übermittelt wird. Aber auch das gilt nur, wenn sie von jedem detaillierte und verlässliche Zeitinformationen zurückerhalten Passwort übermittelt. In der Praxis sind Real-Timing-Angriffe extrem ineffizient , und erfordern viele (oft Tausende oder Millionen) Abfragen, um beliebig zu erhalten überhaupt nützliche Informationen. Dies wird sehr wahrscheinlich alle potenziellen Leistungsvorteile aufheben, die der Timing-Angriff dem Angreifer verschaffen könnte.
Dieser Punkt wird verstärkt, wenn Sie ein geeignetes Key-Stretching-Passwort-Hashing-Schema verwenden, da solche Schemata absichtlich so konzipiert sind, dass sie langsam sind. Daher wird der String-Vergleich in der Datenbank im Vergleich zum Hashing des Passworts an erster Stelle wahrscheinlich nur eine vernachlässigbare Zeit in Anspruch nehmen, und alle dadurch verursachten Timing-Variationen gehen daher im Rauschen unter.
