Channel Security

Wie er Zugriff auf die Webanwendung erlangt, ist einem Angreifer im Allgemeinen egal. Kann er die Authentifizierung nicht bei der normalen Anmeldung überwinden, sucht er nach anderen Möglichkeiten, Zugangsdaten auszuspähen oder zu manipulieren. Auch jede Funktion, die nur indirekt den Zugriff auf die Anwendung erlaubt, ist daher ein mögliches Angriffsziel. So auch die Funktion zum Zurücksetzen des Passworts: Kann der Angreifer sie manipulieren und darüber das Passwort eines beliebigen Benutzers zurück setzen, kann er sich danach evtl. als dieser Benutzer anmelden.

"Account Recovery" außerhalb der Webanwendung

In kritischen Anwendungen, insbesondere also z.B. beim Onlinebanking, wird das "Account Recovery" im Fall eines vergessenen Passworts außerhalb der Webanwendung ausgelöst, z.B. indem der Benutzer seine Filiale aufsucht oder ein Callcenter anruft und sich dort authentifiziert. Auch das neue Passwort wird ihm dann "out of band", z.B. per Briefpost an seine bekannte Anschrift, übermittelt. In den allermeisten Fällen ist dieser Aufwand aber nicht notwendig, so dass das Passwort auch online und automatisch zurückgesetzt werden kann.

"Account Recovery" innerhalb der Webanwendung

An die Funktion zum Zurücksetzen des Passworts werden zwei Anforderungen gestellt: Zum einen muss verhindert werden, dass ein Angreifer darüber das Passwort eines Benutzers zurücksetzen kann, zum anderen sollen die Benutzer ihr Passwort im Notfall möglichst kurzfristig zurück setzen können, um nicht länger als unbedingt nötig an der Nutzung der Anwendung gehindert zu werden. Möglichst sicher und möglichst einfach/schnell widerspricht sich im Allgemeinen, in diesem Fall aber zum Glück nicht.

Unsichere Lösungen

