Überprüfung von Kennworten über HIBP ("Have I Been Pwned")*

Wir bieten unseren Nutzern an, Kennworte mit den bei "Have I Been Pwned" gelisteten kompromittierten Kennworten abgleichen zu lassen.

Dies geschieht aber nur, wenn ein Benutzer dies explizit wünscht.

Für den Abgleich wird ein SHA-1-Hash des Kennworts gebildet. Die ersten 20 Bits (von 160 Bits) werden an HIBP gesendet, woraufhin HIBP eine Liste aller Hashes kompromittierter Kennworte mit den Zahlen ihrer Entdeckungen bei Datenlecks zurücksendet. key.matique vergleicht dann den vollständigen Hash des in Frage stehenden Kennworts mit dieser Liste und teilt dem Benutzer das Resultat mit.

Das dahinterstehende Model ist das der k-Anonymität

Risiken

Natürlich haben wir uns gefragt, ob es nicht ein Risiko darstellt, an einen Dritten, dessen Sicherheitsmaßnahmen wir nicht kontrollieren können, auch nur einen Teil des Hashes zu übermitteln.

Falls z. B. ein Geheimdienst vollen Zugriff auf HIBP hat, und gleichzeitig mitschneidet, wer sich zu key.matique verbunden hat, könnte er die Anfrage an HIBP mit den Metadaten über key.matique verknüpfen und evtl. folgende Information daraus gewinnen: Der Nutzer mit der IP-Adresse x hat mit Wahrscheinlichkeit y ein Kennwort bei HIBP überprüfen lassen, dessen SHA-1-Hash in den ersten 20 Bits den Wert z hat.

Wenn der Geheimdienst nun z. B. über ein Botnet einen Brute-Force-Angriff basierend auf Wörterbüchern gegen die Konten des key.matique-Users fährt, könnte er alle diejenigen Angriffe vorab aussortieren, bei denen die ersten 20 Bits des SHA-1-Hashes nicht mit dem Wert z übereinstimmen.

Im Durchschnitt dürfte es darauf hinauslaufen, dass in diesem Fall weniger Versuche nötig sind, d. h. das Kennwort hier effektiv ca. 1/8 (20/160) der Stärke eingebüßt hat.

Sind z. B. ohne Kenntnis des Werts z im Mittel 1.000.000 Versuche nötig, entspricht dies einer Kennwortstärke von 21 Bit. (D. h. das Kennwort stammt aus einem Namensraum von 2.000.000 Wörtern und im Mittel muss die Hälfte abgefragt werden, um einen Treffer zu erzielen.) Die Kenntnis von z erlaubt nun diesen Namensraum auf 326.000 Wörter zu reduzieren so dass im Mittel nur noch 163.000 Versuche nötig sind. Dies entspricht einer Kennwortstärke von nun nur noch 18,3 Bit. Und der Aufwand, es durch Brute Force zu knacken, beträgt nur noch knapp ein Sechstel des ursprünglichen Aufwands.

Vorteile

Gegen die Risiken sollten die Vorteile der Überprüfung abgewogen werden. Der Benutzer kann lernen, welche Kennworte typischerweise sicher sind und welche z. B. von anderen Benutzern sehr oft verwendet werden und daher über Wörterbuch-Angriffe schnell geknackt werden können.

Abwägung

Für die Abwägung spielt eine Rolle, dass der Benutzer nicht verpflichtet ist, jedes Kennwort mit HIBP abzugleichen, oder auch abgeglichene Kennworte überhaupt zu verwenden.

Wenn er zum Beispiel seine gewonnene Erfahrung, dass ein bestimmtes Kennwort nicht bei HIBP gelistet ist, nutzt, um ein ähnlich komplexes Kennwort, das aber nicht mit HIBP abgeglichen wird, aufzubauen, so kann selbst in dem oben beschriebenen fiktiven Szenario der Geheimdienst keinerlei Nutzen aus dem Abgleich ziehen.

Schließlich ist das fiktive Szenario ein Worst-Case-Szenario:

HIBP wird in Australien und nicht in den USA betrieben, unterliegt also nicht der berüchtigten US-Geheim-Justiz, die nicht nur bestimmen kann, dass Internet-Plattformen Geheimnisse an die NSA auszuliefern haben, sondern dass darüber auch noch Stillschweigen zu wahren ist.

Der gewonnene Wert z kann nur genutzt werden, wenn er mit weiteren Angriffen (im Szenario ein 160.000-facher Botnet-Angriff) kombiniert wird. Ein entsprechend großer Angriff würde bei key.matique leicht entdeckt (durch die Angriffsstatistik) und abgewehrt (durch die Zwei-Faktor-Authentisierung).

Natürlich kann es sein, dass der Botnet-Angriff auf andere Konten des Benutzers (bei anderen Betreibern) gefahren wird, die nicht so gut geschützt sind. Aber key.matique empfieht ja den Benutzern, in aller Regel generierte, sehr starke Kennworte zu verwenden, so dass nur wenige Passworte übrig bleiben, die merkbar bleiben müssen und daher überhaupt gegen Brute-Force-Angriffe anfällig sind.

In der Abwägung kommen wir daher zu dem Schluss, dass ein überlegter Einsatz des Abgleichs mit HIBP mehr Vorteile als Nachteile bringt und im Saldo zu höherer Sicherheit führt.

Einsatz von SHA-1

Spontan kann man über den Einsatz von SHA-1 irritiert sein, gilt dieser Algorithmus doch nach den bekannten Verletzlichkeiten gegenüber Kollisionsangriffen als obsolet.

Doch dürften die Schwächen von SHA-1 in diesem Fall keine große Rolle spielen. Diese sind wichtig wenn es darum geht, ob mit SHA-1 digital signierte Dokumente verfälscht werden können (was mit beträchtlichem Aufwand möglich ist). Aber es ist ja unwichtig, ob weitere Kennworte mit dem gleichen SHA-1-Hash konstruiert werden können, wenn erst einmal ein kompromittiertes Kennwort mit diesem Hash vorliegt.

Wichtig ist lediglich, ob die Hashes einigermaßen gleichverteilt sind und wir erwarten können, dass bei Kenntnis von einem Achtel des Hashes das dahinterstehende Kennwort auch in etwa nur ein Achtel seiner Stärke eingebüßt hat. Der Kommentar von Pierre D ("@Dajrid It's important not to confound accidential hash collision and adversarial collision hunting ...") in stackoverflow.com legt nahe, dass die Gleichverteilung einigermaßen gegeben ist, wenn auch nicht perfekt.

*) Hinweise zu Marken Drit­ter:

"Have I Been Pwned?" und "HIBP" scheinen Warenzeichen von Troy Hunt zu sein.