Freitag, 22. Oktober 2010


Topthema

Donnerstag, 17. September 2009 | Topthema

About Security #222: Schwachstellen-Suche: Authentifizierung - Passwort-Reset

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/051319)

Eine Webanwendung bietet ihren Benutzern mindestens zwei Möglichkeiten, ihr Passwort zu ändern (oder sollte sie zumindest bieten): Zum einen die in About Security #221 untersuchte Funktion zur Passwortänderung, zum anderen die Funktion, mit der ein vergessenes Passwort zurück gesetzt, bzw. mit der ein neues Passwort angefordert werden kann.

Vergessenes Passwort

Funktionen, mit denen eine vergessenes Passwort zurück gesetzt oder ein neues Passwort angefordert werden kann, enthalten oft die Schwachstellen, die bei der Anmeldefunktion umgangen wurden: Das Ermitteln gültiger Benutzernamen und Brute-Force-Angriffe. Da die Funktion ohne vorherige Authentifizierung erreichbar sein muss, fordert sie Angriffe darauf geradezu heraus. Daher dürfen Fehlermeldungen keinen Hinweis darauf geben, ob der eingegebene Benutzername gültig ist oder nicht, und sie darf auch nicht für einen Benutzernamen beliebig oft ausgeführt werden können.

Ein zusätzliches Problem sind Designschwachstellen, die einem Angreifer in die Hände spielen, indem sie die Nutzung der Funktion durch Unbefugte ermöglichen oder erleichtern.

Designfehler 1: Unsichere Sicherheitsfragen

Die "Vergessenes Passwort"-Funktion enthält i.A. eine Möglichkeit, den Benutzer auch ohne das Passwort zu identifizieren, meist mit einem Challenge-Response-Verfahren: Die Webanwendung fragt den Benutzer etwas, und der muss durch die richtige Antwort seine Identität beweisen. Am beliebtesten sind dabei vorgegebene Sicherheitsfragen, die manchmal auch "Geheime Fragen" genannt werden, obwohl sie es nicht sind. Fest vorgegebene Sicherheitsfragen sind ein großes Risiko, da die Antwort darauf meist leichter zu erraten ist als ein gutes Passwort. Man hat nun mal nur eine Mutter, deren Mädchennamen man angeben kann, nur ein erstes Haustier, nur einen Geburtsort, ... - und meist lassen sich die Antworten auf diese Fragen durch Social Engineering oder noch einfacher das Auswerten von Social Networks ermitteln. Lieblingsbuch, -autor, -film, -schauspieler oder -sänger? Ein Blick in Facebook und Co. genügt oft, um die Frage richtig beantworten zu können.

Auch wenn die Sicherheitsfrage vom Benutzer gewählt werden kann, wird sie dadurch meist nicht besser. Denn die Benutzer tendieren dazu, dann besonders einfache Fragen zu verwenden, wie "Wie heiße ich?" oder "Wann bin ich geboren?". Viele Benutzer denken sich nichts dabei, weil sie annehmen, dass sie die einzigen sind, die diese geheime Frage jemals zu sehen bekommen. Das ist aber ein Irrtum: Ein Angreifer kann einen Brute-Force-Angriff auf die "Vergessenes Passwort"-Funktion starten, indem er ermittelte oder übliche Benutzernamen ausprobiert und dann die auswählt, bei denen eine einfach zu ratende Sicherheitsfrage erscheint.

Unsichere Sicherheitsfragen wurden dieses Jahr schon öfter bemängelt, siehe dazu auch den Standpunkt Sicherheit vom 4. Mai 2009. Gute Beispiele für erfolgreiche Angriffe durch das richtige Beantworten von Sicherheitsfragen sind die Angriffe auf die E-Mail-Konten von Sarah Palin und Paris Hilton, siehe den Standpunkt Sicherheit vom 22. September 2008 und die Security-Hinweise vom 2. Juli 2009.

Designfehler 2: Passwort-Hinweise
About Security: Die komplette Serie

Manche Anwendungen implementieren die "Vergessenes Passwort"-Funktion, indem sie einem vom Benutzer während der Registrierung bzw. bei der Änderung des Passworts zu setzenden Hinweis auf das Passwort ausgeben. Selbst wenn die Anwendung dabei verhindert, dass der Hinweis einfach aus dem Passwort besteht, bleiben genug Möglichkeiten, einem Angreifer dadurch das Passwort zu verraten oder zumindest das Erraten zu erleichtern. Auch hierbei denken viele Benutzer, dass sie die einzigen sind, die diesen Hinweis zu sehen bekommen.

Designfehler 3: Die "Recovery-Funktion"

Nachdem die Benutzer die Sicherheitsfrage korrekt beantwortet haben oder eine andere Voraussetzung erfüllt haben, mit der sie sich ohne Passwort identifizieren können, muss das Passwort irgend wie auf einen neuen Wert gesetzt werden. Dafür gibt es verschiedene Möglichkeiten, die alle Raum für Designfehler lassen oder bereits selbst Designfehler sind:

  • Die direkte Ausgabe des Passworts, die direkte Möglichkeit, ein neues Passwort zu setzen oder die Einrichtung einer vollständigen Session sind extrem unsicher. Gelingt es einem Angreifer, die Sicherheitsfrage zu beantworten, hat er danach sofort Zugriff auf das Benutzerkonto.
  • Ebenso unsicher ist es, das vorhandene oder ein neues Passwort oder einen URL zur Passwortänderung an eine in der "Vergessenes Passwort"-Funktion eingegebene E-Mail-Adresse zu senden, denn die kann ein Angreifer nach seinen Wünschen eingeben.
  • Auch wenn ein neues Passwort oder ein URL zur Passwortänderung an die gespeicherte E-Mail-Adresse gesendet wird, kann das Verfahren unsicher sein, und zwar wenn das neue Passwort oder der URL vorhersagbar sind. Das kann z.B. passieren, wenn dem Angreifer der für die Erzeugung von Passwort oder URL verwendete Algorithmus bekannt ist und dafür dem Angreifer bekannte oder von ihm erratbare Parameter verwendet werden, wie z.B. die Benutzer-ID oder die aktuelle Zeit. Der Angreifer kann dann das Passwort oder den URL selbst berechnen und nutzen.

In der nächsten Folge geht es um weitere mögliche Schwachstellen in der und Angriffe auf die "Vergessenes Passwort"-Funktion.

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