Finding: Wenn sich die Passwort-Validierung «verschluckt»

Ein Security Researcher stiess auf einen Fehler bei der Passworteingabe, der zu einer Überlastung führen konnte. Theoretisch. Leider für den Researcher war seine Meldung ein «False Positive». Dennoch gabs eine Anerkennung vom Team, da durch seine Meldung eine andere Schwachstelle identifiziert werden konnte.

Von Daniel Scherrer, Chief Software Architect · 15. Dezember 2022

Manchmal sind die Passwörter viel zu lange... (Bild: Regularguy.eth/Unsplash)

Mit den Passwörtern ist das so eine Sache. Niemand liebt sie. Sie müssen nämlich lang und komplex sein. Dann sind sie am sichersten.

Das Finding

Ein Security Researcher dachte sich das auch und generierte einfach mal so ein extrem langes und extrem komplexes Passwort für seinen Account im Testsystem des Ergebnisermittlungssystems der Kantone St. Gallen und Thurgau. Zu seiner Überraschung klappte der Passwortwechsel. So weit so gut.

Das Problem dahinter: Auf dem Server wurde die Länge des Passworts nicht korrekt geprüft. Aufgrund der Verwendung eines bestimmten Hashalgorithmus, der nur Passwörter in der maximalen Grösse von 72 Bytes verarbeitet (das sind normalerweise etwas mehr als 60 Zeichen), erzeugte dies eine potenzielle Schwachstelle in der Passwortkomplexität – jedoch nicht wie vom Researcher angenommen eine mögliche DOS-Attacke auf den Hashberechnungsprozess.

Die Erkenntnis

Aufgrund der nicht vollständigen Server-Validierung wurden die ersten 72 Bytes im Passwort gespeichert und alle Folgezeichen verworfen. Dies führte zu einer potenziellen Schwächung des Passwortes, da möglicherweise die geforderte Komplexität erst nach den 72 Bytes im Passwort angewandt wird (Gross-/Kleinschreibung, Sonderzeichen etc.). Anders gesagt: Der abgespeicherte Passwordhash (die ersten 72 Bytes) können eine tiefere Komplexität als gefordert haben – eine unbewusste Umgehung der Passwortrichtlinie.

Das Verhalten konnte vom #TeamAbraxas nur reproduziert werden, wenn die Client-Validierung durch Client-Manipulationen deaktiviert wurde. Dennoch sollten Client- und Servervalidierungen korrekt aufeinander abgestimmt sein.

Die Lösung

Das #TeamAbraxas hat das Finding letztlich nach eingehender interner Diskussion im Sinne des Researchers umformuliert und sich für die Sicherheitsoptimierung des Ergebnisermittlungssystems erkenntlich gezeigt. Die Client- und Servervalidierungen sind nun besser aufeinander abgestimmt und die Länge des Passwortes auf den verwendeten Algorithmus.

Daniel Scherrer

Über Daniel Scherrer

Daniel Scherrer ist Chief Software Architect bei Abraxas. Er plant und entwickelt Software konsequent entlang bewährter und sicherer Methoden. Er leitet das Abraxas Bug-Bounty-Programm.