© peshkova - Fotolia.com

HTTPs: Unverzichtbar in der heutigen Zeit

Sobald Passwörter zum Login für Webseiten verwendet werden, ist HTTPs unverzichtbar. Im Folgenden möchte ich aufzeigen, warum dem so ist! Ich beginne mit einer Übersicht der gängigsten Authentifizierungen für Web-Portale.

(1) Klartext Login

Die einfachste Variante: Der Login im Klartext.

Account anlegen

Der Benutzername und das Passwort werden im Klartext an den Server gesendet.

Plaintext Registration

Plaintext Registration

Anmeldung

Zur Anmeldung wird der Benutzername und das Passwort im Klartext an den Server gesendet.

Plaintext Login

Plaintext Login

Sicherheit

Die folgende Analyse wertet die Sicherheit des Verfahrens aus. Die Liste ist ein Auszug einiger wichtiger Sicherheitsparameter, jedoch nicht abschließend.

Klartextpasswort geschütztNein
Replay-Angriff verhindertNein. Wird das Passwort während der Anmeldung mitgeschnitten, kann dieses zum Login genutzt werden.
Login nach Kompromittierung der Datenbank verhindertNein. Das in der Datenbank gespeicherte Passwort kann zum Login verwendet werden.
Man-in-the-Middle verhindertNein. Es gibt keine Möglichkeit sicherzustellen, dass der Client direkt mit dem Server kommuniziert.

Fazit: Erhebliche Risiken; bietet über unverschlüsselte Kommunikationskanäle keinerlei Sicherheit.

(2) Client Hashed Password

Mein letzter Beitrag handelte von der Möglichkeit, den Hash des Benutzerpassworts bereits clientseitig generieren zu lassen. Die Vorteile liegen klar auf der Hand: Das eigentliche Passwort verlässt nicht den Client-PC, dies ist insbesondere sinnvoll, wenn Nutzer auf vielen Webseiten stets das selbe Passwort verwenden!

Account anlegen

Im Rahmen der Erstellung eines Accounts wird das Passwort um einen Zufallswert (Salt) erweitert, anschließend gehashed. Anschließend wird Benutzername und der Hash im Modular Crypt Format (MCF) an den Server gesendet. Der MCF-Hash enthält sowohl den Klartext-Salt, als auch den Hash, beides base64 codiert. Der Salt ist nicht geheimhaltungsbedürftig.

Client Hashed Registration

Client Hashed Registration

Anmeldung

Zur Anmeldung wird der Benutzername und MCF-Hash an den Server gesendet, dieser vergleicht die Daten der Anfrage mit seiner lokalen Datenbank.

Client Hashed Login

Client Hashed Login

Sicherheit

Eine kurze Analyse des zweiten Verfahrens

Klartextpasswort geschütztJa
Replay-Angriff verhindertNein. Wird der Hash während Anmeldung mitgeschnitten, kann dieser zum Login genutzt werden.
Login nach Kompromittierung der Datenbank verhindertNein. Der in der Datenbank gespeicherte Hash kann zum Login verwendet werden.
Man-in-the-Middle verhindertNein. Es gibt keine Möglichkeit sicherzustellen, dass der Client direkt mit dem Server kommuniziert.

Fazit: Schützt das Klartextpasswort, bietet aber keinerlei Schutz vor sonstigen Risiken.

(3) Challenge-Response

Bei diesem Verfahren wird versucht, das Risiko von Replay-Attacken zu vermindern. Das folgende Beispiel basiert auf dem Verfahren mit dem Klartext-Passwort.

Account anlegen

Die Account-Registrierung unterscheidet sich an dieser Stelle nicht von der Klartext-Registrierung.

Plaintext Registration

Plaintext Registration

Anmeldung

Das Anmeldeverfahren wird um Challenge-Response erweitert.

Challenge-Reponse Login

Challenge-Reponse Login

Sicherheit

Durch den sich stets ändernden Zufallswert ist ein erneutes Senden eines abgefangenen Passworts nicht ohne weiteres möglich. Gelingt es dem Angreifer die Registrierung mitzuschneiden, kann er selbst Hashes für jede beliebige Challenge erzeugen.

Klartextpasswort geschütztNein
Replay-Angriff verhindertJa, wenn das Passwort während der Registrierung nicht mitgeschnitten werden konnte.
Login nach Kompromittierung der Datenbank verhindertNein. Der in der Datenbank gespeicherte Hash kann zum Login verwendet werden.
Man-in-the-Middle verhindertNein. Es gibt keine Möglichkeit sicherzustellen, dass der Client direkt mit dem Server kommuniziert.

Fazit: Verhindert ausschließlich Replay-Angriffe. In der genannten Implementierung unsicher, da während der Registrierung das Passwort im Klartext übertragen werden muss.

(4) Challenge-Response + Client Hashed Password

Basierend auf den bisherigen Ergebnissen scheint es sinnvoll, die gerade genannten Verfahren 2 und 3 zu kombinieren.

Account anlegen

Die Account-Registrierung unterscheidet sich an dieser Stelle nicht von der oberen Registrierung.

Client Hashed Registration

Client Hashed Registration

Anmeldung

Eine Kombination aus beiden Verfahren.

Client Hashed Challenge-Reponse Login

Client Hashed Challenge-Reponse Login

Sicherheit

Sieht auf den ersten Blick etwas besser aus, krankt jedoch an den selben Problemen wie das Challenge-Response-Verfahren. Einzige Verbesserung: Das Klartext-Passwort verlässt zur keiner Zeit den Client.

