Re: Benutzerdaten einer Website - weg von MD5
Zitat:
Damit kriegt pgp den schwarzen peter, und ich denke, damit kommt es klar ^^ |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
|
Re: Benutzerdaten einer Website - weg von MD5
Ob PGP oder Zertifikate - das Grundproblem wird nur verschoben:
Woher willst du wissen, dass ein öffentlicher Schlüssel wirklich authentisch ist? |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
aber auch da gilt wieder: bin ich wirklich mit dem richtigen verbunden, oder stecke ich grad in einer man-in-the-middle attack... :lol: cheers... |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
|
Re: Benutzerdaten einer Website - weg von MD5
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.
|
Re: Benutzerdaten einer Website - weg von MD5
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:
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:
Gruß Hagen
(*
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-> *) |
Re: Benutzerdaten einer Website - weg von MD5
kurz gesagt: genau das, was bei dem vorgehen, das ich gefunden habe, auch gemacht wird... :lol:
damit ist dein vorgehen also genauso anfällig für MITM wie das andere... cheers... |
Re: Benutzerdaten einer Website - weg von MD5
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 |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
Gruß Hagen |
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:24 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz