Die MITMA ist ausgeschlossen, ansonsten würde SRP keinen Sinn machen, und viele andere Protokolle ebenfalls nicht.
Und es geht indem man Kryptographie benutzt. Genauer gesagt benutzt man die Technik des "Zero Knownledge" Protokolls. Dabei geht es darum wie man beweisen kann das man ein Geheimnis kennt OHNE dieses Geheimnis verraten zu müssen.
Also wenn es ein Verfahren gibt mit bei dem ich sage "Ich weis ein Geheimnis und kann dies dir beweisen OHNE das DU mein Geheimnis kennen musst" dann nennt sich das "Zero Knownledge", da DU keinerlei Informationen von mir über das Geheimnis selber erhältst. Wenn du aber keine Informationen über mein Geheimnis von mir erhälst so impliziert die auch das kein Anderer Informationen über mein Geheimnis erhält, also auch nicht der böse MITMA.
Es hört sich im ersten Moment als eine Unmöglichkeit an ist aber dank schlauer Mathematiker tatsächlich machbar.
SRP baut darauf auf oder Diffie Hellman Schlüssel Austausch baut indirekt darauf auf.
Allerdings gibt es tatsächlich einen, und einzisgten Zeitpunkt in dem eine MITMA möglich ist, immer, und bei jedem Protokoll. Nämlich der allererste Schritt in dem ein Client beim Server als berechtigter Client registriert wird. Bei jedem Protokoll ist dies eine Schwachstelle und lässt sich im Grunde nur durch eine Dritte Partei -> Trust Center oder direkte Authenfikation (persönlich) lösen.
Wurde dieser erste Schritt sicher abgearbeitet dann sind alle nachfolgenden Schritte garantiert MITMA sicher.
In diesem ersten Schritt ist es über das Zero Knownledge nun möglich das der Server und Client einen sogenannten Verifier vereinbaren/austauschen der denoch nichts über das Geheimnis=Password aussagt. Ganz stimmt diese Aussage aber nicht
Denn korrekt betrachtet ist der Verifier eine Zahlenmäßige Umformung diese Passwortes die mit heutigem Wissen und technologischen Möglichkeiten nicht in das Passwort zurückgerechnet werden kann. Dieser Verifier wird nun zb. im laufenden Protokoll des SRPs niemals übertragen. Der Client/Server können sich aber denoch mit Hilfe des Zero Knownledge gegenseitig davon überzeugen das der jeweils andere diesen Verifier kennt.
Der Client wird einfach mit Hilfe vom SRP aus seinem Password diesen Verifier reproduzieren, der Server hat den Verifier gespeichert. Beide tauschen beim Login nun verschiede Werte untereinander aus die dann indirekt einen Beweis ergeben das der jeweils andere den Verifier kennen muß.
Man geht dabei immer davon aus das sowohl der Client wie auch der Server sicher sind. Wurde also ein Server kompromittiert und hijacked dann ist natürlich eine MITMA möglich. Politisch betrachtet ist das auch ein Grund warum in Deutschland per Verordnung ein Provider gesetzlich verpflichtet ist eine Standleitung zum BND einzurichten, quasi jeder Provider hijacked werden kann. Allerdings trifft dies eben nicht auf Endstellen zu, also Clients und Clients die als Server arbeiten. Und gerade deswegen ist es gut das es solche Protokolle gibt, sie verhindern nämlich eine MITMA effizient.
Bei SRP geht man noch einen Schritt weiter. Im Verlauf des Protokolls authentifizieren sich der Client und Server gegenseitig und erzeugen nebenbei sogar noch ein sogenanntes "shared Secret", einen gemeinsammen Schlüssel. Mit diesem kann dann später ohne Probleme die Kommunikation verschlüsselt werden. Bei diesem Schlüsselaustausch, bei dem keine Schlüssel "ausgetauscht" werden, sondern beide zur gleichen Zeit einen gemeinsammen Schlüssel berechnen, werden wiederum keine nützlichen Informationen übertragen die Rückschlüsse auf diesen Schlüssel ergeben. Ein MITMA kann also nicht diesen Schlüssel durch Lauschen nachberechnen.
Dieser Schlüssel ist dann auch noch zufällig gewählt, und verhindert durch seine binäre Größe jede Brute Force Attacke.
Mein Counter-SRP geht noch par Schritte weiter als Standard SRP. Counter-SRP ermöglicht es zu jedem Login ein neues Password zu vereinbaren ohne das dies übertragen wird und ohne das der Server wissen kann wie das Password lautet oder sogar mit der noch restriktiveren Einschränkung das der Server noch nichtmal in der Lage ist zu erkennen OB das Passwort geändert wurde oder nicht !
Einzigst der Server, als böser Server, wäre in der Lage eine Brute Force Attack auf das Client-Passwort durchzuführen. Allerdings bei gutem Passwort und öfterer Änderungen des Passwortes ist das praktisch nicht machbar.
Desweiteren benutzt Counter-SRP noch nichtmal einen lesbaren Client Namen. D.h. Counter-SRP könnte völlig anonyme Clients verwalten. Selbst wenn also der Server gestohlen würde so wüssten die Angreifer nicht welcher Datenbank-Record zu welchem Clienten gehört. Das ginge wiederum nur durch eine Brute Force Attacke oder besser per Dictionary Attack -> Wörterbuch Angriff. Selbst wenn dies erfolgreich machbar wäre dann muß man immer noch das Clientpasswort per Brute Force Attacke brechen. Allerdings geht dies diesesmal nicht mehr per Dictionary Attack, der Angreifer muß also für jedes Paswort real eine komplette Brute Force Attack durchführen. Das wären bei meinem Counter-SRP also 2^256 * Password_Länge_In_Bits Kombinationen die man durchprobieren muß !
Gruß Hagen