Klartextpasswort geschütztJa.
Replay-Angriff verhindertJa, wenn das Passwort-Hash nicht während der Registrierung mitgeschnitten werden konnte.
Login nach Kompromittierung der Datenbank verhindertNein. Der in der Datenbank gespeicherte Hash kann zum Login verwendet werden.
Man-in-the-Middle verhindertNein. Es gibt keine Möglichkeit sicherzustellen, dass der Client direkt mit dem Server kommuniziert.

Fazit: Verhindert ausschließlich Replay-Angriffe. Vorteil: Passwort wird clientseitig verschlüsselt.

(5) Der "Standard": Server Hashed

Das Verfahren beschreibt die im Internet am häufigsten vorgefundene Variante: Das Passwort wird im Klartext versendet und erst serverseitig zu einem Hash verarbeitet.

Account anlegen

Der Benutzername und das Passwort werden im Klartext an den Server gesendet. Auf dem Server wird das Passwort als Hash gespeichert.

Server Hashed Registration

Server Hashed Registration

Anmeldung

Der Benutzername und das Passwort werden im Klartext an den Server gesendet. Auf dem Server wird das Passwort gehashed und mit dem gespeicherten Hash der User-Datenbank verglichen.

Server Hashed Login

Server Hashed Login

Sicherheit

Einziger Vorteil: Da das Passwort nicht im Klartext auf dem Server liegt, kann das Passwort im Falle einer Kompromittierung der User-Datenbank nicht im Klartext ausgelesen werden. Dieses Verfahren bedingt der Verwendung eines starken Hash-Algorithmus.

Klartextpasswort geschütztNein, dass Passwort kann während der Anmeldung im Klartext mitgeschnitten werden.
Replay-Angriff verhindertNein. Wird das Passwort während Anmeldung mitgeschnitten, kann dieses zum Login genutzt werden.
Login nach Kompromittierung der Datenbank verhindertJa. Der in der Datenbank gespeicherte Hash kann nicht direkt zum Login verwendet werden.
Man-in-the-Middle verhindertNein. Es gibt keine Möglichkeit sicherzustellen, dass der Client direkt mit dem Server kommuniziert.

Fazit: Vermindert ausschließlich die Risiken nach einer Kompromittierung der User-Datenbank, sonst schwach. Wird das Passwort in der URL mitgegeben, so erscheint das Passwort im Klartext in jeder Logdatei.

(6) Kombination verschiedener Verfahren

So recht sicher ist keines der bisher genannten Verfahren. Der Versuch, die genannten Vorteile zu kombinieren, bietet nur wenig zusätzliche Sicherheit. Selbst wenn dies gelingen sollte, gehen die Probleme im Rahmen der authentifizierten Session weiter:

  • Wie kann sichergestellt werden, dass die Nutzdaten der Session unterwegs nicht verändert wurden?
  • Wie kann sichergestellt werden, dass die Nutzdaten vertraulich bleiben?
  • Wie kann sichergestellt werden, dass die authentifizierte Session nicht einfach übernommen wird (Session Hijacking)?

Die Fragestellungen lassen sich beliebig erweitern. Wird versucht, jedes der Probleme einzeln zu beheben, entsteht eine große Komplexität innerhalb der Programmierung. Die Wahrscheinlichkeit, dass die Implementierung fehlerhaft ist, steigt mit zunehmender Komplexität und Umfang an. Generell wird davon abgeraten, eigene Protokolle zur Sicherheit zu entwerfen.

Die Lösung: https

HTTPs bietet unzählige Möglichkeiten, einen Großteil der genannten Risiken zu minimieren. Das Anbieten einer Webseite mit einem geschützten Bereich ohne Verschlüsselung ist in der heutigen Zeit fahrlässig. Gleiches gilt, wenn auf der Webseite persönliche Daten wie Mailadressen eingegeben werden sollen. HTTPs ist leicht zu implementieren und bietet einen guten Grundschutz gegen zahlreiche Angriffsvarianten.

Ich persönlich würde eine Kombination des Client- und Server-Hashed-Passwort-Verfahrens nutzen. Das Passwort sollte lokal gehashed werden, der Hash anschließend auf der Datenbank ein weiteres mal gehashed werden. Die Vorteile liegen auf der Hand:

Klartextpasswort geschütztJa, aufgrund des Client Hashed Verfahrens.
Replay-Angriff verhindertJa, aufgrund HTTP über TLS.
Login nach Kompromittierung der Datenbank verhindertJa, aufgrund des Server Hashed Verfahrens.
Man-in-the-Middle verhindertGefahr aufgrund HTTP über TLS reduziert.

Kurz: Bietet euren Nutzern die Möglichkeit, Webseiten über https zu erreichen. Jeglicher Versuch, Aufgaben von https in eigene Implementierungen zu legen, erhöht die Komplexität und die Gefahr von sicherheitsrelevanten Risiken. Strenggenommen würde dies auch für den Client-seitigen-Hash gelten, hier muss jeder Entwickler selbst eine Entscheidung treffen. Passwörter sollten jedoch niemals im Klartext gespeichert werden. Die Beispielimplementierung von mir auf Github nutzt server- und clientseitiges Hashen mit bCrypt.


Bildnachweise:

  • Beitragsbild: © peshkova - Fotolia.com
Ähnliche Artikel:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.