Bundesamt für Sicherheit in der Informationstechnik

M 4.392 Authentisierung bei Webanwendungen

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Entwickler, Administrator

Soll eine Webanwendung oder Teile davon ausschließlich von einem eingeschränkten Benutzerkreis genutzt werden können, so muss sich der Benutzer gegenüber der Anwendung authentisieren. Für die Authentisierung können unterschiedliche Methoden verwendet werden, die in den Maßnahmen M 4.176 Auswahl einer Authentisierungsmethode für Webangebote und M 5.160 Authentisierung gegenüber Webservern beschrieben sind.

Bei der Umsetzung von Authentisierungsmechanismen für Webanwendungen sind folgende Punkte zu berücksichtigen.

Anforderungen an die Authentisierungskomponente

Die Authentisierungslogik sollte nur an einer Stelle und nicht mehrfach im Programmcode realisiert werden. Treten während der Authentisierung Fehler auf, sollte die angeforderte Aktion abgebrochen und die Anfrage zurückgewiesen werden.

Die Authentisierungskomponente sollte das Erzwingen sicherer Passwörter gemäß einer Passwort-Richtlinie unterstützen. Anforderungen an sichere Passwörter können der Maßnahme M 2.11 Regelung des Passwortgebrauchs entnommen werden.

Darüber hinaus wird empfohlen, die geschätzte Stärke des eingegebenen Passworts einzublenden (z. B. schwach, mittel, sicher). Dadurch wird der Benutzer dabei unterstützt, sichere Passwörter zu wählen.

Um Fehler bei der Entwicklung der Authentisierungskomponente zu vermeiden, wird empfohlen die Authentisierungskomponente auf Basis etablierter Standardkomponenten (Bibliotheken oder Frameworks) umzusetzen ( z. B. Enterprise Security API der OWASP).

Besteht ein erhöhter Schutzbedarf der Webanwendung, sollte eine Zwei-Faktor-Authentisierung eingesetzt werden.

Damit ein Benutzer den Missbrauch seines Benutzerkontos erkennen kann, kann die Webanwendung das Datum und die Uhrzeit der letzten erfolglosen und erfolgreichen Anmeldeversuche nach der Anmeldung eines Benutzers als Warnhinweis anzeigen.

Remember-Me-Funktion

Zur Steigerung der Benutzerfreundlichkeit werden die Authentisierungsdaten von Webanwendungen teilweise dauerhaft auf dem Client der Benutzer gespeichert (z. B. innerhalb eines Cookies im Web-Browser). Diese Möglichkeit wird häufig als Remember-Me-Funktion bezeichnet. Wurden Authentisierungsdaten im Rahmen der Remember-Me-Funktion auf dem Client gespeichert, werden diese bei einer späteren Nutzung der Webanwendung automatisch übertragen. Der Benutzer muss somit keine Zugangsdaten mehr eingeben.

Erhält ein Angreifer Zugriff auf den Web-Browser oder wird Schadcode auf dem Client ausgeführt, können diese gespeicherten Authentisierungsdaten ausgelesen werden. Aus diesem Grund sollte die Verwendung dieser Funktion vermieden werden. Kann auf die Remember-Me-Funktion nicht verzichtet werden, so sollte der Benutzer explizit einer Aktivierung zustimmen müssen (Opt-In). Darüber hinaus sollte der Benutzer auf die Risiken der Funktion hingewiesen werden.

Neben Authentisierungsdaten in Cookies können aktuelle Browser häufig Formularfelder (z. B. Benutzername/Passwort oder Adressdaten) für eine spätere Wiederverwendung speichern. Wird ein Web-Formular, für das die eingegebenen Daten zuvor gespeichert wurden, erneut aufgerufen, so werden die Daten automatisch vom Browser in die Felder eingetragen. Daher sollte die Option "autocomplete=off" für alle Formularfelder mit vertraulichen Daten gesetzt werden. Dadurch werden die Browser angewiesen, die Daten der entsprechenden Formularfelder nicht zu speichern.

Zusätzliche Authentisierung bei kritischen Funktionen

Hat sich ein Benutzer erfolgreich authentisiert, so wird ihm von der Webanwendung üblicherweise eine eindeutige Sitzung (mittels SessionID) zugewiesen. Die Webanwendung kann mithilfe dieser SessionID die eintreffenden Requests den angemeldeten Benutzern zuordnen. Somit kann die SessionID als eine Art temporäres Anmeldedatum betrachtet werden, mit dessen Hilfe auf die Sitzungen angemeldeter Benutzer zugegriffen werden kann (siehe auch M 4.394 Session-Management bei Webanwendungen und Web-Services ).

Da viele Angriffe gegen die SessionID bekannt sind (siehe G 5.169 Unzureichendes Session-Management von Webanwendungen und Web-Services ), kann eine Übernahme von gültigen Sitzungen nicht vollständig ausgeschlossen werden. Daher sollte bei sicherheitskritischen Aktionen (z. B. Änderung des Passworts oder Löschung des kompletten Datenbestandes) eine erneute Authentisierung des Benutzers (z. B. durch Eingabe des alten Passworts bei einem Passwortwechsel) erfolgen.

