Archiv verlassen und diese Seite im Standarddesign anzeigen : MD5 Rückrechnen
FireMail
01.06.2006, 14:52
Hi,
da ich derzeit an einer Sicherheitslösung bzgl Passwörtern arbeite hat sich mir eine Frage eröffnet.
MD5 Verschlüsselte Passwörter in einer MySQL DB gespeichert - können die Rückgerechnet werden?
Denn egal wie oft man den Ursprungsstring MD5 verschlüsselt - es kommt immer das selbe raus. Folglich muss ein Fixer Algorithmus dahinter stecken und da großteil der Unix Sources einsehbar sind sollte der doch auch reversiv berechenbar sein oder?
Weiß da einer von euch etwas?
Gibt es eventuell Tools um das zu testen? Gibt es dynamische Verschlüsselungsmethoden um dies Problem zu beheben?
Jürgen
du brauchst nich erst in die unix sourcen gucken um das herauszufinden. der algo ist öffentlich zugänglich. aber man kann ihn nicht rückrechnen. manche rechenoperationen lassen sich nun einfach nicht umkehren auch wenn man das ergebnis und den rechenweg hat.
es soll allerdings leute geben die tag und nacht daran arbeiten datenbanken mit hashes zu füllen und passenden strings dazu.
ein hash ist eben nun einfach nur so lang wie er ist, und daher gibt es halt auch nicht nur 1 quellstring dafür sondern theoretisch unendlich viele. und man muss ja nur einen finden ;)
und es gibt nun eben solche datenbanken denen man einen hash füttert und mit glück einen passenden string zurück bekommt.
Zur Zeit gilt MD5 übrigens als sehr sicher ;) Um gezielt ein Passwort zu knacken brauchst du selbst mit Hochleistungsrechnern noch Jahrhunderte, es gibt einfach zu viele Möglichkeiten.
Solche Datenbanken wie gencha angesprochen hat bringen nicht viel, da auch die erstmal gefüllt werden müssen und durch ihre enorme Größe auch verdammt langsam werden. Irgendwann wird MD5 überholt sein ;) Aber das dauert noch.
FireMail
01.06.2006, 15:13
also könnt ihr mir schon dazu raten "normale" md5 verschlüsselung zu verwenden.
hab nämlich irgendwo mal was gehört vonwegen dass bereits eine rückentschlüsselung von md5 möglich ist :-/
Man kann durch durchprobieren "rückrechnen" ... aber wie gesagt: Das lohnt sich nicht. Ich werde mal aus Spaß nach dem Quelltext suchen und dir sagen wie lange ein gezieltes Rechnen dauern würde ;)
einfaches schwupp-di-wupp rückrechnen ist nicht möglich. da bin ich mir sehr sicher. und wenn man ohne große probleme 3des oder ähnliches nehmen kann statt md5, dann würde ich das tun. aber angst md5 zu benutzen? ne nich wirklich. denn es ist im grnude so wie malo schon sagt.
xenobyte
01.06.2006, 15:26
Ich wuerde MD5 - sofern moeglich - vermeiden. Ausloeser dafuer war bei mir die Tatsache, dass ich beim testen einer PHP-Application via SQL-Injection an Hashes der Userpasswoerter gekommen bin und im Internet existieren riesen Datenbanken mit MD5-Hashes, die man frei durchsuchen kann.
Das Problem ist nicht nur der Algorithmus an sich, sondern die Tatsache, dass er so beliebt ist, dass es sich scheinbar lohnt Hash-Datenbanken fuer sowas zu errichten.
http://us.md5.crysm.net/find?md5=1a9985f30fec825596a938dd8f42ac96
:D
butterkeks
01.06.2006, 16:23
Dennoch ist auch das Knacken von Hash-Algorithmen möglich, doch man versteht darunter etwas anderes, als du vlt. glaubst.
Beim "Knacken" geht es darum, sog. Kollisionen zu finden, sodass man beim Durchprobierenb sagen kann "wenn a nicht geht, muss ich b auch nciht probieren, etc.". Dadurch kommt man schneller an's Ziel, mit einem Brute-Force
http://en.wikipedia.org/wiki/Hash_collision
Hi,
da ich derzeit an einer Sicherheitslösung bzgl Passwörtern arbeite hat sich mir eine Frage eröffnet.
MD5 Verschlüsselte Passwörter in einer MySQL DB gespeichert - können die Rückgerechnet werden?
Denn egal wie oft man den Ursprungsstring MD5 verschlüsselt - es kommt immer das selbe raus. Folglich muss ein Fixer Algorithmus dahinter stecken und da großteil der Unix Sources einsehbar sind sollte der doch auch reversiv berechenbar sein oder?
Weiß da einer von euch etwas?
Gibt es eventuell Tools um das zu testen? Gibt es dynamische Verschlüsselungsmethoden um dies Problem zu beheben?
Jürgen
Naja... MD5 ist ein sog. Hash-Algorithmus, bzw. eine Einweg- oder Trapdoor-Funktion.
Es erzeugt aus einem Eingabe-Datenstrom (fast) beliebiger Länge einen determinierten, eindeutigen Wert, dessen Wahrscheinlichkeit einer Kollision bei konstanter Stromlänge sehr gering ist (d.h. der Algorithmus hat eine sehr große Hammingdistanz).
Zurückrechnen geht nicht - denn bei der Erzeugung des Hashes geht die Identität der Ursprungsdaten verloren.
Aber MD5 ist trotzdem nicht vollkommen sicher, denn wie bei allen Hashes läßt sich eine Kollision erzwingen (zwei Datenströme erzeugen den gleichen Hashwert), dies läßt sich prinzipiell nicht verhindern.
Da die Hashes für bestimmte Eingangsdaten determiniert sind, ("Hallo" als Eingangsdaten wird immer den gleich Hash erzeugen), kann man mit dieser Information arbeiten. So gibt es Datenbanken, die bestimmte Dienstleister anbieten, die für einen bestimmten Hash alle Datenströme bis zu einer bestimmten Länge liefern, die diesen Hashcode erzeugen.
Diese Datenbanken existieren für alle bekannten und verbreiteten Hashes, so auch für MD5 oder SH-1...
Zur Zeit gilt MD5 übrigens als sehr sicher ;) Um gezielt ein Passwort zu knacken brauchst du selbst mit Hochleistungsrechnern noch Jahrhunderte, es gibt einfach zu viele Möglichkeiten.
Solche Datenbanken wie gencha angesprochen hat bringen nicht viel, da auch die erstmal gefüllt werden müssen und durch ihre enorme Größe auch verdammt langsam werden. Irgendwann wird MD5 überholt sein ;) Aber das dauert noch.
Mir ist ein Anbieter bekannt, der SH1 und MD5-Hashes für Strings bis zu einer Länge von 40 Zeichen gespeichert hat - in verschiedenen Versionen, so als voll rückgerechneter Wert, als ASCII, als druckbare Zeichen, nur alphanumerisch und nach Wahrscheinlichkeit und Wörterbuch sortiert.
Diese Datenbank ist derzeit mehrere Terabyte groß, und sie wächst... grid computing macht es möglich.
Stefan S.
01.06.2006, 16:44
Naja... MD5 ist ein sog. Hash-Algorithmus, bzw. eine Einweg- oder Trapdoor-Funktion.
Es erzeugt aus einem Eingabe-Datenstrom (fast) beliebiger Länge einen determinierten, eindeutigen Wert, dessen Wahrscheinlichkeit einer Kollision bei konstanter Stromlänge sehr gering ist (d.h. der Algorithmus hat eine sehr große Hammingdistanz).
Zurückrechnen geht nicht - denn bei der Erzeugung des Hashes geht die Identität der Ursprungsdaten verloren.
Aber MD5 ist trotzdem nicht vollkommen sicher, denn wie bei allen Hashes läßt sich eine Kollision erzwingen (zwei Datenströme erzeugen den gleichen Hashwert), dies läßt sich prinzipiell nicht verhindern.
Das ist alles richtig. Zu erwähnen wäre noch das die Erzeugung von Kollisionen mittlerweile relativ schnell möglich ist. Aber eine Kollision bedeutet ja nur das ich zwei oder mehrere unterschiedliche Daten generiert habe die denselben Hash produzieren. Auf die Speicherung von normalen Benutzerpasswörtern hat das zunächst einmal keinen Einfluß, den hier möchte ich aus den Ausgangsdaten den Ursprungswert generieren.
Es gibt derzeit nur die Methode des Brute-Force. Wenn das Passwort aus vielen unterschiedlichen und einzigartigen Elementen zusammengesetzt wurde ist ein Brute-Force Angriff so gut wie aussichtlos. Was jedoch problematisch ist sind die so genannten Rainbow Tables. Es existieren Tabellen die bereits kalkuliert wurden. Das heißt zum Beispiel der Hash für das Wort Haus oder das Wort rumpelstilzchen123. Dadurch verringert sich die Rechenzeit erheblich da man nur die Tabelle nach einem Match durchsucht. Erlangt man den Besitz von Benutzerpasswörtern aus einer Datenbank mit vielen hundert Benutzern wird man mit sehr hoher Wahrscheinlichkeit fündig werden, zumal viele Passwörter zu einfach strukturiert sind.
hab nämlich irgendwo mal was gehört vonwegen dass bereits eine rückentschlüsselung von md5 möglich ist :-/Natürlich ist eine Rückentschlüsselung möglich - es ist letzten Endes nur eine Frage von Resourcen, ob man sowas tatsächlich auch als sinnvoll erachtet. Wenn jemand für das Entschlüsseln des Passwortes meines E-Mail Accounts "nur" zwanzig Jahre brauchen würde, dann wäre ich immer noch nicht wirklich besorgt.
Aber für den "Durchschnittsgebrauch" wird MD5 noch eine ganze Weile als sicher zu bezeichnen sein.
eViL_oNe
01.06.2006, 22:51
MD5 und SHA1 gelten längst nicht mehr als sicher -- eine Kollision ist mit weitaus weniger Versuchen möglich theoretisch angenommen:
http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/62480
Zum Glück gilt dies nur für Kollisionen -- um zu einem MD5/SHA1 Hash-Wert wieder in einen Datensatz umzuwandeln, benötigt man weiterhin im worst-case 2^128 bzw. 2^160 Versuche ;)
Kleiner Vorschlag von mir:
Normalerweise neigen User ja dazu, einfache Wörter, Namen oder ähnlichen Schund als Paßwort zu benutzen. Können sie ja auch.
Aber wie wärs, wenn Du, bevor Du das Paßwort durch den MD5 schickst, einfach noch:
- Ziffern/Sonderzeichen einfügen würdest?
- Oder das Paßwort rückwärts schreiben?
- Oder jedes 5. und jedes 7. Bit umkehren, wenn das 3. und 4. Bit gleich sind?
- Oder die Zeichen mit einer 1:1 Ersetzungstabelle in andere Zeichen ersetzen?
- Oder jedes Zeichen mit einer Tabelle in "Daten" übersetzen, daß z.B. aus "a" dann "$!Q" und aus "b" wird "uX)==" usw.?
- Oder einfach an das Paßwort eine 100kByte große Datei hängen?
Genau DANN würdste nämlich erstmal aus dem Paßwort zwar immer noch ein eindeutiges Paßwort, aber eben ein Kauderwelsch-Paßwort erzeugen.
Halt eins, für das es noch keine vorberechneten Hashes in Tabellen gibt...
Dasselbe machste dann auch, wenn das Paßwort geprüft werden soll.
Das heißt also, einfach dem MD5 noch einen eigenen kleinen Algo voranstellen, der aus dem doofen Klartextpaßwort ein etwas "gestreuteres" generiert.
Klar, damit isses natürlich trotzdem nicht sicherer. Aber schließt wenigstens die Benutzung vorgefertigter Tabellen aus.
"Rückrechnen" von MD5 stell ich mir wahnsinnig affig vor - schon den eigentlichen MD5-Algo (vorwärts) von Hand zu implementieren (hab ich mal neulich gemacht), macht nicht gerade Spaß...
EIGENTLICH geht Rückrechnen nämlich gar nicht, weil es kein festgelegtes eindeutiges Ergebnis gibt, sondern eine unendlich große Menge von Ergebnissen, von denen eins sinnvoll, aber auch alle anderen denkbar sind.
Der Computer kann natürlich nicht erkennen, wann ein Ergebnis "sinnvoll" ist, da für ihn auch Paßwörter, die nur aus Sonderzeichen oder ASCIIs von 0 bis 255 bestehen, sinnvoll sein können.
"Sinnvoll" im Sinne von "von normalem User benutzt" sind eben Paßwörter, die Klartextwörter enthalten und auf die bei jeder "Rückrechenstufe" gescannt werden müßte...
Also - schon normales MD5-"Rückrechnen" dürfte für heutige Rechner in Sackgang ausarten. Ein kleiner Trick (siehe oben) und schon kann man auch die "Wörterbuch-Attacken" vergessen...
foobarflu
06.06.2006, 17:14
um noch eine für den praktischen Einsatz wichtige Möglichkeit hinzuzufügen: man kann
H( { username-value, ":", realm-value, ":", passwd }
speichern. Ermöglicht dann trotzdem noch vernünftige Authentifizierungsmethoden wie digest-md5 (http://www.ietf.org/rfc/rfc2831.txt)
eViL_oNe
06.06.2006, 21:37
EIGENTLICH geht Rückrechnen nämlich gar nicht, weil es kein festgelegtes eindeutiges Ergebnis gibt, sondern eine unendlich große Menge von Ergebnissen, von denen eins sinnvoll, aber auch alle anderen denkbar sind.
Der Computer kann natürlich nicht erkennen, wann ein Ergebnis "sinnvoll" ist, da für ihn auch Paßwörter, die nur aus Sonderzeichen oder ASCIIs von 0 bis 255 bestehen, sinnvoll sein können.
"Sinnvoll" im Sinne von "von normalem User benutzt" sind eben Paßwörter, die Klartextwörter enthalten und auf die bei jeder "Rückrechenstufe" gescannt werden müßte...
selbstverständlich kann man MD5 Hashes (wie auch alle anderen Hash-Funktionen) zurückrechnen. Ein MD5 Hash hat lediglich 128 bits, damit gibt es genau 2^128 unterschiedliche Hashes.
Eine Hash-Funktion h(x) garantiert nach der Definition nur, dass wenn
x1 = x2
dann
h(x1) = h(x2)
x1 != x2
und
h(x1) = h(x2)
ist aber auf jedenfall möglich ;)
Der Clou ist dabei, zu einem bekannten h(x1) und einem unbekannten x1 das x2 zu finden ;). Spätestens nach 2^128 Versuchen hat man das Ergebnis -- good luck! *Ggg*
Jan Krüger
06.06.2006, 21:55
selbstverständlich kann man MD5 Hashes (wie auch alle anderen Hash-Funktionen) zurückrechnen.
Nein, denn zu jedem h(x) gibt es unendlich viele x. Im Übrigen braucht man nicht einfach 2^128 Versuche, um x zu finden, denn es gibt bedeutend mehr als 2^128 verschiedene x.
Eben!
Und das Wort "zurückrechnen" ist hier ebenso fehl am Platz.
Du kannst einen MD5 Hash definitiv nicht zurückrechnen.
Und auch einen anderen Hash (auf jeden Fall keinen mir bekannten) kannst du nicht "zurückrechnen".
Du kannst lediglich durch Hashen eines Strings-, bzw. vieler Stringblöcke prüfen ob ein Ergebnis mit vorgegebenem Hash übereinstimmt.
Die Anzahl der Möglichkeiten lässt sich zwar mittlerweile etwas verringern, aber selbst wenn du abkürzt, heisst es noch lange nicht, dass du den eigentlichen String reproduziert hast.
Im Idealfall hälst du dann halt etwas schneller einen kollisionsfähigen String in der Hand.
eViL_oNe
06.06.2006, 22:40
Nein, denn zu jedem h(x) gibt es unendlich viele x. Im Übrigen braucht man nicht einfach 2^128 Versuche, um x zu finden, denn es gibt bedeutend mehr als 2^128 verschiedene x.
vielleicht ist es ein Verständnisproblem von mir, allerdings gehe ich davon aus, dass etwa Authentifizierungsmethoden so aufgebaut sind:
passwordHash = md5(password);
savedPasswordHash = GetPassword("root");
if ( passwordHash != savedPasswordHash )
error( "authentification failed" );
damit ist es doch vollkommen egal, welches x man findet, sofern es nur den gewünschten Hash-Wert erzeugt?
Das mit dem Begriff "zurückrechnen" ist natürlich vollkommen richtig :)
damit ist es doch vollkommen egal, welches x man findet, sofern es nur den gewünschten Hash-Wert erzeugt?
Welches x man findet ist natürlich egal, solange es dem richtigen Format entspricht. Allerdings ist damit noch nicht gesagt, dass man höchstens 2^128 Versuche braucht, um ein passendes x zu finden. Denn es ist relativ unwahrscheinlich, dass die 2^128 verschiedenen x, die man ausprobiert, alle einen verschiedenen Hash haben.
passwordHash = md5(password);
savedPasswordHash = GetPassword("root");
if ( passwordHash != savedPasswordHash )
error( "authentification failed" );
damit ist es doch vollkommen egal, welches x man findet, sofern es nur den gewünschten Hash-Wert erzeugt?
Das mit dem Begriff "zurückrechnen" ist natürlich vollkommen richtig :)
Ja, das ist richtig...
Allerdings muss ein Hash ja nicht unbedingt so benutzt werden.
Ich habe meiner Freundin z.B. neulich ein online-Tagebuch geschrieben (wie Frauen halt sind, wollte sie auch, dass es wirklich keiner lesen kann, selbst wenn der Server mal kompromittiert werden sollte), und habe die komplette Verschlüsselung clientseitig durchgeführt.
Das Passwort liegt als MD5-Hash zwar auf dem Server, aber zum einloggen wird der Hash des Passwortes Clientseitig erstellt, und anschliessend an den Server übermittelt, um diesen zu prüfen und bei Gültigkeit ein Cookie zu setzen, wenn Hash vom Pass richtig war.
Alle weiteren Daten (Tagebucheintrag, Bilderchen etc.) werden auch clientseitig via Blowfish (mit dem selben Pass mit welchem der MD5 Hash erstellt wurde) verschlüsselt und dann verschlüsselt an den Server gesendet.
Ergebnis ist, dass selbst wenn jemand an die Daten auf dem Server gelangt und den Hash in der Hand hält um eine Kollision zu berechnen, nie an die eigentlichen Tagebucheinträge gelangt, selbst wenn er die komplette Routine in der Hand hält, da er wie gesagt, nur eine x-beliebige Kollision erstellt hat um sich einloggen zu können, dieser String aber nicht zur dechiffrierung der Blowfish-Daten taugt.
Also müsste hier schon das eigentliche Passwort reproduziert werden...
eViL_oNe
06.06.2006, 23:28
oki, thx -- wieder was gelernt *g*
deine Methode scheint mir aber auch nicht wasserdicht zu sein -- den Hash, der vom client geschickt wird (nehme mal an, ajvascript), wird man auch direkt senden können, ohne ihn erst berechnen zu müssen
Jan Krüger
07.06.2006, 00:01
oki, thx -- wieder was gelernt *g*
deine Methode scheint mir aber auch nicht wasserdicht zu sein -- den Hash, der vom client geschickt wird (nehme mal an, ajvascript), wird man auch direkt senden können, ohne ihn erst berechnen zu müssen
Das stimmt. Hier geht es eher darum, dass man auch bei Zugriff auf den Server zwar an den Hash drankommt, aber damit nicht die Daten entschlüsseln kann.
Es gäbe übrigens einen weiteren Ansatz, der auch den Server-Login noch erheblich erschweren würde: man speichert h(h(x)), wobei x das Passwort ist. Damit kann man dann h(x) als Passwort an den Server schicken, wodurch der einen authentifizieren kann, ohne das genaue Passwort oder auch nur den Hash davon kennen zu müssen.
Führt man diesen Ansatz noch etwas weiter, kommt man zu Einwegpasswörtern (One-Time Passwords, z.B. implementiert durch OPIE).
deine Methode scheint mir aber auch nicht wasserdicht zu sein -- den Hash, der vom client geschickt wird (nehme mal an, ajvascript), wird man auch direkt senden können, ohne ihn erst berechnen zu müssen
Ja stimmt, du hast recht...
Ich habe gar nicht mit einkalkuliert, dass man die eigentlichen HTML/JavaScript Inhalte auch ändern könnte, um sich so den Plainkey bei Benutzung des Tagebuches senden zu lassen.
Dieses funktioniert dann allerdings auch nur, wenn der Server wirklich in fremder Hand ist.
Ich habe jetzt eine ganze Weile nachgedacht, bin aber nicht wirklich auf eine alltagstaugliche Lösung gestoßen.
Um mal einen Gedankengang zu beschreiben:
Sie hat eine simple HTML/JavaScript Datei auf ihrem Rechner oder einem USB-Stick, welche alle Seiten in Form von verschlüsselten Variablen in einer .js Datei vom Server einbindet und mit einem auf der Homeseite eingegeben Passwort entschlüsselt und via document.write ausgibt. Aber da könnte man ja wieder eigenen JavaScript-Code einbinden. Ausserdem müsste man dann via JavaScript einen Cookie setzen (damit sie nicht bei jeder Seite das Passwort erneut eingeben muss), der dann auch ausgelesen werden kann. Das fällt also weg...
Ich glaube, ich kann das ganze online-Design vergessen *grml*, und schreib einfach ein eigenständiges Programm, welches die Daten vom Server entgegen nimmt und halt auch wieder an den Server sendet...Dann wäre der komplette Verkehr 100%ig verschlüsselt und keiner könnte irgendwelchen Code unterschmuggeln.
Aber irgendwie will ich ihr nun nicht wirklich eine Datei aufs Auge drücken, welche sie immer mit sich rumschleppen muss.
Hat jemand andere Vorschläge?
P.s.: Das Danke gebe ich hiermit zurück... *g*
P.P.s: Danke Jan...werde mir deine Authentifizierung mal genauer anschauen...
vielleicht ist es ein Verständnisproblem von mir, allerdings gehe ich davon aus, dass etwa Authentifizierungsmethoden so aufgebaut sind:
passwordHash = md5(password);
savedPasswordHash = GetPassword("root");
if ( passwordHash != savedPasswordHash )
error( "authentification failed" );
damit ist es doch vollkommen egal, welches x man findet, sofern es nur den gewünschten Hash-Wert erzeugt?
Nicht unbedingt...
Die Kontrolle des Hash ist nur ein Schritt in der Authentifizierung. Damit reicht eine einfache Kollision nicht mehr.
Oftmals werden einige "sanity checks" angehängt, so wird das Passwort auf ungültige Zeichen getestet, an das Passwort wird von dem Hashen ein CRC angehängt (sehr beliebte Methode), usw. Damit hast du einfache Kollisionen schon schnell ausgeschlossen. Da es schon nicht einfach ist, eine einzelne Kollision zu finden, wird es schon durch einfachste Sanitychecks quasi unmöglich, in vertretbarer Zeit eine Lösung für das Problem zu finden.
Die Alarmrufe, SHA-1 oder MD5 wären unsicher, weil sich Kollisionen leichter provozieren lassen, als gemeinhin angenommen, ist eine in erster Linie theoretische Bedrohung! Darauf weisen auch die Cryptoanalytiker hin.
rennfrikadelle
07.06.2006, 13:03
damit ist es doch vollkommen egal, welches x man findet, sofern es nur den gewünschten Hash-Wert erzeugt?
Das mit dem Begriff "zurückrechnen" ist natürlich vollkommen richtig :)
...ist kein Zurückrechnen, sondern probieren, auch BF-Attacke genannt
Hab ich Ironie übersehen?
Ich bitte aus leidvoller Erfahrung den Begriff "zurückrechnen" nich so zu vergewaltigen.
MD5 ist knackbar, aber nicht umkehrbar - also Rückrechenbar. Es ist nicht möglich anhand eines Hashes, einer Formel und unendlich viel Zeit exakt den Ursprungswert zu bestimmen:
13 + 10 = 23
Welche Rechnung führte zum Ergebnis 23?
eViL_oNe
08.06.2006, 21:55
weniger Ironie, als durch Überarbeitung verursachte zeitlich begrenzte geistige Umnachtung ;)
Ich sitze hier gerade gemütlich am rechner und les den Thread da fellt mir doch eine kleine Idee ein womit man es sicherer machen könnte doch da ich mir nicht sicher bin FRAG ich doch EINFACH mal :)
Ein PW wird gesetzt.
-> Das PHP Script hängt an das PW beispielswie den Timestamp von Registrierungsdatum (Das darf nur keiner wissen)
->Es wird nun MD5 verschlüsselt
->Ab in die DB
->Bei erneuter eingabe wird das Timestamp was in der DB steht drangefuegt
->Klaut nun irgendson kid den Hash und gibt in ne DB ein, und villeicht gibt es sogar übereinstimmung gibt er das PW ein. Da das Login script allerdings wieder das Timestamp dranfügt wird das Hash doch wieder anders
->Kid is traurig
Mir kam es nur so als Gedanke aber eigentlich ist es doch Theorätisch ne Cremige Vorstellung...
Nein, das ist keine cremige Idee, da der Login etc. ja eh schon sicher ist.
Die Problematik liegt ganz einfach darin, dass wenn ein Angreifer Zugriff auf den Server hat, die eigentlichen Seiten - welche an den Browser gesendet werden - manipulieren könnte.
Also könnte ein Angreifer sämtliche Verschlüssellungen aushebeln, um sich das eigentliche Pass zusenden zu lassen.
Ausserdem würde dein Vorschlag bedeuten, dass User sich alle Naselang ein neues Passwort einfallen lassen müsste, um sich einzuloggen...
Und es hätte zur Folge, dass jedes mal wenn das Passwort geändert wird, sämtliche Daten erst einmal entschlüsselt werden müssen, um sie anschliessend mit dem neuen Key wieder zu verschlüsseln.
Je nach Menge der Daten - könnte dies ein langes Aus für die Benutzbarkeit bedeuten...
Ne er(Loginscript) hängt immer wenn ein user sich einloggt die daten ran und verschlüsselt es dann, dann kommt der selbe hash raus wie in der db. Wenn nun ein Hacker irgend nen string findet der den selben hash ergibt wird es ja wieder dran gehängt und es kommt ein ungültiger hash raus
Achso meinst das...
Ja, ok. Ist eine Möglichkeit.
Dieses ist aber auch nur solange sicher, wie der Angreifer keinen Zugriff auf den Server hat.
Felix Kaiser
26.06.2006, 09:52
Wenn die Sicherheit in dieser Art und Weise gefährdet werden kann, allein durch Kenntnisnahme eines Hashwertes, dann wäre es doch für den Moment eine fixe und kluge Lösung, zwei unterschiedliche Hashverfahren parallel einzusetzen. Schließlich müsste man nicht aus einem Hash irgendeinen Wert bestimmen, der auch einfach nur zu diesem Hash führt, sondern müsste dieser Wert dann auch bei dem anderen Hash dort zu genau demselben Ergebnis führen. Ich denke da nützen die heutigen Hashdatenbanken auch nicht viel.
Ja...ist richtig.
Aber wie gesagt, es wird ja nur das Pass zum Einloggen MD5-hashed.
Die Verschlüsselung der Texte etc. erfolgt ja eh via Blowfish.
Aber ich habe bereits eine Lösung gefunden.
Nun muss sie halt mit einem Firefox Plugin leben, welches vorher einen MD5-Hash des Seiten-Inhalts erstellt und vergleicht.
Das macht ein Manipulieren der eigentlichen Seiten selbst bei Zugriff auf den Server nahezu unmöglich.
vBulletin® v3.8.6, Copyright ©2000-2012, Jelsoft Enterprises Ltd.