Sonntag, 15. August 2010


Topthema

Donnerstag, 3. Dezember 2009 | Topthema

About Security #233: Schwachstellen-Suche: Sichere Authentifizierung (2)

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

Die Entwicklung sicherer Authentifizierungssysteme bzw. die Behebung gefundener Schwachstellen ist auch das Thema dieser Folge.

Zur Vervollständigung der in About Security #232 aufgeführten Regeln zur sicheren Verwendung bzw. Verarbeitung der Zugangsdaten fehlt noch ein Punkt: Wenn möglich, sollte ein Teil der Zugangsinformationen über ein Drop-Down-Menü statt über ein Textfeld abgefragt werden, um einen evtl. eingeschleusten Keylogger auszutricksen. Dafür kommen vor allem die in About Security #230 und #231 beschriebenen zusätzlichen Informationen eines mehrstufigen Systems, wie z.B. die Angabe bestimmter Buchstaben eines geheimen Wortes, in Frage.

Alles für die Katz?

Man sollte immer berücksichtigen, dass ein Angreifer, der den Rechner des Benutzers kompromittiert hat, prinzipiell sämtliche Informationen ausspähen kann, unabhängig davon, ob es sich z.B. um Texteingaben, ausgewählte Drop-Down-Menüs oder Mausbewegungen handelt oder ob die Daten über HTTP oder das geschützte HTTPS übertragen werden: Ein Man-in-the-Middle bzw. passender Man-in-the-Browser kann alles protokollieren, was vom Browser an den Server geschickt wird. Egal wie umsichtig man mit den Zugangsdaten umgeht, es ist nie ausgeschlossen, dass ein Unbefugter sie ausspäht und/oder sich als Man-in-the-Middle zwischen Benutzer und Server schleicht. Vor dem Missbrauch ausgespähter Zugangsdaten bietet ein mehrstufiges Authentifizierungssystem einen gewissen Schutz, da der Angreifer dann i.A. nicht alle für die Authentifizierung benötigten Informationen kennt (sofern es keine der in About Security #230 und #231 beschriebenen Schwachstellen gibt). Eine weitere Schutzmaßnahme ist der Einsatz eines Security-Tokens, das ein immer nur für kurze Zeit gültiges Einmalpasswort (One Time Password, OTP) erzeugt. Das schützt zwar nicht vor einem Man-in-the-Middle, der die laufende Kommunikation ausspähen und manipulieren kann, verhindert aber die Nutzung ausgespähter Zugangsdaten. Dafür bringt es einen anderen Nachteil mit sich: Geht das Token verloren oder ist es defekt, ist der Benutzer aus der Webanwendung ausgesperrt, sofern es keine weitere Authentifizierungsmöglichkeit gibt. Die bietet dann aber wiederum eine zusätzliche Angriffsfläche und muss aufwendig abgesichert werden, da sie für einen Angreifer natürlich reizvoller als der normale, per Security-Token gesicherte Zugang ist. Je nach individueller Bedrohung muss man sich also entscheiden, wie sicher das Authentifizierungssystem sein muss, wie gro� das tolerierbare Restrisiko eines erfolgreichen Angriffs sein darf - und wie hoch die Zugangshürden überhaupt sein dürfen, damit sie die Benutzer nicht abschrecken.

3. Korrekte Prüfung der Zugangsdaten

Passwörter müssen immer vollständig und im Originalzustand geprüft werden. Sie dürfen also weder nach eine bestimmten Zeichenanzahl abgeschnitten noch in irgend einer Form modifiziert werden, z.B. indem alle Zeichen in Gro�- oder Kleinbuchstaben umgewandelt oder Sonderzeichen ausgefiltert werden (siehe About Security #226).

Gibt es eine Funktion zur "User Impersonation", muss besonders darauf geachtet werden, dass darüber kein Umgehen der Authentifizierung möglich ist (siehe About Security #225). Da die Funktion i.A. sowieso nur von Administratoren genutzt werden darf, empfiehlt es sich, sie auch nur aus dem Administrationsbereich zugänglich zu machen. Außerdem müssen alle Aufrufe der Funktion protokolliert und regelmäßig kontrolliert werden, um einen möglichen Missbrauch schnellstmöglich zu entdecken.

About Security: Die komplette Serie

Bei mehrstufigen Authentifizierungssystemen muss besonders sorgfältig darauf geachtet werden, dass die Benutzer und damit auch die potentiellen Angreifer keinen Einfluss auf das Zusammenwirken der einzelnen Stufen nehmen können (siehe About Security #230 und #231).

  • Alle Informationen über die Fortschritte in der Authentifizierung sowie über die Ergebnisse in den einzelnen Stufen müssen auf dem Server gespeichert werden und dürfen nie an den Client gesendet oder von diesem gelesen werden können.
  • Einmal an den Server gesendete Informationen dürfen nicht erneut an den Server gesendet werden, es darf für den Benutzer keine Möglichkeit geben, bereits vom Server erfasste und/oder geprüfte Daten nachträglich zu ändern. Wird eine Information von mehreren Stufen benötigt, muss sie auf dem Server gespeichert werden.
  • Als erster Schritt muss in jeder Stufe geprüft werden, ob alle vorherigen Stufen erfolgreich und vollständig durchlaufen wurden.
  • Ein fehlgeschlagener Authentifizierungsversuch sollte erst nach dem Durchlaufen der letzten Stufe mit einer allgemeinen Meldung wie "Login fehlgeschlagen" an den Benutzer gemeldet werden, unabhängig davon, in welcher Stufe der Benutzer gescheitert ist. Ansonsten könnte der Angreifer bei einem weiteren Angriff gezielt diese Stufe angreifen.

Wird während der Authentifizierung eine geheime Frage gestellt, muss sichergestellt sein, dass der Angreifer ihre Auswahl nicht manipulieren kann. Dazu muss der Server die Frage auswählen, nachdem der Benutzer sich in einem vorherigen Schritt identifiziert hat. Welche Frage gestellt wurde, muss auf dem Server gespeichert werden, und die ausgewählte Frage muss so lange immer wieder verwendet werden, bis sie erfolgreich beantwortet wurde. (Siehe About Security #231).

In der nächsten Folge wird die Entwicklung sicherer Authentifizierungssysteme fortgeführt.

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