Bundesamt für Sicherheit in der Informationstechnik

M 4.176 Auswahl einer Authentisierungsmethode für Webangebote

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

Verantwortlich für Umsetzung: Administrator

Für E-Commerce- und E-Government-Anwendungen, personalisierte Webangebote oder nur allgemein zur Realisierung von Zugriffsbeschränkungen auf bestimmte Bereiche eines Webangebots werden Mechanismen zur Identifikation und Authentisierung verschiedener Benutzer benötigt.

In Abhängigkeit von den konkreten Anforderungen an den Schutz der Informationen vor unbefugtem Zugriff und die Qualität der Authentisierung muss eine geeignete Methode ausgewählt werden. Die Wahl der Authentisierungsmethode und die Gründe, die zu der Wahl geführt haben, sollten dokumentiert werden.

Authentisierungsmethoden bei HTTP

Das Protokoll HTTP/1.1 sieht zwei verschiedene Methoden zur Benutzerauthentisierung vor.

Die erste Methode ist die so genannte Basic-Access-Authentisierung. Dabei sendet der Client den Benutzernamen und das Passwort Base64-kodiert im so genannten Authorization Header des HTTP-Requests an den Server. Base64 ist eine Methode zur Kodierung von Binärdaten in 7-Bit ASCII, die hier zur Übertragung von Sonderzeichen über die HTTP-Schnittstelle genutzt wird. Das Passwort ist somit zwar nicht auf den ersten Blick ablesbar, kann aber von einem potentiellen "Lauscher" problemlos ermittelt werden, da es unverschlüsselt ist. Daher ist dieser Authentisierungstyp allenfalls für sehr geringe Vertraulichkeitsanforderungen zu gebrauchen.

Die zweite Methode zur HTTP-Authentisierung ist die Digest-Authentisierung. Bei dieser Art der Authentisierung muss auf dem Server das Passwort des Benutzers im Klartext vorliegen. Der Client erhält vom Server einen Zufallsstring, die so genannte Challenge. Aus dieser Challenge und dem Passwort des Benutzers errechnet der Client nach einem standardisierten Verfahren einen so genannten Digest, der dann zur Authentisierung an den Server gesandt wird. Da der Server sowohl über den von ihm generierten Zufallsstring, als auch über das Passwort des Benutzers verfügt, kann er den Digest ebenfalls berechnen und so die Authentisierung durchführen. Da bei der Digest-Authentisierung das Passwort nicht über das Netz verschickt wird, eignet sich diese Methode für einen etwas höheren Schutzbedarf.

Ein Problem bei der Verwendung der oben genannten Authentisierungsmethoden ist die Sicherheit der Passwortdaten auf dem Server: Bei Verwendung der Digest-Authentisierung müssen die Authentisierungsdaten der Benutzer auf dem Webserver im Klartext vorhanden sein. Bei Verwendung der Basic-Authentisierung wird meist ein Hash-Wert des Passwortes gespeichert. Eine Sicherung der Passwortdateien auf dem Server vor unbefugtem Zugriff ist daher besonders wichtig.

Neben der HTTP-Authentisierung existiert ein weiterer Weg, Zugriffskontrolle über das HTTP-Protokoll zu realisieren: die Authentisierung kann nicht über den Webserver selbst, sondern über eine serverseitige Anwendung durchgeführt werden. Dabei werden Benutzername und Passwort über normale HTML Formulare eingegeben und von der Anwendung überprüft. Dieses Verfahren ist häufig bei Internet-Angeboten realisiert. Es sollte jedoch stets beachtet werden, dass Passwörter oder PINs, die im Klartext über das Internet übertragen werden, leicht mitgelesen werden können. Zudem werden natürlich auch sämtliche Daten, selbst wenn sie auf authentisierte Anfragen hin ausgeliefert werden, unverschlüsselt übermittelt.

Manche Webangebote identifizieren die Benutzer über spezielle Cookies, die im Browser gespeichert werden. Da Cookies bei der Verwendung von HTTP ebenfalls im Klartext übertragen werden, ist diese Methode für die Authentisierung beim Zugriff auf schutzbedürftige Informationen ebenfalls nicht geeignet. Da im Zusammenhang mit Cookies noch weitere Sicherheitsprobleme existieren, sollte diese Methode generell nicht verwendet werden.

Verwendung von SSL

Wenn im Rahmen von E-Government- oder E-Commerce-Angeboten höhere Anforderungen an die Sicherheit der Authentisierung und die Vertraulichkeit der übertragenen Daten bestehen, dann sollte die Übertragung durch die Verwendung von SSL abgesichert werden (siehe auch M 5.66 Verwendung von SSL).

Bei der Verwendung von SSL gibt es zwei verschiedene Betriebsarten: bei der ersten Variante besitzt nur der Server ein Zertifikat. Dies dient dem Benutzer dazu, zu erkennen, dass er wirklich mit dem "richtigen" Server verbunden ist, und ermöglicht nach dem Aufbau einer verschlüsselten Verbindung die sichere Übertragung von Authentisierungsinformationen und Anwendungsdaten.

Ein Server-Zertifikat enthält neben dem Namen der Zertifizierungsstelle auch den Namen des Servers, für den es gültig ist. Es kann von einer Wurzelzertifizierungsstelle (Root-CA) ausgestellt sein oder auch selbst erzeugt werden, beispielsweise mit den im OpenSSL Paket enthaltenen Tools.

