FIAE2k4 Geschrieben 11. Oktober 2007 Geschrieben 11. Oktober 2007 hallo erstmal! ich bin momentan dabei, mich in das thema kryptographie einzuarbeiten. zu diesem thema gehören natürlich auch die hashes. nun hab ich mir etwas überlegt und wollte dazu einmal die meinung von anderen hören die sich damit auskennen. wie sicherlich bekannt ist lassen sich MD5 hashes relativ leicht per rainbow tables cracken. nun, hasht man aber einen string, also beispielsweise ein passwort nochmals, müsste sich doch die warscheinlichkeit eines crackens um einen großen faktor verringern. warum ich so argumentiere: stellt euch einmal das passwort 'abc' vor. es wäre sicherlich sehr schnell zu knacken. erstens durch die kürze und zweitens durch die fehlende groß/kleinschreibung, zahlen und sonderzeichen. würde man sich also rainbow tabellen für passwörter mit einer länge bis max 5 zeichen erstellen die das alphabet in kleinbuchstaben enthält hätte man lediglich 26^5 (=11881376) möglichkeiten. also relativ wenig. wie bekannt ist gibt md5 einen string mit 32 zeichen bestehend aus hex aus. würde man diesen hash des passwortes also nochmals hashen müsste ein angreifer 16^32 (=3,4028236692093846346337460743177e+38) möglichkeiten in seine rainbowtable mit einbeziehen, da 32 stellen und jede stelle 16 (HEX) kominationen darstellen kann. man würde doch so, eher die sicherheit eines simplen passwortes erhöhen, denn vom 2. hash auf das ausgangspasswort zu kommen halte ich für recht schwierig bis unmöglich. die rainbow tables wären einfach utopisch groß. und da es bisher nicht möglich war kollisionen in md5 zu errechnen. ich habe diese idee bereits anderen geschäftskollegen erklärt, allerdings haben die mich nicht verstanden bzw. den eigentlich hintergrund nicht erkannt. ich hoffe hier gibt es leute die sich besser auskennen. evtl. mache ich dazu auch noch ein paar versuche mit rainbow tables, mal schauen... Gruß Ausgelernter FI-AE (2004-2007) Zitieren
dr.dimitri Geschrieben 11. Oktober 2007 Geschrieben 11. Oktober 2007 Ich versteh das allerdings auch nicht so ganz. Wenn Du einen 16Byte MD5 Wert nochmal in MD5 umwandelst, bekommst Du wieder einen 16Byte MD5 Wert. Jemand muss den String also nur 2 mal durch den Algorithmus laufen lassen und fertig. Im schlimmsten Fall verdoppelt sich also die Rechenzeit. man würde doch so, eher die sicherheit eines simplen passwortes erhöhen Bevor jemand einen Hashwert knacken kann, muss er erstmal an den Hash herankommen. Dies bedingt zumindest Leserechte auf eine Datenbank oder Datei. Wer soweit kommt, weiß mit Sicherheit auch, welche Regeln der Passwortvergabe zugrundelegen und wird bei einem (falls möglich) simplen Passwort mit einer Brute Force Attacke schneller zum Ziel kommen. Im schlimmsten Fall hat er sogar Schreibrechte auf die DB/Datei und setzt den Hash auf einen von ihm gewünschten Wert. Wieso verwendest Du eigentlich nicht SHA256? Damit hast eine wirkliche Erhöhung des Werteraums anstatt irgendwelche seltsamen doppel Hashes zu speichern. Dim Zitieren
littledjango Geschrieben 12. Oktober 2007 Geschrieben 12. Oktober 2007 Deswegen verschlüsselt man ja nicht nur einfach einen String mit MD5, sondern nimmt etwas "Salz" dazu :-). Also eine Schlüsselbasis für die Verschlüsselung. Schon ist es wesentlich schwerer das über eine Rainbowtable zu knacken Zitieren
dr.dimitri Geschrieben 12. Oktober 2007 Geschrieben 12. Oktober 2007 Naja wenn Du den Hash auch noch verschlüsselst, dann hast wieder das Problem, das du das Passwort bzw. den Key irgendwo ablegen musst wo auch gleichzeitig deine Anwendung irgendwie drauf Zugriff hat. Ich halte sowas nicht für besonders praktikabel und die Anwendungsentwicklung wird damit auch nicht einfacher. Meiner Meinung nach sollte zum einen von der Anwendung ein vernünftiges PW gefordert werden (nicht zu schwer, sonst klebt's bloß wieder am Monitor). Dann per SHA256 (oder auch SHA512) einen Hash Wert erzeugen und diesen in einer verschlüsselten Datenbank ablegen. Oracle bietet dazu beispielsweise das sog Transparent Data Encryption (TDE) an, bei dem ganze Tabellen oder auch nur einzelne Spalten transparent verschlüsselt werden. Damit solltest, was die reine Speicherung des Passwortes betrifft, schon mal sehr gut aufgestellt sein und musst keine Kapriolen drehen. Dim Zitieren
FIAE2k4 Geschrieben 12. Oktober 2007 Autor Geschrieben 12. Oktober 2007 vielen dank für eure antworten wenn ich mir das so überlege macht es wirklich keinen sinn daten mehrfach zu hashen. wie gesagt, wollte ja mal andere meinungen dazu hören. @dr.dimitri: linux verwendet beispielsweise auch salt werte die das cracken mit rainbowtables wesentlich erschweren bis unmöglich machen. windows hat das bisher nicht getan, also waren dort die NTLM und LM passwörter einfach zu knacken (aber da gibt es noch weitere gründe...). wie es in vista aussieht kann ich nicht sagen, da ich vista absolut nicht ausstehen kann und mich daher auch nicht damit auseinander gesetzt habe. wie bekannt ist legt man also den salt wert vor dem hash in der datenbank ab. beispiel: passwort = abc salt = 10 ausgabe = "10" + "abc" = 10:e8dfaaca99a7eab5dbb4b4ba651ece01 viele andere system machen es also nicht anders sicherlich könnte ich SHA256 verwenden, das wäre eine sinnvolle idee. implementiert ist das in PHP ja schon, wofür ich das später dann auch benötige. in den luxus von oracle DB's kann ich leider nicht kommen...mysql wird reichen müssen. trotzdem besten dank für eure aussagen hat mir mal wieder den horizont erweitert. Gruß FiAe Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.