Hinweise auf das aktuelle Passwort sollten niemals verwendet werden - die Gefahr, dass ein Angreifer daraufhin das richtige Passwort rät, weil ein Benutzer einen zu eindeutigen Hinweis angegeben hat, ist zu hoch (siehe About Security #222).

Ebenso ist jede Funktion unsicher, die nach dem erfolgreichen Bestehen eines Challenge-Response-Verfahrens zur Identifizierung des Benutzers sofort den Zugriff auf die Webanwendung erlaubt, egal ob das über das Einrichten einer authentifizierten Session, die Weiterleitung auf die Funktion zur Passwortänderung oder die Ausgabe eines neuen Passworts erfolgt (siehe About Security #222).

Auch Sicherheitsfragen können sehr gefährlich sein, siehe About Security #222 und den Standpunkt Sicherheit vom 4. Mai 2009. Selbst wenn die Webanwendung keine dummen, d.h. einfach zu beantwortenden, Fragen vorgibt, sondern der Benutzer die Frage selbst stellen muss, kann unmöglich sicher gestellt werden, dass wirklich alle Benutzer eine sichere, d.h. nicht einfach zu beantwortende, Frage verwenden.

Die sichere Lösung ...

... besteht darin, dem Benutzer einen einmaligen, nicht erratbaren, nur kurze Zeit gültigen und nur einmal verwendbaren URL an die gespeicherte E-Mail-Adresse zu schicken, mit dem er auf eine Seite gelangt, auf der er ein neues Passwort eingeben kann (siehe auch About Security #223). Nachdem das Passwort geändert wurde, wird der Benutzer in einer zweiten Mail über die erfolgreiche Änderung des Passworts informiert (wobei das Passwort natürlich nicht mitgeschickt werden darf!). Um DoS-Angriffe durch das wiederholte Anfordern der Passwort-Reset-Mails zu verhindern, muss das aktuelle Passwort so lange gültig bleiben, bis ein neues gesetzt wurde.

Diese Funktion kann problemlos ohne vorherige Identifizierung des Benutzers zugänglich sein, da ein Angreifer darüber keinen Schaden anrichten kann: Weder ermöglicht sie ihm den Zugriff auf die Webanwendung, noch verrät sie, ob ein Benutzername gültig ist oder nicht.

Zusätzliche Schutzmaßnahme

Um Schabernack zu verhindern, kann der Zugriff auf die Funktion als zusätzliche Schutzmaßnahmen an eine erfolgreiche Identifizierung des Benutzers geknüpft sein: Wer das Passwort eines bestimmten Benutzerkontos zurücksetzen will, muss vorher durch Bestehen eines Challenge-Response-Verfahrens nachweisen, dass er wirklich der entsprechende Benutzer ist. Das kann z.B. durch die richtige Beantwortung einer Sicherheitsfrage passieren. Das klingt wie ein Widerspruch zur obigen Warnung, ist aber keiner: Selbst wenn ein Angreifer die Sicherheitsfrage erfolgreich rät, erlangt er keinen Zugriff auf das Benutzerkonto. Dafür müsste er zusätzlich Zugriff auf das Mailkonto des betreffenden Benutzers haben, und der hat dann ganz andere Probleme als den unbefugten Zugriff auf die Webanwendung. Das gleiche gilt für den Fall, dass dem Angreifer der Zugriff auf die ausgehenden Mails möglich ist - wer das kann, hat andere Möglichkeiten, die Webanwendung zu kompromittieren.

Allerdings hat die Sicherheitsfrage auch an dieser Stelle eine unerwünschte Nebenwirkung: Sie kann gültige Benutzernamen verraten. U.a. darum geht es in der nächsten Folge, in der die Entwicklung sicherer Authentifizierungssysteme abgeschlossen wird.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #214: Schwachstellen-Suche: Authentifizierung - Grundlagen
• About Security #215: Schwachstellen-Suche: Authentifizierung - Brute Force
• About Security #216: Schwachstellen-Suche: Authentifizierung - Namen finden
• About Security #217: Schwachstellen-Suche: Authentifizierung - Ein Angriff
• About Security #218: Schwachstellen-Suche: Authentifizierung - Die Übertragung
• About Security #219: Schwachstellen-Suche: Authentifizierung - Verschlüsselung
• About Security #220: Schwachstellen-Suche: Authentifizierung - Unsichere Kryptographie
• About Security #221: Schwachstellen-Suche: Authentifizierung - Passwort ändern
• About Security #222: Schwachstellen-Suche: Authentifizierung - Passwort-Reset
• About Security #223: Schwachstellen-Suche: Authentifizierung - Passwort-Reset (2)
• About Security #224: Schwachstellen-Suche: Authentifizierung - "Remember me"
• About Security #225: Schwachstellen-Suche: Authentifizierung - "User Impersonation"
• About Security #226: Schwachstellen-Suche: Authentifizierung - "Halbe Passwörter"
• About Security #227: Schwachstellen-Suche: Authentifizierung - "Doppelte Benutzer"
• About Security #228: Schwachstellen-Suche: Authentifizierung - Vorhersagbares
• About Security #229: Schwachstellen-Suche: Authentifizierung - Daten übertragen
• About Security #230: Schwachstellen-Suche: Authentifizierung - Implementierungsfehler
• About Security #231: Schwachstellen-Suche: Authentifizierung - Implementierungsfehler (2)
• About Security #232: Schwachstellen-Suche: Sichere Authentifizierung
• About Security #233: Schwachstellen-Suche: Sichere Authentifizierung (2)
• About Security #234: Schwachstellen-Suche: Sichere Authentifizierung (3)
• About Security #235: Schwachstellen-Suche: Sichere Authentifizierung (4)
• About Security #236: Schwachstellen-Suche: Sichere Authentifizierung (5)
• About Security #237: Schwachstellen-Suche: Sichere Authentifizierung (6)