Montag, 11. Juli 2011


Topthema

Donnerstag, 31. Dezember 2009 | Topthema

About Security #236: Schwachstellen-Suche: Sichere Authentifizierung (5)

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

Gegen Brute-Force-Angriffe, bei denen eine Liste mit einer große Anzahl ermittelter oder erratener Benutzernamen der Reihe nach mit einem einzelnen Passwort durchprobiert wird, helfen die üblichen Gegenmaßnahmen nicht. Wie in About Security #235 erwähnt, sind die Erfolgsaussichten eines solchen Angriffs gar nicht mal schlecht, vor allem dann nicht, wenn die Webanwendung sehr viele Benutzer hat und der Angreifer eine lange Liste ihm bekannter Benutzernamen durchprobieren kann. Irgend einer dieser Benutzer wird sehr wahrscheinlich ein schwaches Passwort haben.

Brute-Force-Angriffe auf viele Benutzerkonten abwehren

Die Erfolgswahrscheinlichkeit für so einen Angriff sinkt, wenn alle anderen Schutzmaßnahmen korrekt implementiert wurden: Können keine gültigen Benutzernamen ermittelt werden, muss der Angreifer sie raten. Werden die Regeln für ein starkes Passwort erzwungen, sinkt die Wahrscheinlichkeit, dass der Angreifer ein gültiges Passwort rät. Besteht die Authentifizierung aus mehreren Stufen, steht der Angreifer nach dem erfolgreichen Brechen der ersten Stufe vor dem Problem, dass er nun mit diesem einen "angebrochenen" Benutzerkonto die folgenden Stufen brechen muss, wobei wieder die in About Security #235 beschriebenen Maßnahmen zur Verhinderung von Brute-Force-Angriffen zum Zuge kommen.

Eine weitere Möglichkeit, um solche Angriffe zu verhindern, ist der Einsatz eines CAPTCHA. Die werden zwar hauptsächlich eingesetzt, um automatische Registrierungen oder Kommentar-Spam zu verhindern, erfüllen aber auch im Authentifizierungsprozess ihren Zweck: Das automatische Ausführen der damit geschützten Formulare zu verhindern. Gibt es für jede durch Brute-Force-Angriffe gefährdete Funktion einen CAPTCHA-Schutz, kann die Funktion nur noch manuell ausgelöst werden, ein Brute-Force-Angriff ist also nicht mehr möglich. Zwar gibt es inzwischen auch mehr oder weniger effektive Angriffe auf die meisten CAPTCHA-Systeme, die kosten aber Zeit und/oder Geld und mit etwas Glück sucht sich der Angreifer ein schlechter geschütztes Ziel.

6. Funktion zur Passwortänderung vor Angriffen schützen

Eine Funktion zur Passwortänderung ist notwendig, damit die Benutzer ihr Passwort bei Bedarf, z.B. nach einer Kompromittierung, schnell und problemlos ändern können (siehe About Security #221). Außerdem ist sie natürlich eine Voraussetzung für eine evtl. eingeführte Beschränkung der Gültigkeitsdauer der Passwörter: Ablaufende Passwörter müssen schließlich rechtzeitig ausgetauscht werden können. Da es für den Angreifer egal ist, ob er durch die Vordertür des Authentifizierungsprozesses oder die Hintertür eines manipulierten Passworts eindringt, muss die Funktion zur Passwortänderung genau so sicher sein wie die Authentifizierungsfunktion selbst. Ein erster wichtiger Schritt ist dabei die Positionierung innerhalb der Webanwendung. Da nur registrierte Benutzer überhaupt ein Passwort haben, das sie ändern können, sollte die Funktion erst nach der Authentifizierung zugänglich sein. Das verhindert keinen Angriff durch einen Angreifer, der sich zuvor selbst registriert hat und dann versucht, die Passwörter anderer Benutzer zu ändern. Daher darf es keine Möglichkeit geben, einen Benutzernamen anzugeben, weder explizit noch durch ein verstecktes Formularfeld oder einen Cookie. Jeder Benutzer darf sowieso nur sein eigenes Passwort ändern, es besteht also auch gar keine Notwendigkeit dafür, einen anderen Benutzernamen anzugeben.

Bevor das Passwort geändert wird, muss der Benutzer sein bisheriges Passwort eingeben. Das klingt überflüssig, da er das ja schon bei der vorherigen Authentifizierung getan hat, ist aber zwingend notwendig: Es verhindert das unbefugte Ändern des Passworts durch einen Angreifer der über einen andere Schwachstelle bzw. einen anderen Angriff wie z.B. Session Hijacking oder Cross Site Scripting Zugriff auf die Funktion zur Passwortänderung erlangt hat.

About Security: Die komplette Serie

Das neue Passwort sollte immer zwei Mal eingegeben werden, um Tippfehler zu vermeiden, durch die der Benutzer sich selbst aussperrt. Nachdem geprüft wurde, ob beide eingegebenen Wörter überein stimmen, muss das neue Passwort auf das Einhalten der Passwortregeln geprüft werden. Wurde das Passwort geändert, weil das bisherige abgelaufen ist, muss zusätzlich geprüft werden, ob es womöglich mit dem bisherigen übereinstimmt. Viele Benutzer unterlaufen so bekanntlich den Zwang, ein Passwort regelmäßig zu ändern.

Wurde das Passwort geändert, muss der Benutzer "out of band", z.B. über eine E-Mail, über die erfolgte Änderung informiert werden. Dabei sollte auch die Möglichkeit bestehen, die Änderung Rückgängig zu machen oder das Benutzerkonto zu sperren, falls die Passwortänderung nicht vom Benutzer durchgeführt wurde. Dabei müssen die vor der Passwortänderung gültigen Kontaktinformationen wie z.B. die E-Mail-Adresse verwendet werden, da ein erfolgreicher Angreifer sonst nach der unbefugten Änderung des Passworts diese gegen andere austauschen und die Schutzfunktion ins Leere laufen lassen kann.

Außerdem müssen die gleichen Schutzfunktionen wie für die Authentifizierungsfunktion selbst gelten, wie z.B. keine Preisgabe gültiger Benutzernamen oder sonstiger für einen Angreifer brauchbarer Informationen über Fehlermeldungen und die temporäre Sperre der Funktion nach wenigen Fehlschlägen.

In der nächsten Folge wird die Entwicklung sicherer Authentifizierungssysteme mit der Absicherung der Funktion zum Zurücksetzen des Passworts fortgeführt.

Ich wünsche allen Lesern ein erfolgreiches neues Jahr!

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