Have You Been Pwned? Neue Sicherheitsfunktion, um die Nutzung geleakter Passwörter zu verhindern

Während wir auf die Version v4.6 LTS von Ibexa DXP warten, wollen wir einen Blick auf eine nützliche Funktion werfen, die im Mai mit der Version v4.5 eingeführt wurde.

Passwort-Leaks

Immer wieder kommt es zu Passwort-Leaks. Manchmal haben Angreifer es auf bestimmte Benutzer abgesehen, aber meistens wird eine Schwachstelle in einer Software oder einem Dienst ausgenutzt, um große Mengen an Benutzerdaten abzugreifen, darunter bisweilen auch Passwort-Hashes. In schlecht konzipierten Systemen könnten Passörter sogar im Klartext geleakt werden. Solche Passwortsammlungen ("Dumps“) werden dann gewinnbringend verkauft. Die Käufer versuchen, aus den Benutzerdaten Profit zu schlagen, beispielsweise durch Lösegeld-Angriffe, Phishing oder andere Straftaten. Diese Angriffe werden zusätzlich dadurch erleichtert, dass Benutzer oft dasselbe Passwort für verschiedene Dienste verwenden. Was können wir also tun, um unsere Benutzer zu schützen?

Nicht selten werden auf einen Schlag Hunderte Millionen von Benutzerdaten abgegriffen. Die Betreiber der Dienste müssen ihre eigenen Benutzer natürlich über den Vorfall informieren. Die Datenschutz-Grundverordnung (DSGVO) der EU sieht hohe Geldstrafen für Unternehmen vor, die das nicht tun. Aber selbst wenn Benutzer informiert werden: Handeln Sie dann richtig und ändern das geleakte Passwort auf allen Diensten, bei denen sie es verwendet haben? Nicht immer, und das macht sie anfällig für weitere Angriffe.

Rettung durch „gute“ Hacker

Die positive Nachricht zu diesen Datenlecks: Letztendlich landen sie in öffentlichen Foren, wo auch Nichtkriminelle, die Nutzern helfen wollen, Zugriff auf die Daten erhalten. Einer dieser „Guten“ ist Troy Hunt von Microsoft, der den Dienst https://haveibeenpwned.com eingerichtet hat. Dort kann jeder nach geleakten Benutzernamen und Passwort-Hashes suchen. Und was soll daran jetzt gut sein, werden Sie sich vielleicht fragen? Nun, zum einen können Sie mit Ihrer eigenen E-Mail-Adresse nachschauen, ob Ihre Daten abgegriffen wurden und wo das der Fall war. Das ist sicherlich nützlich für alle, die wissen, dass dies möglich ist. Die API kann aber noch mehr: Sie hilft auch allen, die sich mit der Sicherheit von Passwörtern nicht auskennen.

Mit Hilfe der API können wir als Website-Betreiber überprüfen, ob das Passwort schon einmal gestohlen wurde, wenn ein Benutzer ein neues Konto auf unserer Seite erstellt oder sein Passwort ändert. Bestehende Passwörter können wir nicht überprüfen, da wir sie nicht haben; wir haben nur die Hashes. Wir könnten das Passwort auch jedes Mal überprüfen, wenn sich Benutzer anmelden, aber das würde zu vielen unnötigen API-Anfragen für dieselben Passwörter führen. Wir sind es Troy Hunt schuldig, dass wir seinen Dienst effizient nutzen.

Passwortprüfung in Ibexa DXP

Symfony hat die haveibeenpwned-API als NotCompromisedPassword-Constraint implementiert, der wie jede andere Einschränkung in einem Validator verwendet werden kann. Wir nutzen diesen Constraint als konfigurierbare Passwortvalidierungsregel in Ibexa DXP. Seit der Version v4.5 steht er Ihnen zur Verfügung.

Um Überraschungen beim Upgrade zu vermeiden, ist diese neue Passwortregel standardmäßig nicht aktiviert. Aber die Aktivierung ist ganz einfach: Bearbeiten Sie im DXP-Backend den Inhaltstyp User. Erweitern Sie die Details für die Felddefinition des User Accounts- Aktivieren Sie das Kontrollkästchen "Password must not be contained in a public breach" und speichern Sie den Inhaltstyp. Das war‘s schon!

Bei dieser Gelegenheit sollten Sie vielleicht auch die anderen Einstellungen zu den Passwortregeln in Betracht ziehen. Zu diesem Thema habe bereits etwas im Blog-Beitrag Security Checklist geschrieben – dort im Abschnitt "Login and user information“.

Aber ist es sicher, Passwörter an eine externe API zu senden?

Nein! Deshalb machen wir das auch nicht. Wie das Ganze funktioniert, ist ziemlich clever. Schauen wir uns das einmal an: Auf den ersten Blick könnte man denken, es gibt nur zwei Möglichkeiten, diese Überprüfung durchzuführen: Wir senden das Kennwort (oder einen Hash davon) an die API, die prüft, ob es in ihrer Datenbank existiert, und eine Ja/Nein-Antwort zurückgibt. Troy Hunt ist sicher ein anständiger Kerl, aber soweit sollten wir ihm und seinem Dienst nun auch nicht vertrauen.

Alternativ könnten wir die gesamte Datenbank von seinen Servern herunterladen, sie auf unserem Server installieren und sie jedes Mal durchsuchen, wenn wir ein Passwort überprüfen wollen. Das würde viel Zeit und Speicherplatz beanspruchen, und natürlich müssten wir die Datenbank immer wieder aktualisieren. Tatsächlich dürfen wir sie herunterladen, aber das wollen wir gar nicht. Welche andere Möglichkeit könnte es also geben?

Die Lösung: k-Anonymität

Diese clevere Lösung ist ein Mittelding zwischen den beiden oben genannten Optionen. Wir erstellen einen Hash des zu prüfenden Kennworts mit demselben Algorithmus, den auch die API verwendet. Wir nehmen dann die ersten fünf Zeichen (also einen Bruchteil) des Hashes und verwenden sie als Eingabe für eine Bereichsabfrage an die API. Die API durchsucht ihre Datenbank und liefert eine Liste aller Hashes, die mit denselben fünf Zeichen beginnen. Das sind etwa 800 bis 1.000 Einträge.

Diese kurze Liste durchsuchen wir dann ganz schnell lokal. Wenn unser Passwort-Hash in dieser Liste auftaucht, wird das Passwort als ungültig abgelehnt. Dem Benutzer wird dann mitgeteilt, dass es von einem Leak betroffen ist. Steht es nicht auf der Liste, ist alles in Ordnung. Wichtig ist, dass die API das Ergebnis nie erfährt. Sie weiß nur, dass unser Passwort entweder in der zurückgespielten Liste von ca. 1.000 Einträgen enthalten ist (in diesem Fall lehnen wir es ab) oder gar nicht in der Datenbank vorhanden ist. Und sie kennt die ersten fünf Zeichen des Hashes. Angesichts der Länge und Eigenschaften des Hashes lässt sich diese Information aber nicht für böswilligen Zwecke nutzen.

Dieser Algorithmus leitet sich vom mathematischen Konzept der k-Anonymität ab. Es kommt beispielsweise auch in medizinischer Forschung bei anonymisierten Patientenakten zum Einsatz. Der Datensatz ist k-anonym, wenn es für jeden Datensatz k - 1 weitere identische Datensätze gibt. In unserem Fall sind es etwa 800 bis 1.000 Einträge, und nur wir wissen, ob unser Passwort dazugehört. Weitere Informationen hierzu finden Sie in einem ausgezeichneten Beitrag im Cloudflare-Blog: Validating Leaked Passwords with k-Anonymity, von Junade Ali.

Wir hoffen also, dass Sie diese Funktion aktivieren. Sie haben nichts zu verlieren, und Ihre Benutzer werden sehr davon profitieren.