Benutzerdaten einer Website - weg von MD5

[DGL-luke]

Zitat:

ohje ohje... was das denn?
sorry, aber es ist ja wohl mit das leichteste, E-Mails abzufangen...
damit erzeugst du eine race-condition, die ein Man-in-the-Middle jedes Mal gewinnen kann...
wer hindert ihn daran, den registrierungsprozess für den eigentlichen Benutzer fortzuführen?

Und wenn die emails mit pgp (also asynchron) verschlüsselt sind?
Damit kriegt pgp den schwarzen peter, und ich denke, damit kommt es klar ^^

[Meflin]

Zitat von DGL-luke:

Und wenn die emails mit pgp (also asynchron) verschlüsselt sind?
Damit kriegt pgp den schwarzen peter, und ich denke, damit kommt es klar ^^

... und deine potentiellen Benutzer brauchen erstmal die passende Software (die noch dazu alles andere als weit verbreitet ist). Damit kannst du deine Webseite so gut wie dicht machen.

[Chewie]

Ob PGP oder Zertifikate - das Grundproblem wird nur verschoben:

Woher willst du wissen, dass ein öffentlicher Schlüssel wirklich authentisch ist?

[cware]

Zitat von Chewie:

Ob PGP oder Zertifikate - das Grundproblem wird nur verschoben:

Woher willst du wissen, dass ein öffentlicher Schlüssel wirklich authentisch ist?

durch abfrage des öffentlichen schlüssels bei einem Trusted Certificate Issuer...
aber auch da gilt wieder: bin ich wirklich mit dem richtigen verbunden, oder stecke ich grad in einer man-in-the-middle attack...


cheers...

[Chewie]

Zitat von cware:

Zitat von Chewie:

Ob PGP oder Zertifikate - das Grundproblem wird nur verschoben:

Woher willst du wissen, dass ein öffentlicher Schlüssel wirklich authentisch ist?

durch abfrage des öffentlichen schlüssels bei einem Trusted Certificate Issuer...
aber auch da gilt wieder: bin ich wirklich mit dem richtigen verbunden, oder stecke ich grad in einer man-in-the-middle attack...

Richtig, und darüber hinaus musst du diesem vertrauen. Hat er dieses Vertrauen verdient?

[bigg]

Meine Güte, macht euch nicht ins Hemd. Behörden, Banken und Unternehmen gehen wesentlich schlampiger mit euren Daten um, als so manche Forensoftware und dabei kostet es auch noch euer Geld. Ich bin der Meinung, dass man ein gesundes Mittelmaß zwischen Sicherheit und Komfort finden sollte/ muss. Und das ist aktuell in der Version 3 von phpbb doch gegeben.

[negaH]

Irgendein Kryptologe sagte mal: TrustCenter bedeutet Vertrauenszenter und das bedeutet das es die einzigste Instutition ist die das Vertrauen der Kunden mißbrauchen kann. Das ist keine Sicherheit !

Zitat:

Was meinst du "sein reales Passwort"? Das Passwort, das er gerne haben würde? Und wie trägt er dieses auf dem Server ein, ohne es zu übertragen?

Das ist ja der Trick

1.) bei einem guten Passwortbasiertem Loginsystem wird das Passwort niemals über das INet übertragen. Übertragen werden durch mathematische Verfahren "umgewandelte" Daten, könnte man als "Prüfsummen" betrachten. Man macht quasi einen Diffie Hellman Schlüsselaustausch. Nun und dieses Wort "Schlüssel-austausch" suggeriert einen Austausch von Schlüsseln das ist aber falsch. In Wahrheit ist es eine gemeinsamme Schlüsselvereinbarung ohne das man irgendwelche Daten übertragen muß die sich auf den später vereinbarten und gemeinsam berechneten Schlüssel zurückberechnen lassen. Schau dir das Diffie Hellman Verfahren an.

2.) beim SRP liegt also auf dem Server nur ein Zertifikat das nur durch den Benutzer mit dem korrekten Passwort errechnet werden kann. Dieses Zertifikat wird mit Diffie Hellman geschützt übertragen, bzw. es ist defakto ein Bestandteil des modifizierten Diffie Hellmans beim SRP.

