Immer mehr Dienstanbieter und auch Unternehmen setzen im Rahmen der Digitalisierung auf mehr Webanwendungen. Hier gilt es im Besonderen, seine eigenen Dienstleistungen den Kunden und Webbesuchern anbieten zu können. Unternehmen und auch die Industrie selbst setzen aber ebenfalls auch auf Webanwendungen, beispielsweise im Servicebereich der eigenen Mitarbeiter. Hier müssen nicht selten auch sensible und datentechnische Informationen sicher zwischen den Systemen übertragen werden. Dies erfordert in der Regel eine sichere und verschlüsselte Übertragung von Daten und den Login-Informationen der Benutzer.
Besonders bewährt und häufig verwendet wird eine besondere Methode in der HTTP-Authentifizierung, die jene bisher eingesetzte Standard-Authentifizierung sinnvoll und leistungsstark erweitert. Wird beispielsweise bei der Standard-Authentifizierung (Basic-Auth) das Kennwort im Rahmen einer HTTPS-Übertragung noch als Klartext-Eintrag übertragen, verwendet das optimierte Digest-Auth eine auf kombinierten Hash-Werten basierte Verschlüsselung und Authentifizierung, was ein Plus an Sicherheit und Zuverlässigkeit bietet. Zudem wird ein mehrfaches Austauschverfahren etabliert, was die Datensicherheit weiter stärkt.
Die Funktionsweise von Digest-Auth
Inzwischen findet man zwar verschiedene Authentifizierungsverfahren wie beispielsweise auch OAuth 2.0 auf dem Markt. Je nach Einsatzbereich und verfügbare Ressourcen wählt man hier aber dann das für seine Bedürfnisse optimale Verfahren. Mit HTTP-Digest-Auth steht ein einfaches, aber sehr leistungsstarkes Verfahren für die allermeisten Anwendungssituationen zur Verfügung. Die Funktionsweise ist einerseits sehr einfach und transparent aufgebaut. Auf der anderen Seite ist für die meisten Sicherungsaufgaben ein ausreichender Schutz bei vergleichsweise wenig Ressourcenverbrauch vorhanden.
Wenn Sie in einem Browser eine gültige URL eingetragen und versendet haben, wird der empfangende Server Ihre Zugriffsberechtigung abfragen und prüfen. Wurde die Ressource als geschützt deklariert, wird in einem nächsten Schritt eine entsprechende Authentifizierung vom Absender angefragt. Der Server-Response-Header sieht dann beispielsweise wie folgt aus:
HTTP/1.1 401 Unauthorized
Date: Fri, 14 Dec 2018 09:22:16 GMT
WWW-Authenticate: Digest
realm="beispielrealm@domain.com",
qop="auth,auth-int",
nonce="dcd90c0938b7102dd2f0e8b11d0f600bfb",
opaque="069c403ebaf95ccc f0171e9517f40e41"
...Ein wichtiges Element stellt dabei der Schlüssel „WWW-Authenticate:“ dar. Mit dem Wert „Digest“ wird das erweiterte Authentifizierungsverfahren angefordert. Ein weiterer wichtiger Parameter ist der NONCE-Wert. Dieser Wert ist eine zufällig gewählte Zeichenfolge, die im weiteren Verlauf mit in das Verschlüsselungsverfahren aufgenommen wird. Der verwendete Browser berechnet nun aus den Parametern Benutzername, Passwort, angeforderte URL, verwendete http-Methode und den NONCE-Wert einen Hash-Wert. Im Authorization-Header wird dieser Wert dann an den Server zur Authentifizierung zurückgesendet.
Mit dem Parameter „OPAQUE“ sendet der Authentifizierungsserver eine weitere Zeichenfolge als vergleichsweise „Garderobenmarke“. Diese Zeichenfolge sollte vom Clientbrowser auch wieder unverändert mit zurückgesendet werden. Die Berechnung des Hashwertes folgt dabei nun nach einem bestimmten Schema unter Verwendung von 16-Byte-Variablen wie HA1 und HA2, wie in der folgenden Ablaufsequenz ersichtlich wird:
Start-Hashwertbildung =>
HA1 = MD5(Nutzername: Realm: Passwort)
HA2 = MD5(Methode: digestURI)
RESPONSE = MD5(HA1: nonce: HA2)Bei diesem Schema ist jedoch zu beachten, dass sowohl der Benutzername als auch das Kennwort hier nicht verschlüsselt werden, sondern nur mit der Methode MD5() kodiert werden. Theoretisch ist damit eine Rekonstruktion möglich. Aus Sicherheitsgründen kann bei Verwendung dieser Methode jedoch auf die Übertragungsmethode HTTPS zurückgegriffen werden.
Für eine Übertragung kann der Server dem Client jedoch auch noch weitere Schemas zur Authentifizierung anbieten, wie in der folgenden Auflistung gezeigt:
-
Anonym: enthält keine Authentifizierungsinformationen und dient daher als universelle Freigabe für alle Anfragen.
-
Basic: wurde im obigen Beispiel als Standard-Authentifizierung vorgestellt. Hier muss eine Kombination aus Benutzername und Passwort vergeben sein. Detailliertere Informationen hierzu finden Sie in unserem technischen Artikel unter HTTP Basic Auth.
-
NTLM: verwendet eine nochmals sicherere Variante der Digest-Authentifizierung und verwendet die Windows-Anmeldeinformationen zur Freigabe.
-
Negotiate: bietet eine automatisierte Auswahl von entweder dem NTLM-Schemata oder dem Kerberos-Protokoll. Die Auswahl wird automatisch und je nach Verfügbarkeit ausgewählt.
Fazit
Trotz weiterer Anmelde- und Authentifizierungsverfahren wie OAuth2 oder Single Sign-On können mit dem Standard-Anmeldeverfahren HTTP-Digest-Auth in Verbindung mit dem HTTPS-Protokoll sehr sichere Übertragungs- und Anmeldeverfahren eingesetzt werden. HTTP-Digest-Auth ist ressourcenschonend einzusetzen und sollte für die meisten Anwendungsfälle auch vollkommen ausreichen. Der insgesamt geringe Overhead und die sehr weit verbreitete Implementierung auf Client-/Serversystemen erleichtert die Verwendung zusätzlich und stellt damit auch eine gewisse Standardisierung dar.
Positiv hervorzuheben ist die Tatsache, dass der RFC von HTTP-Digest-Auth noch weitere Funktionen anbietet, um die Sicherheit signifikant zu erhöhen. Eine Möglichkeit ist dabei, den NONCE-Parameter bei jeder Anfrage zu ändern. Weiterhin kann man in den NONCE-Wert auch einen Zeitstempel integrieren. Damit kann der Server die NONCE-Attribute des Clients jederzeit auf Aktualität und Originalität prüfen, was den Sicherheitsaspekt zusätzlich stärkt und die Möglichkeit von wiederholten Angriffen reduziert. Werden diese zusätzlichen Aspekte mit einer verschlüsselten Übertragungsmethode mit HTTPS kombiniert, sollte ein ausreichender Sicherheitsschirm aufgespannt werden können.