Wie werden Zugangsdaten sicher übertragen? Für die Richtung vom Benutzer zur Webanwendung nimmt man dafür SSL/TLS - aber was ist mit der Übertragung der von der Webanwendung während der Registrierung erzeugten Daten? Die müssen an den Benutzer übermittelt werden, und das, ohne dass Unbefugte sie dabei zu sehen bekommen.

In einem Intranet ist die sichere Verteilung von der Webanwendung erzeugter Zugangsdaten kein Problem, da können die Benutzer sie z.B. in der IT-Abteilung abholen oder sie bekommen sie von ihrem Vorgesetzten oder in der Personalabteilung oder ... Anders sieht es im Internet aus, dort soll die Übertragung der Zugangsdaten "out of band" einen gewissen Schutz vor Registrierungen unter falschen Namen gewähren: Durch das Mailen der Zugangsdaten an die angegebene E-Mail-Adresse oder ihr Schicken an die angegebene Postanschrift soll geprüft werden, ob das E-Mail-Konto bzw. der Briefkasten unter der Kontrolle der Person steht, die sich damit registriert hat. Dabei gibt es mehrere mögliche Schwachstellen:

• Übertragung von Benutzername und Passwort
  Enthält die Nachricht sowohl Benutzername als auch Passwort, und gibt es weder ein Zeitlimit für deren Gültigkeit noch einen Zwang zur Passwortänderung bei der ersten Anmeldung, werden viele Benutzer das Passwort nicht ändern, und jeder, dem die Daten in die Hände fallen, kann sich damit anmelden.
• Aktivierungs-Links
  Wird statt der vollständigen Zugangsdaten oder des Passworts nur ein Aktivierungs-Link verschickt, mit dem sich die Benutzer einmalig anmelden können, um dann ein eigenes Passwort zu setzen, können vorhersagbare URLs einen Angreifer in die Lage versetzen, fremde Benutzerkonten zu übernehmen.
• Übertragung sämtlicher Daten
  Werden nicht nur Benutzername und Passwort bzw. ein Aktivierungs-Link übertragen, sondern sämtliche bei der Registrierung angegebenen Daten wie z.B. Name und Adresse, weitere Kontaktmöglichkeiten wie Telefonnummern oder (ggf. weitere) E-Mail-Adressen oder die Antwort auf die Sicherheitsfrage, schützt auch eine zeitliche Begrenzung der Gültigkeitsdauer der Zugangsdaten oder der Zwang zum Setzen eines Passworts bei der ersten Anmeldung nicht vor einem Angriff, der dann z.B. durch Nutzung der Passwort-Reset-Funktion mit der bekannten Antwort auf die Sicherheitsfrage oder in Form eines Social-Engineering-Angriffs erfolgen kann.
• "Fremde Briefkästen"
  Werden die Zugangsdaten an die angegebene Postanschrift geschickt, beweist das nur, dass der sich registrierende Benutzer diesen Brief empfangen hat. Ob er den aus seinem eigenen Briefkasten genommen oder ihn z.B. aus einen ungenutzten Briefkasten geangelt hat oder einfach einen Briefkasten mit passenden Namen in einer anonymen Wohngegend an die Wand geschraubt hat, weiß man nicht. Will man sicher sein, dass die angegebene Anschrift stimmt, muss man schon zu einem dafür vorgesehen Verfahren, z.B. dem Postident-Verfahren der Deutschen Post, greifen.

Schwachstellen verhindern

Beim Test der eigenen Webanwendung muss man wie üblich nicht lange suchen, man weiß ja, wie die Zugangsdaten "out of band" übertragen werden und kann sofort daran gehen, evtl. vorhandenen Schwachstellen zu korrigieren:

• Werden Benutzername und Passwort gemeinsam übertragen, sollte man prüfen, ob man auf die Übertragung des Benutzernamens verzichten kann, denn den kennt der neue Benutzer ja von der Registrierung. Sollen, aus welchen Gründen auch immer, die vollständigen Zugangsdaten übertragen werden, dürfen sie nicht unbegrenzt gültig sein, sondern nur für einen relativ kurzen Zeitraum. Wie lang der ist, muss im Einzelfall entschieden werden, da die neu registrierten Benutzer ja Zeit haben müssen, um sich damit anzumelden. Außerdem sollte es nach der ersten Anmeldung mit diesen Zugangsdaten einen Zwang zum Setzen eines neuen Passworts geben, so dass die übertragenen Zugangsdaten danach unbrauchbar sind.
• Werden Aktivierungs-Links verschickt, müssen die wirklich zufällig und nicht vorhersagbar erzeugt werden. Es spricht nichts dagegen, z.B. den Benutzernamen oder weitere Daten in der URL zu speichern, zusätzlich muss aber ein wirklich zufälliger Wert verwendet werden, so dass ein Angreifer keine gültigen Aktivierungs-Links erzeugen kann.
  Im Extremfall, in dem der Link alle zum Anlegen des neuen Benutzerkontos verwendeten Daten enthält, könnte ein Benutzer sogar die Registrierung umgehen und nur durch das Erzeugen eines entsprechenden Links ein neues Benutzerkonto anlegen.
  Außerdem dürfen die Aktivierungs-Links nur einmal zu benutzen sein, damit ein Angreifer, dem so ein Link in die Hände fällt, darüber nicht später noch die Kontrolle über das betreffende Benutzerkonto erlangen kann.
• Vollständige Daten sollten sicherheitshalber nicht übertragen werden. Wozu auch - die kennt der Benutzer ja. Insbesondere dürfen keine Informationen, die zum Zurücksetzen des Passworts oder für ähnliche Fallback-Funktionen verwendet werden, übertragen werden. Geraten die in falsche Hände, ist das entsprechende Benutzerkonto danach kompromittiert.

Schwachstellensuche durch Angreifer

Ein Angreifer bzw. Black-Box-Tester registriert sich bei der Webanwendung und stellt dabei fest, ob und wie Zugangsdaten an ihn übertragen werden.

Wird ein Aktivierungs-Link verschickt, werden weitere Benutzernamen registriert und die dabei gewonnenen Aktivierungs-Links auf Regelmäßigkeiten geprüft. Danach wird versucht, ob sich die den bekannten Links vorhergehenden oder folgenden Links erfolgreich erraten lassen.

Außerdem ist von Interesse, was bei der mehrmaligen Nutzung des Aktivierungs-Links passiert. Kann man damit vielleicht auch später noch Zugriff auf das Konto erlangen? Evtl. sogar, nachdem das Passwort geändert wurde?

In der nächsten Folge geht es um typische Implementierungsfehler im Bereich der Authentifizierung.

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