© 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ü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.

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ü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.

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ü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.

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ü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.

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ü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

2 Gedanken zu „HTTPs: Unverzichtbar in der heutigen Zeit“

  1. Super visualisierte Erklärung, warum Verschlüsselung wichtig ist.

    Dank Let’s Encrypt bieten glücklicherweise immer mehr Hoster kostenlos an, auf HTTPS umzustellen 🙂

Schreibe einen Kommentar

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