Sind Passwörter und Authentifizierungsprotokolle wirklich sicher? Nicht immer.

Werfen wir einen näheren Blick auf die Protokolle und ihre Schwachstellen.

Als Authentifizierung bezeichnet man den Vorgang der Identitätsprüfung eines Benutzers, der sich mit einem System verbinden möchte. Wie effektiv dieser Prozess ist, ergibt sich aus den verwendeten Authentifizierungsprotokollen und -mechanismen. Nachfolgend betrachten und bewerten wir einige der Authentifizierungsarten, um zu sehen, welche von ihnen wirklich sicher sind.

Einfaches HTTP

Die erste SIP-Version verwendete die einfache HTTP-Authentifizierung. Dieses Verfahren ist relativ einfach über Man-in-the-Middle-Angriffe angreifbar. Diese Form der Benutzerauthentifizierung verliert daher seit geraumer Zeit an Bedeutung.

Bei der HTTP-Authentifizierung kann ein Angreifer problemlos ein Paket, welches das Passwort enthält und base64-kodiert ist, abfangen, damit die Dekodierung durchführen und Angriffe ausführen.

→ Nicht wirklich sicher!

Digest-Authentifizierung

Die Digest-Authentifizierung, die sowohl von SIP als auch von HTTP verwendet wird, bietet die Fähigkeit, nur die verschlüsselte Version des Passworts auf dem Server zu speichern. Dies verhindert, dass der Client das Passwort in einem leicht dekodierbaren Format sendet, und es ermöglicht dem Server, einen Hash des Passworts zu speichern (der nicht leicht dekodierbar ist).

Betrachten wir im Einzelnen, wie Nachrichten zwischen Client und Server ausgetauscht werden:

Der Server fordert eine Authentifizierung an:

Der Client fügt die Authentifizierungsinformationen hinzu:

Der „Antwort“-Wert („response“) wird in drei Schritten wie folgt berechnet (werden Werte kombiniert, sind sie durch Doppelpunkte voneinander getrennt):

1. 1. Der MD5-Hash der Kombination aus Benutzernamen, Authentifizierungsbereich und Passwort wird berechnet. Das Ergebnis wird als HA1 bezeichnet.
   2. Der MD5-Hash der Zugriffsmethode kombiniert mit dem Digest-URI wird berechnet (z.B. „GET“ und „/dir/index.html“). Das Ergebnis wird als HA2 bezeichnet.
   3. Der MD5-Hash wird aus dem kombinierten HA1-Ergebnis, Server-Nonce (nonce), Request-Zähler (nc), Client-Nonce (nonce), Quality-of-Protection Code (qop) und HA2-Ergebnis berechnet. Das Ergebnis ist der vom Client bereitgestellte „Antwort“-Wert.

Die Verwendung dieser Methode hat folgende Vorteile:

• Das Passwort wird nicht direkt im Digest verwendet, sondern vielmehr HA1 = MD5 (username:realm:password). Dies ermöglicht es einigen Implementierungen, HA1 anstelle des Klartextpassworts zu speichern.
• Die Client-Nonce ermöglicht es dem Client, Chosen-Plaintext-Angriffe zu verhindern, die andernfalls die Digest-Authentifizierungsschemata gefährden könnten.
• Die Server-Nonce darf Zeitstempel enthalten, d.h. der Server kann die von Clients übermittelten Nonce-Attribute prüfen, um Replay-Angriffe zu verhindern.
• Der Server darf auch eine Liste der zuletzt ausgegebenen oder verwendeten Server-Nonce-Werte führen, um eine Wiederverwendung zu verhindern.

→ Digest stellt zwar einen Fortschritt dar, hat aber immer noch erhebliche Nachteile.

Das Hauptproblem dabei sind Man-in-the-Middle-Angriffe. Um Digest sicher zu machen, muss die Verbindung zwischen Client und Server verschlüsselt und der Server-Schlüssel vorinstalliert werden, oder es muss eine Zertifizierungsstelle verwendet werden, die es dem Client ermöglicht, den öffentlichen Schlüssel des Servers zu überprüfen.

SCRAM

