Mittwoch, 17. August 2011


Topthema

Donnerstag, 24. September 2009 | Topthema

About Security #223: Schwachstellen-Suche: Authentifizierung - Passwort-Reset (2)

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/051453)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

In About Security #222 wurden unsichere Möglichkeiten beschrieben, um dem Benutzer ein neues Passwort zukommen zu lassen oder ihm ohne Passwort Zugriff auf die Webanwendung zu gewähren.

Unsicherer geht immer

Diese Möglichkeiten, bei denen ein Benutzer nach dem Bestehen des Challenge-Response-Verfahrens mehr oder weniger sofort Zugriff auf die Webanwendung erhält, werden noch unsicherer, wenn keine E-Mail mit einer Benachrichtigung über den erfolgreichen Reset des Passworts an die gespeicherte E-Mail-Adresse geschickt wird. Der Angreifer hat dann solange ungestörten Zugriff auf das betroffene Benutzerkonto, bis sich der Benutzer das nächste Mal selbst anmelden möchte und das mit seinem nun falschen Passwort nicht gelingt. Erst dann wird er merken, dass irgend etwas nicht stimmt, und den Betreiber der Webanwendung informieren. Sofern er nicht denkt, er hätte das Passwort vergessen, und es nun selbst über die "Vergessenes Passwort"-Funktion zurück setzt. In dem Fall könnten Angreifer und Benutzer bis in alle Ewigkeit immer wieder abwechselnd das Passwort zurück setzen, um Zugriff auf die Webanwendung erlangen.

Eine sichere Lösung

Eine sichere Lösung besteht z.B. darin, dem Benutzer an die gespeicherte E-Mail-Adresse einen eindeutigen, nicht erratbaren und nur kurze Zeit gültigen URL zu schicken, bei dessen Aufruf innerhalb der Gültigkeitsdauer der Benutzer auf eine Seite gelangt, auf der er ein neues Passwort eingeben kann.

Die Verwendung der gespeicherten E-Mail-Adresse sorgt dafür, dass der Angreifer nicht seine eigene Adresse angeben kann. Um an diese E-Mail zu gelangen, müsste er also entweder Zugriff auf den Mail-Account seines Opfers haben oder die E-Mail im Rahmen eines Man-in-the-Middle-Angriffs abfangen.

Der URL muss eindeutig und nicht erratbar sein, damit der Angreifer sie nicht selbst berechnen und dann vor dem Benutzer nutzen kann. Ansonsten könnte er so lange Zugriff auf das Benutzerkonto erlangen, bis der Benutzer auf die ihm unverlangt zugesandte Mail reagiert. Der URL darf nur kurze Zeit gültig sein, damit eine irgendwann in falsche Hände gelangende URL nicht erneut verwendet werden kann. Da sich alle notwendigen Parameter in der URL befinden, werden sie auch in Logfiles oder der Browser-History gespeichert, wo sie ausgespäht werden können.

Statt eines URLs könnte auch ein zufällig erzeugtes, nur zum einmaligen Gebrauch innerhalb des Gültigkeitszeitraum vorgesehenes Passwort verschickt werden. Nachdem der Benutzer sich damit eingeloggt hat, würde er dann zum Setzen eines neuen Passworts gezwungen. Dieser Ansatz hat den Vorteil, dass keine Spuren in Logfiles oder der Browser-History zurück bleiben.

Der Versand des aktuellen Passworts in einer unverschlüsselten E-Mail ist unsicher, es würde ja auch niemand die Onlinebanking-PIN auf einer Postkarte verschicken.

"Vergessenes Passwort"-Funktion testen

Bei der Schwachstellensuche in der eigenen Webanwendung kann sich das Testen im wesentlichen auf einen Vergleich der vorhandenen Funktion mit den in About Security #222 und dieser Folge beschriebenen Schwachpunkten beschränken. Ggf. muss noch die Funktion zum Erzeugen der zufälligen URL oder des neuen Passworts auf mögliche Schwachstellen untersucht werden.

About Security: Die komplette Serie

Anders sieht es bei einem Black-Box-Test aus. Zuerst wird dann geprüft, ob sich über die "Vergessenes Passwort"-Funktion gültige Benutzernamen ermitteln lassen oder ob Brute-Force-Angriffe möglich sind. Danach wird die "Vergessenes Passwort"-Funktion selbst untersucht. Um ihre Funktionsweise zu ermitteln, muss sie zuerst einmal komplett mit einem vom Tester kontrollierten Benutzerkonto durchlaufen werden.

Wird ein Challenge-Response-Verfahren zur Identifizierung des Benutzers verwendet, muss ermittelt werden, ob die Benutzer eigene Challenges wie z.B. eine Sicherheitsfrage bestimmen oder aus einer Menge vorgegebener Challenges eine aussuchen können. Können die Benutzer die Challenge wählen, kann ein Angreifer mit Hilfe einer Liste ermittelter oder typischer Benutzernamen eine Liste zugehöriger Challenges erstellen, aus denen dann die am leichtesten erratbaren ausgewählt werden können.

Gibt die Funktion einen Hinweis auf das aktuelle Passwort aus, wird ebenso vorgegangen: Mit Hilfe einer Liste ermittelter oder typischer Benutzernamen wird eine Liste zugehöriger Passwort-Hinweise erstellt und die auf einfach erratbare Lösungen untersucht.

Wurde das Challenge-Response-Verfahren erfolgreich gebrochen, gibt es mehrere Möglichkeiten: Kann sofort ein neues Passwort gesetzt werden oder wird sofort eine neue Session gestartet, ist das Verfahren unsicher und sollte ersetzt werden.

Verschickt die "Vergessenes Passwort"-Funktion eine E-Mail mit einem Recovery-URL oder einem temporären Passwort, ist die Zieladresse wichtig. Wird die Mail an eine in der Funktion eingegebene E-Mail-Adresse geschickt, ist das Verfahren sofort unsicher, statt dessen muss die gespeicherte E-Mail-Adresse verwendet werden.

Wird die E-Mail an die gespeicherte Adresse gesendet, wird die Funktion mehrmals, am besten auch für unterschiedliche Benutzerkonten, ausgelöst und die dabei gesammelten Passwörter bzw. URLs auf erkennbare Muster untersucht (wie Passwörter, Session-Tokens und ähnliche Werte untersucht werden, wird in einer zukünftigen Folge beschrieben). Ist ein Muster erkennbar, muss dieser Teil der Funktion ersetzt werden.

Sofern die Funktion nicht sowieso eine E-MailL an die gespeicherte E-Mail-Adresse schickt (was sehr zu empfehlen ist), sondern dem Benutzer nach dem Bestehen des Challenge-Response-Verfahrens sofort Zugang zur Webanwendung gewährt, muss zumindest eine E-Mail an die gespeicherte Adresse geschickt werden, in der der Benutzer über die erfolgreiche Durchführung des Passwort-Resets informiert wird. Dabei muss die zuvor gespeicherte E-Mail-Adresse verwendet werden, keinesfalls eine nach dem Auslösen der "Vergessenes Passwort"-Funktion eingegebene. Ansonsten kann ein erfolgreicher Eindringling die Adresse gegen eine unter seiner Kontrolle stehende austauschen.

In der nächsten Folge geht es um weitere mögliche Schwachstellen in der Authentifizierung: Die "Remember me"-Option mancher Webanwendungen.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren