Sichere authentifizierung

[negaH]

Von CRAM-MD5 halte ich nicht viel. Eine MITMA, Man in the Midle Attack ist nicht ausgeschlossen noch überhaupt notwendig um die anschließende Komunikation zu belauschen. Denn diese ist ja im CRAM-MD5 STandard ja garnicht verschlüsselt. Eine Brute Force Attacke auf das Clientpassword ist ebenfalls nicht ausgeschlossen, denn alle Daten dafür stehen während einer Loginkommunikation zur Verfügung. Ein Verlust der Clientdatenbank auf dem Server kann ebenfalls für Offline Brute Force Angriffe benutzt werden. Desweiteren is CRAM-MD5 nur eine einseitige Authentifikation, der Server muß sich zb. nicht vor dem Client authentifizieren. Das ist eine enorme Lücke für MITMA Server Replacements Angriffe. CRAM-MD5 ist ein 3 Step Protokoll, im Gegensatz zu SRP das mathematisch gesehen ein 5 Step Protokoll ist. Das ist wichtig da bei diesen Steps immer nur Teilinformationen, die die vorherigen Steps aber benötigen, ausgetauscht werden.

All dies ist beim SRP ausgeschlossen, bzw. so schwierig das es praktisch nicht durchführbar ist. SRP ist ein sehr aktuelles Protokoll und setzt sich immer weiter durch. Immer mehr Standard Bibliotheken integrieren es in ihre APIs.

SRP benutzt intern ein modifiziertes Diffie Hellman Protokoll, arbeitet also mit einem mathematischen Zero Knownledge Verfahren. Nach einer erfolgreichen Authentifikation von Client beim Server und Server zum Client wurde autom. ein Shared Secret -> gemeinsammer Schlüssel berechnet. Mit diesem One Time Schlüssel, der zufällig gewählt ist, wird die nachfolgende Kommunikation verschlüsselt. Somit ist SRP nicht nur ein Passwort basiertes Authentifikations Protokoll sondern zusätzlich noch ein sicheres Schlüssel-Austausch-Protokoll. Wobei man das Wort "Austausch" nicht falsch verstehen sollte (kommt von Keyexchange), denn real einigen sich nur beide per mathematik auf ein und den selben Schlüssel ohne diesen real über eine Kommunikation austauschen zu müssen. Dh. dieser Schlüssel wird niemals übertragen und kann somit auch nicht von einem Lauscher abgehört werden.
Ein wichtiger Vorteil meiner SRP Version ist es das die Daten die kommuniziert werden keinerlei direkten Zusammenhang zu den berechneten Daten auf Client/Server seite haben. Somit ist sichergestellt das ein Lauscher nichts erfährt. Desweiteren sind die Clients in der Server Datenbank vollständig anonym. Ein Diebstahl dieser Datenbank durch Dritte wird nicht die Clients kompromittieren, im Gegenteil ist es sogar so das falls dieser sehr unwahrscheinliche Fall eingetreten ist und zudem noch der sehr sehr sehr unwahrscheinliche Fall das ein Hacker sich als regulärer Client ausgegeben hat, dann kann der reguläre Client dies autm. beim nächsten Login erkennen. Entweder er bekommt garkeinen Zugriff mehr, meil der Hacker sein eigenes Passwort benutzt hat, oder aber er sieht an Hand eines Counters das sich ein Anderer in der Zwischenzeit eingeloggt hat. Das und die Möglichkeit beim Counter-SRP zu jeder Zeit das Passwort zu wechseln ohne das dies der Server registrieren kann sind zwei ganz wesentliche Vorteile vom Counter-SRP zum original SRP-6a. Dh. selbst der Server wird quasi als Angreifer in meinem Protokoll betrachtet und das Protokoll weitestgehend auf diese Möglichkeit hin optimiert. Der Client kann anonym sein und die Sicherheit seiner Datensätze in der Serverdatenbank "verifizieren". Naja und dann noch die vielen anderen Angriffe, besonders solche die interleaved arbeiten werden ja schon vom SRP6a ausgeschlossen.
SRP ist meiner Meinung nach (und da bin ich nicht der Einzigste) als das bisher sicherste Login Protokoll betrachtet. Schau einfach mal in die sci.crypt Newsgroup rein.

Es gibt defakto nur EINE Angriffstelle, und das ist die Registration eines neuen Clients im Server. Diese Angriffsstelle existiert in jedem Protokoll, sofern dieses nicht über TrustCenter arbeitet das mit einer persönlichen Gegenüberstellung des potentiellen Clients beim TrustCenter arbeitet, zb. Ausweis bei der Deutschen Post vorzeigen usw. Aber auch an dieser Stelle habe ich in meinem SRP einige Protokolländerungen vorgenommen. Zb. kann ein Client erstmal als vorläufiger Registrations Datensatz durch den Server angelegt werden (der natürlich nicht alle Zugriffsrechte erhalten wird). Das ist möglich weil der Server ein zufälliges Registrationspasswort für den Client anlegen kann und mein Counter-SRP ja in jedem Login die Möglichkeit hat transparent und unbemerkbar für den Server ein neues Passwort zu wählen. Das ist so in SRP-6a nicht möglich, ein Clientdatensatz ist immer unveränderlich, readonly, und beim Counter-SRP wird bei jedem Login dieser Datensatz verändert (könnte Datenbankbezogen aber auch ein Problem darstellen).

Ich habe wie gesagt noch eine neuere Version hier rumliegen. Sie wurde primär auf Geschwindigkeit hin optimiert. Immerhin führt sie alle SRP Schritte ca. 16 mal schneller durch. Die Gesamtzeit eines SRP Logins dauert ca. 15 Millisekunden. Desweiteren bastle ich noch an einem SRP das in Elliptischen Kurven in GF(p) arbeitet. Dies wird den nötigen Datentraffic/Datenbankgrößen/Clientdatengrößen um das 3 bis 4 fache reduzieren, bei gleicher Sicherheit wohlgemerkt.

Gruß Hagen