|
Benutzerdaten einer Website - weg von MD5
Hallo zusammen,
gerade durch die phpBB.de-Geschichte, bin ich am Überlegen, ob ich die Benutzerpasswörter der Benutzer meiner Website anders hashen soll. Momentan nutze ich, wie viele andere, den MD5-Algorithmus. Ein anderer gewöhnlicher Hashalgorithmus wie SHA1 bringt meiner Meinung nach nichts, da man mittels Bruteforce, sofern der Hashalgorithmus bekannt ist, ähnlich viel erreichen kann, wie bei einem HD5-Hash. Nun wurde im entsprechenden  Thema das Salting angesprochen. Diesbezüglich bin ich auf php.net auf die crypt-Funktion gestoßen.Das Problem ist, ich möchte nicht unbedingt jeden registrierten Benutzer auffordern, ein neues Passwort einzugeben. Das wirkt sonst so, als sei die Datenbank geknackt worden, was ich vertuschen möchte und man müsse deshalb die Daten ändern (das würde ich vermutlich als erstes denken). Wahrscheinlich komme ich ohne weiteres jedoch nicht drum herum: Zitat:
Wie funktioniert das und was würdet ihr mir empfehlen? Grüße, Matze |
Re: Benutzerdaten einer Website - weg von MD5
Die einzige Möglichkeit, welche ich sehe, ist den MD5 des Passworts mit einem Salt nochmals zu Hashen. Ob das wirklich besser ist, das wage ich zu bezweifeln.
Ansonsten kannst Du es nur über diesen "ewigen Updatecode" machen. Den zu nutzen ist imo aber auch nicht schlimm. Das kann transparent im Hintergrund geschehen, so dass die Nutzer nichts mitbekommen. Zusätzlich zum Salt-String, welcher in der DB steht, würde ich einen weiteren Salt nutzen, der fest im Code steht. Das macht es für den Nichts-Ahnenden Angreifer nochmals schwieriger das Passwort via Brute-Force zu finden. ...:cat:... |
Re: Benutzerdaten einer Website - weg von MD5
Hallo Daniel,
sowohl das Updateskript als das doppelte Hashen gefallen mir eigentlich nicht so sehr. Wobei das Updateskript wäre noch ok, da müsste ich mich mal schlau machen, wie das funktioniert. Meinst du, ich habe einen Salt-String in der Datenbank, der zum Hashen mitverwendet wird? Denn das kommt mir nicht sehr sicher vor, da ein Angreifer diesen "Schlüssel" zusammen mit den Daten erhält und evtl. damit an die Benutzerdaten kommt. Natürlich konnte ich den Salt-String auch in eine PHP-Datei packen, dann wäre das gelöst. Persönlich kommt mir es sicherer vor, wenn man einen zufälligen Salt-String nutzt, damit auch der Hash identischer Passwörter unterschiedlich aussieht. Nur müssten diese Strings dann auch irgendwo abgespeichert werden und in der Benutzerdaten-Tabelle wäre das Fehl am Platz. :? Grüße |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
Wichtig für einen guten Salt ist dadurch imo nur eine angemessene Länge (ASP.Net: 10 Byte), volle Ausnutzung des Zeichensatzes und Per-User-Vergabe. |
Re: Benutzerdaten einer Website - weg von MD5
Sicherheitstechnisch sollte auch das doppelte Hashen einen Gewinn bringen. Denn dadurch hättest du die direkten Hashwerte der Passwörter auch nicht mehr vorliegen und verhinderst dadurch Attacken durch Rainbow-Tables. Als Nachteil bringt diese Variante zwar den erhöhten Rechenaufwand für die Verifikation, da zweimal gehahst werden muss, aber das sollte normalerweise zu vernachlässigen sein.
Aber die größte Sicherheitslücke ist immer noch die Übertragung selbst - wenn die Passwörter im Klartext durch die Leitung gehen, kann jemand da angreifen und sich nicht mühsam in die Datenbank einhacken. |
Re: Benutzerdaten einer Website - weg von MD5
Das doppelte Hashen (Bsp MD5 und SHA1) hätte den Vorteil, dass ich den bestehenden Hash einfach erneut hashen kann und so die Passwörter erhalten bleiben. Doch ich denke, da kann man auch recht leicht dahinterkommen. Vielleicht lässt sich das sogar am Hashwert erkennen.
Bei der Übertragung gebe ich dir recht, doch in Blogs (und Foren) ist das leider nicht häufig anzutreffen, zumindets kenne ich keinen, bei dem dies so wäre. Ich muss zugeben, dass ich mich mit SSL (https) noch nicht auseinandergesetzt habe und auch nicht weiß, ob mein Server dies unterstützt. Ich kann mir auch nicht vorstellen, dass jemand versucht, so die Passwörter von benutzern meiner kleinen Website herauszufinden, aber schön wäre so eine Lösung. |
Re: Benutzerdaten einer Website - weg von MD5
genau aus dem grund schreibt man sich für den datenbank-zugriff IMMER ein zusätzliches modul, dass die ganzen sicherheits-vorkehrungen automatisch trifft... sobald so'n ding da ist, kann man es mit code-injection bombardieren, bis einem schlecht wird...
die aussage, dass es keine sicherheitslücke in phpBB ist schlichtweg gelogen... dass ist so, als ob ich einen FTP-server schreibe, einen debug-zugang ohne passwort fest einkompiliere und dann sage, dass derjenige sich ja nicht eingehackt hat... stimmt... er hat den leichten weg genommen... zu dem bruteforcing: wenn man das bruteforcing erschweren will, sollte man versuchen, die Anzahl der Elemente des Definitionsbereichs zu erhöhen... oder anders ausgedrückt: man sollte versuchen, vor dem hashen statt einem ascii-text einen binärtext zu erhalten... auch der salt sollte möglichst binär sein... das erste, was man versucht, ist, den Definitionsbereich zu verringern... die verkleinung des Definitionsbereich verringert nämlich die Komplexität in abhängigkeit von der länge des ausgangstextes... *ehem* angenommen, wir sind im unären Zahlensystem (wobei 1 zur Basis 1 = 0 zur Basis 10, oder einfach ausgedrückt 0 = 1, 1 = 11, 2 = 111, etc.)... dann müssen wir für jede stelle genau ein Element prüfen... die Komplexität liegt also bei n... (um ein Wort der maximal-Länge n zu bruteforcen, müssen wir genau n worte testen [naja, eigentlich n-1, aber wen stört's])... im binären Zahlensystem müssten wir bei n Stellen bereits 2^n Zustände prüfen, im ternären system 3^n etc. pp. um es mal an zahlen auszumachen... angenommen, wir lassen nur passwörter mit mind. 8 zeichen zu... wenn wir unsere passwörter in binärform hashen (8bit definitionsbereich), haben wir 18446744073709551616 mögliche wörter... wenn wir nur passwörter mit groß- und klein-buchstaben, zahlen und ein paar sonderzeichen zulassen, kommen wir auf einen definitionsbereich mit etwa. 72 elementen (bei vielen systemen sind es weniger) und somit auf 722204136308736... die anzahl der zu testenden passwörter ver-25.000-facht sich... mit einem binären salt vergrößert sich diese zahl natürlich noch... cheers... P.S.: was man natürlich beachten muss, sind evtl. vorhandene kolisionen... diese sind allerdings nicht vermeidbar, da hashing ja immer eine surjektive abbildung ist... |
Re: Benutzerdaten einer Website - weg von MD5
Also bei unseren Servern wird nachdem 5 misslungenen Versuch die IP auf eine Banlist geschrieben womit die Firewall die IP 24 Std. Blockt.
Na dann viel Spass beim Bruteforce man sieht sich in ca. 10 Jahren wieder :wink: |
Re: Benutzerdaten einer Website - weg von MD5
Ähm hab ich richtig verstanden, der lange Text soll mir lediglich mitteilen, ich soll ein Passwort vor dem Hashen in eine Binärform bringen. :gruebel:
|
Re: Benutzerdaten einer Website - weg von MD5
den text in eine binärform bringen unter der premisse, dass die länge des wortes gleich lang bleibt, ja... das kann zum beispiel durch das einrechnen von stördaten/varianzen geschehen, durch die dann theoretisch alle 256 zustände in einem ungehashten wort vorkommen können...
das schöne: selbst, wenn der algorithmus für das einrechnen der varianzen bekannt ist, bringt das nichts, weil wir ja einwegfunktionen benutzen... sprich: md5(vary(Wort)) != vary(md5(Wort)) oder anders: die Varianz kann nicht vor dem Bruteforcen herausgerechnet werden... cheers... P.S.: wegen dem langen text - da hatte ich grad Mathe-Vorlesung... hat wohl abgefärbt... :mrgreen: |
Re: Benutzerdaten einer Website - weg von MD5
und wenn man dann noch Sakura's Salts mit einbezieht, dann kommt man schon auf 'ne nette Variante, die schön viele mögliche unterschiedliche Zustände zuläßt :angel:
PasswortHash = md5(vary(variablerSalt . festerSalt . Passwort)); festerSalt ist in 'ner PHP-Datei definiert (zum Ausgleich, der "Unsicherheit" der variablen Salts ... da hier wohl schwerer ranzukommen sein sollte) variablerSalt wird beim festlegen/ändern des Passwortes für jeden Benutzer neu festgelegt und, weils einfach ist, mit in der DB gespeichert (damit bei gleichen Paswörtern unterschiedliche Hashs rauskommen) und bei zu häufiger falscher Passwort eingabe sollte eh etwas geblockt/ausgebremst werden. |
Re: Benutzerdaten einer Website - weg von MD5
also wenn dann so
PasswortHash = variablerSalt || md5(vary(variablerSalt || festerSalt || Passwort)); Immer erst die Zufallsdaten und daran die festen Daten hashen. Eine Hashfunktion hat einen Lawineneffekt. Je veränderlicher die ersten Bits der Daten sind desto mehr Einfluß haben sie auf den internen Status der nachfolgenden Bits die man hasht. Aber grundsätzlich ist ein solches Loginsystem unsicher. Ein gutes Loginsystem ist in der Lage eine Authentifikation in mehreren Stufen (minimal 3) durchzuführen. Dabei authentifiziert es den Client beim Server, den Server beim Client und die kompletten vorherig getätigten Protokollschritte. Dabei darf das reale Benutzerpasswort nirmals den Clientrechner verlassen ! Hasht man auf einem Server das Passwort des Benutzers so heist dies das der Benutzer in irgendeiner Form immer das Paswot lesbar übers INet übertragen muß. Das ist unsicher. Die Datenbanken auf dem Server sollten mit einem Passwort verschlüsselt sein, egal was darin steht. Wird diese DB gestohlen muß man erstmal diese DB entschlüsseln können. Dazu sollte man eine Hardwarebasierte Lösung benutzen, also zb. SmartCards. Als sehr gutes Loginsystem gilt das SRP Verfahren. Bis auf den sensiblen Registratonsprozess eines neuen Benutzers gilt dieses als sehr sicher vor allen bekannten Angriffen. Der Registrationsprozess ist immer ein Problem, bei jedem Verfahren. Gruß Hagen |
Re: Benutzerdaten einer Website - weg von MD5
das passwort muss IMMER über das internet verschickt werden... mindestens bei der registrierung...
in der heutigen zeit ist alles andere user-unfreundlich etc. pp. für das eigentliche einloggen kann man ein challenge-response-verfahren benutzen... das problem ist nur: sowas unterstützt HTTP nicht... somit bleibt im web nur die übertragung des passwortes... cheers... |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
|
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
Wieso sollte das bei HTTP nicht realisierbar sein? Klar, interaktionslos geht es nicht, aber in zwei Schritten (1. Schritt: Laden einer Seite mit dem Challenge-Wert; 2. Schritt: Senden der Loginkennung und des Ergebnisses) sollte das doch problemlos möglich sein. Aber natürlich löst das viele andere Probleme nicht, man würde zwar beim Login keine Passworte mehr im Klartext über die Leitung senden, aber zumindest beim Registrieren muss man das tun. Oder aber man verwendet für das Registrieren eine Diffie-Hellmann-artiges Verfahren, was aber auch nichts bringt, da in einem kabelgebundenen Netz so gut wie nicht zwischen Mitlauschen und (aktiven) Man-in-the-Middle-Attacken unterschieden werden kann und das DH-Verfahren ohne so etwas wie Zertifikate notorisch unsicher ist. Also kommt man, will man ein System halbwegs sicher machen, nicht um die Verwendung einer komplexen Infrastruktur herum, und selbst dann bleibt immer noch das grundlegende Problem der assymetrischen Verfahren: Der Zwang zum Vertrauen der Herkunft. |
Re: Benutzerdaten einer Website - weg von MD5
möglich wäre es evtl. dadurch, dass der challenge-wert als hidden input im formular steht...
dann würde der user das passwort eingeben und auf einloggen klicken... dann müsste das passwort zuerst via JavaScript genommen werden, aus dem Passwort und dem challenge-wert der response-wert ermittelt werden... und dann müsste man evtl. nochmal ein commit machen, um den response-wert als passwort zurück zu schicken... jemand bock das mal eben umzusetzen? :lol: cheers... |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
Richtig, genauso würde das gehen, es würde aber wie angesprochen nicht viel bringen, da ja das Passwort irgendwann einmal ausgehandelt werden muss ;-) |
Re: Benutzerdaten einer Website - weg von MD5
Ganz stimmt das nicht.
In meiner SRP Implementierung habe ich gezeigt das man mit einem mehrstufigem EMail basiertem Registrationsprozess auch diesen Prozess kryptographisch absichern kann. Dabei wird der neuangelegte Account auf dem Server stufenweise in seinen Zugriffsrechten inkrementiert. Als erstes wird über die EMail ein Benutzer einen Account beantragen. Der Server erzeugt ein Zufallspasswort für diesen neuen Account, richtet eine vorläufigen und zeitlich begrenzten Account ohne Zugriffsrechte ein. Dann sendet er dieses vorläufige Passwort an die EMail des Benutzers als Link. Dieser wird den Link anklicken und sich das erste Mal beim Server mit dem vorläufigen Passwort anmelden, bei diesem Schritt definiert er sein reales Passwort als neues Passwort. Der Server gestattet Zugriff auf den Account, beide authentifizieren sich gegenseitig auf Basis des Registrationspasswortes. Der Server trägt die Daten zum neu gewählten Passwort in seiner DB ein, statt des dort gespeicherten vorläufigen Passwortes. Nun sendet der Server die "Prüfcode" per EMail an den User und gleichzeitg wird der "Prüfcode" auch nach dem Logindialog angezeit. Da SRP auf Diffie Hellman beruht, die "Prüfcodes" ebenfalls, und meine SRP Implementierung einen unverfälschbaren Login-Counter enthält kann ein Benutzer eine Man In The Middle Attack erkennen. Bei einer erfolgreichen Attacke wird der Angreifer ein neues Passwort hinterlegen und den Login-Counter inkrementieren. Der berchtigte Benutzer wird beim nächsten mal entweder einen fehlerhaften Login durchführen oder aber den Login-Counter zu weit inkrementiert vorfinden. Das System ist nicht absolut wasserdicht. Nimmt man eine "allmächtige" Autorität an, die JEDE Kommunikation überwachen kann, also auch TrustCenter, SmartCard Produktion, Post, INet, EMail, dann wird es kein automatisiertes Verfahren geben können das nicht geknackt werden könnte durch eine MITMA. Nur ein inoffizielles persönliches Treffen der beteiligten Parteien wäre dann noch sicher. Man kann also SRP so abändern das es im Vergleich zu 90% der heute benutzten Verfahren wirklich sicher ist. Besonders da man SRP so abändern kann das ein Benutzer bei jedem Login ein neues Passwort definieren kann ohne das der Server dies detektieren kann. Dh. eine Passwortänderung ist anonym. Das Passwort selber wird beim SRP niemals übertragen, verlässt also den Clientrechner nicht. Auch das eventuell neue Passwort wird niemals übers Netz übertragen. Dies ist möglich da SRP ein abgewandeltes Diffie Hellman benutzt. Man handelt also kein Passwort mehr aus indem man es in irgendeiner Form über das INet versendet. Das einzigste Passwort das quasi abgefanhen werden kann und mit der man dann eine MITMA machen könnte ist das vorläufige Registrationspasswort das der Server per Zufall erzeugt und zum Client zb. pr EMail sendet. Da der dazugehörige Acccount aber noch garnicht aktiviert wurde auch nicht explizit durch den Benutzer verifiziert wurde, ist eine MITMA viel schwieriger. Man müsste dazu eben eine "allmächtige" Authorität sein. Nur würden dann Zertifikate von TrustCentern ebenfalls knackbar sein. Gruß Hagen |
Re: Benutzerdaten einer Website - weg von MD5
Ich versteh das Verfahren nicht, zunächst scheitert es schon an diesem Punkt:
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? |
Re: Benutzerdaten einer Website - weg von MD5
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? was ich wirklich interessant finde, ist der ansatz auf http://pajhome.org.uk/crypt/md5/auth.html (suchen nach "Alternative System")...der müsste jedoch noch gegen einen man-in-the-middle (MITM) abgesichert werden... aber zumindest entfällt hier die passwort-übertragung bei der Registrierung... wirklich toll... :-D cheers... |
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 |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
(sorry, falls das folgende falsch ist, aber bei deiner beschreibung des vorganges verstehe ich großteilig nur bahnhof, liegt wohl teilweise an den ganzen ein-zeichen-bezeichnern:) das problem an der ganzen sache ist: der MITM kann sich einfach zwischen den client und server schalten und die challenge-response-phase mitnutzen... es sagt ja niemand, dass der MITM sich nach dir nochmal einloggt... er loggt sich einfach ein, wenn du dich einloggst... damit fällt der login-counter schonmal flach... die response zur password-challenge lieferst du automatisch beim login mit... das wohl interessanteste szenario ist, dass der MITM sich permanent einnistet und sich auf deiner seite als server ausgibt... er könnte z.b. alle passwort-änderungen, etc. mitmachen und sogar deine anfragen an den server weiterleiten und die antworten an dich zurückgeben (allerdings würden die anfragen über die gekaperte verbindung des MITM mit seinen zugangsdaten erfolgen)... mitkriegen würdest du nicht viel - der counter wird erhöht (das kann sogar der echte server übernehmen) und das passwort wird geändert (das macht der MITM)... und während du eingeloggt bist (und auch danach) kann der MITM auf dem server arbeiten... sollte er gerade arbeiten und willst dich neu einloggen, kappt er die verbindung zum server und baut sie gemeinsam mit dir wieder neu auf => der login-counter ist korrekt und alle sind glücklich... cheers... |
Re: Benutzerdaten einer Website - weg von MD5
Hi.
Du könntest es so Formulieren: Da in letzter Zeit die anfälligkeit der Forensoftware durch Exploits stark angestiegen ist haben wir mit der Sicherheit stark nachgerüstet. Wir bitten euch euer Passwort zu aktualisieren und somit eure Sicherheit zu gewährleisten. Oder halt in die Richtung. |
Re: Benutzerdaten einer Website - weg von MD5
Hallo
@gene: Stimmt, das st eine gute Idee. @alle anderen: Ich lese hier fleißig mit, muss mich aber teilweise genauer mit den angesprochenen Verfahren beschäftigen, da ich diese noch nicht ganz verstanden habe und somit auch nicht sachlich mitreden kann. Auf jedenfall klingen einige Ansätze vielversprechend. Diskutiert ruhig weiter, ich finde es sehr interessant. :thumb: Grüße |
Re: Benutzerdaten einer Website - weg von MD5
Zu eurer Salt Diskusion:
ein MD5 hasht zu einer 128bit Zahl. Also gibt es 2^128 Möglichkeiten. Wenn ihr einen Salt verwendet, bringt das keinen Unterschieden an den Möglichkeiten was aus dem MD5 rauskommt. Richtige BF-Angriffe probieren eine Kollision zu finden. D.h. einen Input welcher nach dem MD5 das gleiche Ergebnis hat. Somit ist der Salt auch uninteresant, da sowieso das orginal Passwort niemals ermittelt werden kann. Der Salt verhindert nur eines (wenn diese gut gewählt ist): Passwörter bestehen im Normalfall auf Zeichen welche über Tastatur eingegeben werden können. Meist sind Passwörter nur aus Buchstaben (ausgenommen Freaks welche natürlich auch Zahlen und Sonderzeichen verwenden). Dadurch ergibt sich für ein 0815 Passwort pro Stelle 52 Möglichkeiten (26+26) Erzeugt man nun eine Rainbowtabelle mit diesen 52 Zeichen pro Stelle is diese Tabelle kleiner als würde man eine Tabelle erzeugen, welche alle Zeichen beinhaltet. Was ein Vorteil ist. Diese kleine Rainbowtabelle wird ausgehebelt wenn ihr Salts mit Sonderzeichen verwendet, ggf. auch Zeichen welche NICHT eingebbar sind über Tastatur. Diese verkürzten Tabelle werden meistens verwendet, um funktionierende Passwörter zu ermitteln. Größere komplette Tabelle zu erzeugen, verbraucht massig Speicher und massig Zeit. Wer mal ein einzelnes Passwort aus einen MD5 braucht, für den habe ich noch diesen Link: http://md5.rednoize.com/ |
Re: Benutzerdaten einer Website - weg von MD5
Also wenn ich dies Diskussion richtig verstanden hab dann wollt ihr eine Brutforce Attacke Unterbinden.
Das geht aber nicht durch ändern des Verschlüsslungs Algorithmus des PW in der DB (weil Brute Force ist das egal) Eine RainbowTabelle hilft dabei zwar das PW schneller zu erlange. Jetzt zu einer Lösung. Das Problem ist die Eingabe des PW's, Also wie der Hacker die Daten an die DB Schickt da müsst ihr handeln und nicht irgendwelche Algos fürs PW ändern. |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
Bei einem MD5-Hash muss der Angreifer per Bruteforce lediglich alle möglichen MD5-Hashs erzeugen bis dieser mit dem gegebenen Passwort-Hash übereinstimmt. Dann wurde ein gültiges Passwort ermittelt. Wenn man den Hash allerdings mit einem Salt und ähnlichem erzeugt, dann weiß der Angreifer nicht, wie der Passwort-Hash erzeugt wurde und kann so nicht ohne weiteres per Bruteforce auf ein gültiges Passwort kommen. Das war zumindets mein Gedanke. |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
Er muss doch Username und PW eingeben. |
Re: Benutzerdaten einer Website - weg von MD5
@Matze:
Stell es dir mal so vor: Du schützt mit Algorithmus "Fantasy" alle Passwörter und andere Daten deines Systems. Nun sagt dir einer das Fantasy nicht mehr sicher ist, er tritt den Beweis an das er gebrochen werden kann. Du weißt nicht wer in der Zwischenzeit an deine verschlüsselten Daten herangekommen ist. Du must also von der Annahme augehen das Jemand an deine Daten herangekommen ist und du hast es nicht bemerkt. Du kannst nicht von der Annahme ausgehen das keiner an deine Daten rangekommen konnte denn das musst du dann hieb&stichfest beweisen können. Das geht nicht sobald du igrend ein OS benutzt. Du must auch davon ausgehen das Derjenige der deine Daten nun hat auch weiß das Fantasy gebrochen wurde. Du kannst also davon ausgehen das dieser deine Daten hat. Nun: das bedeutet, egal wie du es drehst und wendest: 1.) die User müssen darüber informiert werden das ihre Passwörter unsicher geworden sind 2.) deine System muß einen anderen Schutz benutzen der durch Experten als sicher eingestuft wurde 3.) alle User müssen ein neues Passwort benuten für dein neues System 4.) schlaue User ändern alle Accounts usw. bei denen sie das gleiche Passwort benutzt haben Nur das macht es sicher. Du kannst da rumdoktorn wie du möchtest es kann nicht sicherer werden, wenn du davon ausgehen musst das der Angreifer schon längst dein System im geheimen geknackt hat, also den Worstcase. Ein gutes Loginsystem sollte komplett beweisbar anonym arbeiten. Es darf keinerlei Information die einen Zusammenhang zu einem User herstellen könnte ungeschützt gespeichert werden. Gruß Hagen |
Re: Benutzerdaten einer Website - weg von MD5
Zitat:
|
Re: Benutzerdaten einer Website - weg von MD5
Hallo Hagen,
so ähnlich hast du das ja bereits geschildert. Ich habe nur die Ausgangssituation nochmals erläutert, um franktron klar zu machen, was ich ursprünglich meinte. Ich hatte ihn so verstanden. Daher schrieb ich auch, es sind sehr interessante Aspekte erwähnt worden, von denen ich noch gar nicht wusste, dass es sie gibt. Sehr gut gefällt mir vor allem die Methode, das Passwort gar nicht erst zu übertragen. Ob ich das umsetzen kann, sei mal dahingestellt, aber näher auseinandersetzen werde ich mich damit auf jedenfall. :) |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 05:51 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