XMPP unterstützt Klartext, Digest Passwort Austausch und auch SCRAM (Salted Challenge Response Authentication Mechanism). SCRAM bietet gegenüber Digest Vorteile, da es dem Server ermöglicht, Passwort-Hashes in einem irreversiblen Format zu speichern. Diese Funktion schützt vor Offline-Angriffen auf die Passwort- und Benutzerdatenbank. Der Client kann zudem eine Hash-Version des Passworts speichern, was es Angreifern (die Zugriff auf den PC haben könnten, auf dem das Passwort gespeichert ist) erschwert, das Passwort im Klartextformat zu interpretieren

Darüber hinaus schützt SCRAM vor Man-in-the-Middle-Angriffen, sofern Zertifikate verwendet werden. Dies geschieht, indem der Server dem Client nachweisen kann, dass nicht nur das Zertifikat von einer CA (Certification Authority) signiert wurde, sondern dass er das Passwort auch kennt. Diese Funktion wird als Kanalbindung bezeichnet, da der untere Verschlüsselungskanal an den höheren Anwendungskanal „gebunden“ wird. Es bietet auch zusätzliche Sicherheit im Vergleich zu TLS, die bei Klartext- und Digest-Authentifizierung fehlt.

In der Kryptographie ist der Salted Challenge Response Authentication Mechanism (SCRAM) eine Familie von modernen, passwortbasierten, Challenge-Response-Authentifizierungsmechanismen, die die Benutzerauthentifizierung zu einem Server ermöglichen. Wie für Simple Authentication and Security Layer (SASL) definiert, kann es für passwortbasierte Anmeldungen an Diensten wie SMTP und IMAP (E-Mail) oder XMPP (Chat) verwendet werden. Für XMPP ist die Unterstützung von SCRAM zwingend erforderlich.

Stärken des SCRAM:

• Sichere Passwortspeicherung: Bei richtiger Implementierung kann der Server die Passwörter in einem „gesalzenen“, iterierten Hash-Format speichern, was Offline-Angriffe erschwert und die Auswirkungen von Datenbanklecks verringert.
• Einfachheit: Die Implementierung von SCRAM ist einfacher als bei DIGEST-MD5.
• Internationale Interoperabilität: Die RFC verlangt, dass UTF-8 statt CRAM-MD5 für Benutzernamen und Passwörter verwendet wird.
• Da nur die „gesalzene“ und gehashte Version eines Passworts im gesamten Anmeldeprozess verwendet wird und das „Salz“ auf dem Server unverändert bleibt, kann ein vom Client gespeichertes Passwort die „gehashten“ Versionen verwenden, ohne das Klartextpasswort Angreifern zugänglich zu machen. Solche Hash-Versionen sind an einen Server gebunden und eignen sich daher ideal für die Wiederverwendung von Passwörtern.

Schlussfolgerung

HTTP, XMPP und SIP mit Digest-Authentifizierung bieten grundlegenden Schutz und sind nur anfällig für:

• Offline-Angriffe: Das bedeutet, dass ein Backup oder eine Kopie der Datenbank, in der die Login-Daten und Passwörter gespeichert sind, von einem Angreifer beschafft wird.
• Man-in-the-Middle-Angriffe: ist beschränkt auf eine Sitzung, da die Verwendung von Digests vor der Wiederverwendung von Hash-Dateien schützt.

Offline-Angriffe werden durch die Anwendung starker Hash-Funktionen, wie sie beispielsweise in der SHA2-Familie enthalten sind, entschärft.

Um die Kommunikation nicht nur bei der Authentifizierung, sondern auch zum Schutz der ausgetauschten Daten sicher zu machen, muss ein gesichertes Signalisierungsprotokoll (TLS) verwendet werden. Leider erzwingen viele verfügbare UC-Systeme diese Funktion standardmäßig nicht.

XMPP verfügt über einen verbesserten Authentifizierungsmechanismus über SCRAM. Dieser bietet einen deutlich verbesserten Schutz vor Offline-Angriffen, Man-in-the-Middle-Angriffen und TLS-Zertifikatsschmieden. SCRAM setzt auf eine sichere Transportschicht.

Es gibt Vorschläge (RFC 7804), auch SCRAM über HTTP zu unterstützen. Bis dahin kann die gleiche Verbesserung, die SCRAM gebracht hat, von Webentwicklern bei der Implementierung der UC-Plattform separat realisiert werden.

Möchten Sie mehr wissen? Abonnieren Sie das kostenlose Wildix Magazin, um es alle drei Monate direkt auf Ihren Schreibtisch zu erhalten Wildix Magazin