Grenzwerte für gescheiterte Anmeldeversuche

Versucht ein Benutzer sich mehrfach in kurzen Zeitabständen an der Webanwendung anzumelden, so sollten diese Authentisierungsversuche als Angriff gewertet werden. Wenn die Zahl der fehlgeschlagenen Versuche einen festgelegten Wert überschreitet (z. B. fünf Fehlversuche), sollte das Benutzerkonto für ein definiertes Zeitintervall (z. B. 10 Sekunden) gesperrt werden. Darüber hinaus können die Zeitintervalle zur Sperrung des Benutzerkontos mit der Anzahl der Fehlversuche progressiv ansteigen. Hierdurch soll verhindert werden, dass Benutzer unbefugt Kennwörter anderer Benutzer erraten.

Bei der Wahl des Grenzwerts und der Zeitintervalle sollte beachtet werden, dass dieser Mechanismus für Denial-of-Service-Angriffe missbraucht werden kann. Ein Angreifer kann bewusst das Sperren vieler Benutzerkonten provozieren und somit diese Benutzer von der Nutzung der Webanwendung ausschließen.

Automatisiertes Zurücksetzen von Authentisierungsdaten

Da Webanwendungen oftmals von einem großen Benutzerkreis genutzt werden, bieten sie häufig Funktionen zum automatisierten Zurücksetzen der Authentisierungsinformationen (Passwort-Reset) an. So soll der administrative Aufwand möglichst gering gehalten werden, wenn z. B. ein Benutzer sein Passwort vergessen hat. Können die Authentisierungsdaten unbefugt zurückgesetzt werden, kann auf diese Weise der Authentisierungsmechanismus umgangen werden. Deshalb ist darauf zu achten, dass alle Funktionen einer Webanwendung zur Änderung der Authentisierungsdaten mindestens genauso abgesichert sind wie die primäre Authentisierung der Webanwendung.

Wird beispielsweise im Prozess zum Zurücksetzen des Passworts die Authentisierung des Benutzers über eine geheime Frage mit entsprechender Antwort sichergestellt, so sollten die Merkmale vom Benutzer formuliert werden können. Er sollte darauf hingewiesen werden, dass sie keine Daten beinhalten sollten, die öffentlich verfügbar oder leicht zu erraten sind. Zur Erhöhung des Schutzniveaus können mehrere Fragen und Antworten bei der Registrierung aufgenommen werden (z. B. fünf, von denen mindestens drei Fragen für eine erfolgreiche Authentisierung richtig beantwortet werden müssen).

Zusätzlich kann noch ein weiteres Sicherheitsmerkmal verwendet werden, indem nach der korrekten Beantwortung der Fragen ein Link an eine zuvor vom Benutzer spezifizierte E-Mail-Adresse versendet wird oder ein weiteres Sicherheitstoken (z. B. eine PIN ) per SMS an eine hinterlegte Rufnummer gesendet wird. Erst nach Klicken auf den Link bzw. Eingabe der PIN kann sich der Benutzer dann anmelden.

Da das Authentisierungsverfahren beim Zurücksetzen von Anmeldeinformationen in der Regel nur schwer auf das gleiche Sicherheitsniveau der primären Authentisierung zu bringen ist, sollte nach Möglichkeit auf ein automatisiertes Zurücksetzen durch die Webanwendung verzichtet werden. Bei eingeschränkten Nutzerkreisen der Webanwendung (z. B. bei einer Webanwendung im Intranet) kann stattdessen das Passwort manuell beispielsweise über eine Hotline mit sicheren Authentisierungsmerkmalen und entsprechendem Freigabeverfahren zurückgesetzt werden. Insbesondere bei einem hohen Schutzbedarf sollte eine manuelle Zurücksetzungsfunktion umgesetzt werden.

Prüffragen:

  • Verwendet die Webanwendung eine zentrale Authentisierungskomponente?

  • Erzwingt die Webanwendung die Verwendung sicherer Passwörter?

  • Setzen die Webanwendungen eine explizite Zustimmung des Benutzers bei der Verwendung der Remember-Me-Funktion voraus (Opt-In)?

  • Werden kritische Funktionen der Webanwendung durch eine zusätzliche Authentisierung geschützt?

  • Definiert die Webanwendung Grenzwerte für fehlgeschlagene Anmeldeversuche, die Brute-Force-Angriffe erschweren?

  • Erfüllen alle angebotenen Authentisierungsverfahren der Webanwendung (beispielsweise auch Funktionen zum automatisierten Zurücksetzen des Passworts) das gleiche Sicherheitsniveau?

  • Wird der Benutzer einer Webanwendung umgehend über die Nutzung der angebotenen Passwort-Zurücksetzungsfunktion informiert?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK