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

Wir bieten unseren Nutzer*innen an, Kennworte mit den bei "Have I been pwned" gelisteten kompromittierten Kennworten abgleichen zu lassen.

Dies geschieht aber nur, wenn eine Benutzer*in 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.matiq vergleicht dann den vollständigen Hash des in Frage stehenden Kennworts mit dieser Liste und teilt der Benutzer*in das Resultat mit.

Das dahinterstehende Model ist das der k-Anonymität.

Wir bilden den Hash per JavaScript im Browser und senden die Anfrage direkt an den HIBP-Server. Jedenfalls Überall dort, wo der Cautiously Knowing Service bereits implementiert ist. Dass ist in der expliziten Abfrage unter "Extras > HIBP" und auch beim Ändern des Hauptkennworts bereits der Fall.

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.matiq verbunden hat, könnte er die Anfrage an HIBP mit den Metadaten über key.matiq verknüpfen und evtl. folgende Information daraus gewinnen: Die Nutzer*in 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 der key.matiq-User*in 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 Passwortstä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 Passwortstä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. Die Benutzer*in kann lernen, welche Kennworte typischerweise sicher sind und welche z. B. von anderen Benutzer*innen 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 die Benutzer*in nicht verpflichtet ist, jedes Kennwort mit HIBP abzugleichen, oder auch abgeglichene Kennworte überhaupt zu verwenden.

Wenn sie zum Beispiel ihre 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.matiq leicht entdeckt (durch die Angriffsstatistik) und abgewehrt (durch die Zwei-Faktor-Authentisierung).

Natürlich kann es sein, dass der Botnet-Angriff auf andere Konten der Benutzer*in (bei anderen Betreiber*innen) gefahren wird, die nicht so gut geschützt sind. Aber key.matiq empfieht ja den Benutzer*innen, in aller Regel generierte, sehr starke Kennworte zu verwenden, so dass nur wenige Passwörter ü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.

Keine Abspeicherung des Hashes!

Wichtig ist, dass der Hash nur kurzzeitig gebildet, nur zum kleinen Teil an den HIPB-Server gesandt wird und nach der Prüfung sofort wieder gelöscht wird. Der Hash wird auf kein Speichermedium geschrieben. Und bei voller Implementation des Cautiously Knowing Service geschieht die Bildung und Überprüfung des Hashes auch im Client und nicht mehr auf der Server.

Denn: Ein vollständiger Hash könnte für Angriffe genutzt werden. Kurze Kennworte könnten systematisch ausprobiert werden, da die Rechenzeit für einen einfachen Hash kurz ist (im Gegensatz zu mit Schlüsselstreckung berechneten Prüfwerten). Wenn eine Folge von Buchstaben, Ziffern und Sonderzeichen gefunden wird, die zum Hash passt, so wäre die Chance für die Angreifer*in gut, den Klartext ermittelt zu haben. Kurze Kennworte, die noch gar nicht in der HIBP-Datenbank vorhanden sind, könnten auf diese Weise kompromittiert werden. Dies gilt es natürlich zu verhindern.