Zertifikate, die nicht von einer Wurzelzertifizierungsstelle ausgestellt wurden, die dem Browser bekannt ist, werden vom Browser meist nicht ohne weiteres akzeptiert, sondern der Benutzer muss explizit bestätigen, dass das betreffende Zertifikat akzeptiert werden soll.

Bei der zweiten Variante, verfügt auch der Benutzer über ein Zertifikat, das auf dem Client-Rechner vorhanden sein muss, und das der Browser zur Authentisierung an den Server schickt. Voraussetzung dafür ist jedoch, dass die Zertifizierungsstellen, deren Zertifikate verwendet werden, vertrauenswürdig sind. Dass diese Art der Authentisierung in der Praxis nicht häufiger verwendet wird, liegt an dem Aufwand, der zur Umsetzung einer solchen Lösung erforderlich ist. Die serverseitige Konfiguration ist relativ einfach: Neben der Konfiguration des Webservers für SSL muss ein SSL-Server-Zertifikat beschafft und implementiert werden. Der Aufwand, der für jeden einzelnen Benutzer zu betreiben ist, ist jedoch relativ hoch: Jeder Benutzer muss über ein SSL-Client-Zertifikat verfügen, das jeweils im Browser des Benutzers installiert ist. Dies führt zu einer gewissen Einschränkung der Bequemlichkeit, da einer der großen Vorteile der normalen Webserver-Nutzung gerade darin besteht, dass der Zugriff von praktisch jedem beliebigen Rechner aus erfolgen kann. Werden Client-Zertifikate zur Authentisierung benutzt, so ist diese Flexibilität deutlich eingeschränkt, weil das Client-Zertifikat meist nicht überall vorhanden ist. Andererseits kann in bestimmten Situationen, etwa beim Einsatz eines Intranet-Webservers, genau dies erwünscht sein.

Eine häufig verwendete Methode der Benutzerauthentisierung für Webangebote ist die Kombination von formularbasierter Authentisierung und SSL-verschlüsselter Datenübertragung. Diese Methode bietet, wenn die gewählte SSL-Verschlüsselung ausreichend stark gewählt wird, bei vertretbarem Aufwand (Benutzerverwaltung in der Webanwendung und Implementierung eines SSL-geschützten Zugriffs auf den Webserver) ein Sicherheitsniveau, das auch für höhere Sicherheitsanforderungen angemessen ist.

In M 5.160 Authentisierung gegenüber Webservern werden die verschiedenen Möglichkeiten der Benutzerauthentisierung bei Webservern vorgestellt und in der folgenden Tabelle zusammengefasst:
Methode Sicherheitsniveau Aufwand für Implementierung Serveranforderungen Kommentare
Standard-Authentisierung Niedrig Niedrig Benutzerverwaltung Authentisierungsinformationen und Daten werden unverschlüsselt übertragen!
Formularbasierte Authentisierung ohne gesicherte Übertragung Niedrig Niedrig bis mittel Implementierung in der jeweiligen Anwendung Authentisierungsinformationen und Daten werden unverschlüsselt übertragen!
Digest-Authenti-sierung Mittel Niedrig Benutzerverwaltung Daten werden unverschlüsselt übertragen.
Formularbasierte Authentisierung über SSL Hoch Mittel bis hoch SSL-Unterstützung im Server, Implementierung in der jeweiligen Anwendung Authentisierungsinformationen und Daten werden verschlüsselt übertragen!
Zertifikatbasierte Authentisierung über SSL Hoch bis sehr hoch Hoch bis sehr hoch Installation von Server-Zertifikaten. Zertifikatsverwaltung, Public-Key Infrastruktur. Wird hauptsächlich für sichere Transaktionen über das Internet verwendet.

Tabelle: Benutzerauthentisierung bei Webservern

Der Microsoft Internet Information Server bietet darüber hinaus noch eine weitere Methode, bei der die Windows-Benutzeranmeldung benutzt wird. Diese Methode funktioniert allerdings nur mit dem Microsoft Internet Explorer als Client.

Beim Aufbau einer SSL-Verbindung wird der zu verwendende Verschlüsselungsmodus zwischen Client und Server ausgehandelt. Unter den zur Verfügung stehenden Algorithmen befinden sich auch solche, die nicht mehr als sicher angesehen werden können. Insbesondere gibt es auch den so genannten Null-Encryption-Modus, bei dem keine Verschlüsselung stattfindet. Bei der Konfiguration des Webservers für die Verwendung von SSL muss darauf geachtet werden, dass der Server keinen der schwachen Algorithmen und insbesondere nicht den Null-Encryption-Modus akzeptiert. Andernfalls könnte es dazu kommen, dass scheinbar eine sichere Verbindung aufgebaut wird (es wird https verwendet), die jedoch in Wirklichkeit zu schwach oder gar nicht verschlüsselt ist. Eine solche Situation könnte von einem Angreifer bewusst herbeigeführt werden, um Authentisierungsinformationen und andere Daten abzuhören. Daher sollte in der SSL-Konfiguration des Webservers die Verwendung des Null-Encryption-Modus und der schwachen Algorithmen abgeschaltet werden.

Prüffragen:

  • Wurden/Sind die Authentisierungsmethode für Webangebote und die Gründe für deren Auswahl dokumentiert?

  • Digest-Authentisierung: Werden Passwortdateien auf dem Webserver vor dem Zugriff Unbefugter geschützt?

  • Bei hohen Anforderungen an die Vertraulichkeit: Wird die Authentisierung und die Übertragung von Daten bei Webangeboten durch SSL abgesichert?

  • Bei SSL -Verwendung: Werden schwache kryptographische Algorithmen vom Webserver nicht akzeptiert?

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