3.) Man kann SRP nun so umbauen das es im gleichem Atemzug seines Protokolles eine neues Zertifikat geschützt überträgt.

4.) dieses Zertifikat eines Passwortes besteht als Grundlage der Berechnung aus dem Benutzerpasswort und einem Zufallssalt -> ergo das Zertifikat ist pseudozufällig.

5.) Würde man ein neues Zertifikat vom gleichen Passwort erzuegen so benutzt man ja immer einen anderen Zufallssalt, ergo: das neue Zertifikat unterscheidet sich zum alten Zertifikat (binär betrachtet) und denoch athentifizieren sie das gleiche Passwort

6.) man kann nun das neue Zertifikat mit dem alten Passwort erzeugen oder gleich ein neues Passwort benutzen.

7.) der Server authentifiziert also das alte Zertifikat des Benuters und bekommt im gleichen Atemzug ein neues Zertifikat übermittelt. Dieses wird der Server in seiner Datenbank bei erfolgreichem Login anstelle des alten Zertifikates abspeichern. Da der Server das reale Passwort nicht kennt und immer bei den Berechnungen ein Zufallsalt mit einberechnet wurde, kann der Server nicht unterscheiden ob zwei verschiedene Zertifikate zum gleichen Passwort gehören oder zu zwei unterschiedlichen Passwörtern.

8.) man kann SRP also so abändern das ein Benutzer sich in den selben Protokolschritten beim Server mit einem alten Passwort authentifiziert und gleichzeitig ein neues Zertifikat eines neuen oder eben des alten Passwortes übermittelt. Damit kann der User bei jedem Login sein Passwort ändern ohne das man an Hand der übermittelten Daten oder der gespeicherten Daten auf dem Server erkennen kann ob er sein altes Passwort weiterbenutzt oder ein neues registriert.

Hier mal mal die Protokollschritte dieses geänderten SRPs, ich nenne ihn Counter-SRP.

Delphi-Quellcode:

