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.

Anmeldung

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

Sicherheit

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

Klartextpasswort geschützt	Nein
Replay-Angriff verhindert	Nein. Wird das Passwort während der Anmeldung mitgeschnitten, kann dieses zum Login genutzt werden.
Login nach Kompromittierung der Datenbank verhindert	Nein. Das in der Datenbank gespeicherte Passwort kann zum Login verwendet werden.
Man-in-the-Middle verhindert	Nein. 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.

Anmeldung

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

Sicherheit

Eine kurze Analyse des zweiten Verfahrens

Klartextpasswort geschützt	Ja
Replay-Angriff verhindert	Nein. Wird der Hash während Anmeldung mitgeschnitten, kann dieser zum Login genutzt werden.
Login nach Kompromittierung der Datenbank verhindert	Nein. Der in der Datenbank gespeicherte Hash kann zum Login verwendet werden.
Man-in-the-Middle verhindert	Nein. 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.

Anmeldung

Das Anmeldeverfahren wird um Challenge-Response erweitert.

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ützt	Nein
Replay-Angriff verhindert	Ja, wenn das Passwort während der Registrierung nicht mitgeschnitten werden konnte.
Login nach Kompromittierung der Datenbank verhindert	Nein. Der in der Datenbank gespeicherte Hash kann zum Login verwendet werden.
Man-in-the-Middle verhindert	Nein. 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.

Anmeldung

Eine Kombination aus beiden Verfahren.

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ützt	Ja.
Replay-Angriff verhindert	Ja, wenn das Passwort-Hash nicht während der Registrierung mitgeschnitten werden konnte.
Login nach Kompromittierung der Datenbank verhindert	Nein. Der in der Datenbank gespeicherte Hash kann zum Login verwendet werden.
Man-in-the-Middle verhindert	Nein. 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.

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.

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ützt	Nein, dass Passwort kann während der Anmeldung im Klartext mitgeschnitten werden.
Replay-Angriff verhindert	Nein. Wird das Passwort während Anmeldung mitgeschnitten, kann dieses zum Login genutzt werden.
Login nach Kompromittierung der Datenbank verhindert	Ja. Der in der Datenbank gespeicherte Hash kann nicht direkt zum Login verwendet werden.
Man-in-the-Middle verhindert	Nein. 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ützt	Ja, aufgrund des Client Hashed Verfahrens.
Replay-Angriff verhindert	Ja, aufgrund HTTP über TLS.
Login nach Kompromittierung der Datenbank verhindert	Ja, aufgrund des Server Hashed Verfahrens.
Man-in-the-Middle verhindert	Gefahr 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