(*
Counter-SRP-6

SecureBits            = integer
MGF([data])           = hash based Mask Generation Function, creates SecureBits length result
                        from a set of input parameters
MGF([data], index)    = MGF with Index > 0
OTP(data, key, index) = hash based One Time Pad, use an indexed KDF
RND()                 = secure random generator, produce SecureBits result

Name                  = plaintext Name of Client
I                     = Identifier of Client
S,S'                  = random Password Salt, SecureBits long
Sp                    = public OTP encrypted Salt
V,V'                  = Password Verifier
Vp                    = public OTP encrypted Verifier
P,P'                  = client passwords, old and new
C                     = incremental Counter, 32 Bits long, used as Index in the MGF
N                     = large Safe Prime, so called Sophie Germain Prime
g                     = Generator, > 3
k                     = hased security value
ID                    = string thats represent N,g,k in safe reproducible manner
b,B                   = ephemeral server keys, secret and public
a,A                   = ephemeral client keys, secret and public
K                     = shared secret key
Kd                    = derivate of K
???                   = question


 CLIENT                                   SERVER

Username is hashed and not plain
 I  = MGF([Name])

                          -----------> I
                                          lookup on I values S,V,C in Database (Salt, Verifier, Counter)
                                          N,g = IDPrime(ID)
                                          k   = MGF([N, g])
                                          b   = RND()
                                          B   = k*V+g^b
                          S,C,B <---
 B   = 0 ??? abort else ok

 N,g = IDPrime(ID)
 k   = MGF([N, g])

 x   = MGF([S, I, P], C)
 V   = g^x

 a   = RND()
 A   = g^a
 u   = MGF([A, B], C)
 K   = (B-k*V)^(a+u*x)

// create new Verifier with new random salt and if needed with new password P', but P' can be even P
 S'  = RND()
 x'  = MGF([S', I, P'], C +1)
 V'  = g^x'

 Vp  = OTP(V', K, C +1)
 Sp  = OTP(S', K, C +1)

 Mc  = MGF([A, B, S', V'])
                          ----> Mc,A,Sp,Vp
                                         A  = 0 ??? abort else ok
                                         u  = MGF([A, B], C)
                                         K  = (A*V^u)^b

                                         S' = OTP(Sp, K, C +1)
                                         V' = OTP(Vp, K, C +1)

                                         M' = MGF([A, B, S', V'])
                                         M' = Mc ??? ok else abort

                                         Mh = MGF([A, B, S', V', Mc])

                                         store new Salt, Verifier and Counter+1 into DB to User I
                                           I,S=S',V=V',C=C+1
                          Mh <---------
 M' = MGF([A, B, S', V', Mc])
 M' = Mh ??? ok else abort

 Kd = MGF([K])                            Kd = MGF([K])
                          <-Data encrypted->
*)

Gruß Hagen

[cware]

kurz gesagt: genau das, was bei dem vorgehen, das ich gefunden habe, auch gemacht wird...
damit ist dein vorgehen also genauso anfällig für MITM wie das andere...


cheers...

[negaH]

Quatsch, Du musst das differenzieren. WANN ist eine MITMA möglich ? Das Verfahren ist sicher gegen jeden bekannten Angriff wenn man einmal beim Server registriert ist. Danach geht auch MITMA nicht mehr. Das ist weitaus besser als viele der heutzutage benutzten Verfahren, inkulsive SSL das mit Zertifikaten arbeitet die auf RSA basieren. Im RSA gibt es viel möchtigere Möglichkeiten ganze Infrastrukturen absichtlich zu kompromittieren. Ich sage immer: ein RSA Schlüssel den du nicht selber mit eigener Library, die mit den dazugehörigen eigenen Sourcen selber kompiliert wurde, ist absolut unsicher. Egal ob dieser ein 64 Bit RSA oder 4096 Bit oder 8196 Bit RSA Schlüssel ist. Alle RSA Schlüssel die du nicht selber erzeugt hast könnten von spezieller Form sein so das man sie in Sekunden knacken kann. Knacken heist hier das der Wissende der die RSA Schlüsselerzeugung manipuliert hat zu jederzeit aus dem öffentlichen Modul N bei RSA auf direktem Wege die beiden zugrundeliegenden Primzahlen P,Q faktorisieren kann. Nungut, soweit zu SSL und Zertifikaten und TrustCenter und SmartCards bei denen man eben nicht die absolute Kontrolle hat bei der Schlüsselerzeugung.

Nungut. Der einzigste Zeitpunkt bei der eine MITMA möglich ist ist der Registratiuonsprozess des User beim Server. Man kann nun mit verteilten Kommunikationswegen, beschränkten Zugriffsrechten abhängig vom Registrationsfortschritt usw. dieses Problem minimieren. Aber eine allwissende Authorität wird immer eine MITMA ausführen können. Das obige SRP Schema ermöglicht es aber einen erfolgreich durchgeführten Angriff wenigsten zu entdecken. Dh. der User wird beim nächsten Login, quasi als mathem. Beweis, erkennen das sein Account gebrochen wurde. In diesem Moment informiert er den Server und wählt ein neues Password. Der Angreifer muß zu jedem Zeitpunkt seine MITMA aktiv durchführen, also die Kommunikation vollständig und dauerhaft überwachen. Macht er dies nicht so ist seine MITMA erstmal futsch. Er muß, da der User nun ein neues Passwort wählt und keinen vollständigen Registrationsprozess mehr durchführt, nun eine Brute Force Attacke auf das Passwort auf dem Server durchführen. Ist der Server dabei nicht unter Kontrolle des Angreifers so muß er dies über das API des Servers machen. Da die Komplexität dieses Angriffes so enorm hoch ist ist der Angreifer gezwungen sehr viele Bruteforce Versuche in kürzester Zeit durchzuführen. Das API des Server sollte solche Versuche detektieren und die verbindung kappen oder den Account sperren.

Es sind also bei den neureren Protokollen schon viel weitreichendere Überlegungen angestellt worden die weitaus höhere Sicherheit bieten als alles was bis heute noch Standard ist.

Gruß Hagen

[negaH]

Zitat:

kurz gesagt: genau das, was bei dem vorgehen, das ich gefunden habe, auch gemacht wird... Laughing
damit ist dein vorgehen also genauso anfällig für MITM wie das andere...

Nenn mir ein Verfahren das absolut betrachtet einer MITMA widerstehen kann !

Gruß Hagen