[Orolhawion]

Anmerkung der Projektleitung

Diese Diskussion ist auf Basis folgender Nachricht entstanden: http://www.developers-guide.net/foru...hen-und-finden

Die Diskussion wurde als eigenständiger Thread abgespalten, da sie so im geeigneteren Forum geführt werden kann.

hab das gestern auch gelesen und direkt mal mit nem alten passwort von mir ausprobiert. es funktionierte nicht. also ich hab nach eingabe des md5-hashes nicht das passwort bekommen. entgegenwirken.. hmm.. man macht vielleicht triple-md5 oder so.. halt so, dass die checksumme der checksumme der checksumme des passworts in der db als klartext steht. oder auch zwischendurch mal den sha1-hash mit md5 behandeln.. nur son gedanke..

edit:

$string = "1"; md5("1") -> c4ca4238a0b923820dcc509a6f75849b (20300 hits bei google)

$string = "c4ca4238a0b923820dcc509a6f75849b"; md5("c4ca4238a0b923820dcc509a6f75849b") -> 28c8edde3d61a0411511d3b1866f0636 (83 hits bei google)

$string = "28c8edde3d61a0411511d3b1866f0636"; md5("28c8edde3d61a0411511d3b1866f0636") -> 40f5888b67c748df7efba008e7c2f9d2 (1 hit bei google)

$string = "40f5888b67c748df7efba008e7c2f9d2 "; md5("40f5888b67c748df7efba008e7c2f9d2 ") -> bc554ecf2b33458ff1f152433cd4c813 (0 hits bei google)

da muss man wohl doch quintuple-md5 anwenden..

[robo47]

Gibt einige möglichkeiten sowas auszubauen:
- man lässt weitere FESTE parameter mit einfließen: benutzername, registrierungsdatum, emailadresse (abhängig vom system) ...

z.B. sowas ....
md5(sha1(md5(username).md5(registrierungsdatum).md 5(passwort)))

[Neq']

Zitat von Orolhawion

hab das gestern auch gelesen und direkt mal mit nem alten passwort von mir ausprobiert. es funktionierte nicht. also ich hab nach eingabe des md5-hashes nicht das passwort bekommen. entgegenwirken.. hmm.. man macht vielleicht triple-md5 oder so.. halt so, dass die checksumme der checksumme der checksumme des passworts in der db als klartext steht. oder auch zwischendurch mal den sha1-hash mit md5 behandeln.. nur son gedanke..

edit:

$string = "1"; md5("1") -> c4ca4238a0b923820dcc509a6f75849b (20300 hits bei google)

$string = "c4ca4238a0b923820dcc509a6f75849b"; md5("c4ca4238a0b923820dcc509a6f75849b") -> 28c8edde3d61a0411511d3b1866f0636 (83 hits bei google)

$string = "28c8edde3d61a0411511d3b1866f0636"; md5("28c8edde3d61a0411511d3b1866f0636") -> 40f5888b67c748df7efba008e7c2f9d2 (1 hit bei google)

$string = "40f5888b67c748df7efba008e7c2f9d2 "; md5("40f5888b67c748df7efba008e7c2f9d2 ") -> bc554ecf2b33458ff1f152433cd4c813 (0 hits bei google)

da muss man wohl doch quintuple-md5 anwenden..

Darauf würde ich mich nicht verlassen. Es gibt mit der Rainbow Table ein mächtiges Werkzeug was sowas angeht. Freerainbowtables.com hat z.B das Konzept, nach der Registrierung einen Client auszuliefern über den jeder User quasi seine eigene Rainbow Table erstellt und diese werden auf der Webseite allgemein zusammengefasst, eben um Ressourcen zu sparen bzw. die Möglichkeit zu bieten so viele Rainbow Tables zu erstellen. Demnach sind multiple MD5-Hashes nicht lange sicher. Robo's weg halte ich da schon für interessanter, da im Normalfall es sehr lange dauern wird bis irgendwann mal jemand genau diesen String md5-hasht (wobei auch ein sha1 vorkommt und diese im "Normalfall" nicht in den Rainbow Tables vorkommen, gibt jedoch auch sha1-Tables).

[Orolhawion]

korrekt.

Zitat von Orolhawion

oder auch zwischendurch mal den sha1-hash mit md5 behandeln.. nur son gedanke..

robo hats bissel präzisiert.

[Jann Hendrik]

Zitat von Orolhawion

da muss man wohl doch quintuple-md5 anwenden..

Ich denke nicht, dass sich dadurch ein höheres Maß an Sicherheit einstellen lässt!

[Neq']

Zitat von Orolhawion

korrekt.

robo hats bissel präzisiert.

Tut mir leid, hab ich wohl übersehen. Aber im Grunde ist es nur eine Frage der Zeit bis alle Strings mit einer gewissen Länge (die sich mit den Jahren natürlich immer verlängern werden) erfasst worden sind. Die PC's werden performanter und die Technologien immer ausgereifter. Und je mehr User diese Seite unterstützen desto schneller wird das von statten gehen.

[mepeisen]

Der Punkt ist, dass es auch völlig egal ist, welches Passwort man rausbekommt. Es gibt mehr als ein Passwort, was zum gleichen MD5-Hash führt. Und mehr als ein Passwort, was zum gleichen Triple-MD5 führt usw. Du musst nur eines wissen und ob es das Original ist, ist doch völlig egal.

Du hast Hash. Du weisst, dass das zu hackende System zweimal MD5 aufruft. Und du weisst, dass Passwort X zu genau diesem Hash führt. Zack. Login. Dass der enutzer ein völlig anderes Passwort genutzt hatte, kann dir egal sein.

Was mich bei alldem wundert: Wer speichert denn ein MD5-Passwort auf dem Client ab?!?!

[Orolhawion]

Zitat von mepeisen

Du weisst, dass das zu hackende System zweimal MD5 aufruft.

woher?
ich sehe deinen punkt. habs nur grad gedanklich mal durchgespielt. du weisst den hash aus der datenbank (oder woher auch immer), also den zielhash. aber man weiss in der regel nicht, wie man darauf nun kommt (ausser man schaut ins script). und wenn ich kombinationsweise irgendwelche hashfunktionen aufrufe, in einer bestimmten reihenfolge, mit bestimmten zusatzstrings, dann komm ich grad nich dahinter, inwiefern die info den zielhash zu kennen nuetzlich sein könnte.. also angenommen, du findest nen string dessen hash genau dem zielhash gleichkommt, und du gibst diesen string im loginformular als passwort ein, dann wird doch die prozedur (kombination aus hashfunktionen) auch wieder aufgerufen, woraufhin dann bestimmt was anderes als der zielhash rauskommt, oder? mir scheint die info wie oft, bzw. welche hashfunktionen in welcher kombination genutzt werden doch sehr wichtig zu sein, um einen string zu finden, der letztendlich den zielhash ergibt.. oder ueberseh ich was?

[Neq']

Zitat von mepeisen

Der Punkt ist, dass es auch völlig egal ist, welches Passwort man rausbekommt. Es gibt mehr als ein Passwort, was zum gleichen MD5-Hash führt. Und mehr als ein Passwort, was zum gleichen Triple-MD5 führt usw. Du musst nur eines wissen und ob es das Original ist, ist doch völlig egal.

Das ist schon klar. Nur wenn der Hash eben gesalzen wird, ist das nicht mehr so einfach, aber dennoch möglich.

Zitat von mepeisen

Du hast Hash. Du weisst, dass das zu hackende System zweimal MD5 aufruft. Und du weisst, dass Passwort X zu genau diesem Hash führt. Zack. Login. Dass der enutzer ein völlig anderes Passwort genutzt hatte, kann dir egal sein.

Wenn du das Passwort X bereits besitzt, brauchst du keinen Hash mehr und auch nicht die Routine zu wissen. Wenn du nur den Hash kennst, brauchst du eben genau solche Rainbow Tables, es wird sozusagen enthasht.

Zitat von mepeisen

Was mich bei alldem wundert: Wer speichert denn ein MD5-Passwort auf dem Client ab?!?!

MD5-Passwort auf dem Client speichern? Der Client erzeugt einfach willkürliche Strings die gehasht werden und dann auf den Webserver gesendet werden. So wird jeder String den es gibt durchgenommen (das haben sie zumindest vor) und von irgendeinem User erstellt, das läuft so wie Torrents.

[mepeisen]

Zitat von Neq'

Das ist schon klar. Nur wenn der Hash eben gesalzen wird, ist das nicht mehr so einfach, aber dennoch möglich.

Die wirkliche Hürde ist, dass man hier einen zusätzlichen Zugriff auf die Datenbank bräuchte. Bei ungesalzenen, die beispielsweise als Cookie auf dem Client abgelegt werden, ist der Angriff als solches viel einfacher. Aber ob mit oder ohne Salt: Es ist (MD5 und Salz vorausgesetzt) leicht herauszubekommen.

Wenn du das Passwort X bereits besitzt, brauchst du keinen Hash mehr und auch nicht die Routine zu wissen. Wenn du nur den Hash kennst, brauchst du eben genau solche Rainbow Tables, es wird sozusagen enthasht.

X stand für ein Passwort, was dem Hacker nicht bekannt ist

MD5-Passwort auf dem Client speichern? Der Client erzeugt einfach willkürliche Strings die gehasht werden und dann auf den Webserver gesendet werden. So wird jeder String den es gibt durchgenommen (das haben sie zumindest vor) und von irgendeinem User erstellt, das läuft so wie Torrents.

Das wirkliche Problem entsteht doch erst, wenn der MD5-Passwort-Hash "offen" zugänglich ist. Beliebt ist ja, das per URL zu übergeben, weil jemand beispielsweise Cookies deaktiviert. Im Forum möchte nun jemand ein anderes Thema verlinken und prompt landet der MD5 öffentlich lesbar im Forum. Das wäre ein einfaches Szenario, wo sowas greift. Wenn ein Hacker erst soweit ist, dass er die Hashaes aus einer Datenbank holt, hilft auch kein Salz mehr oder eine andere Verschlüsselung, denn dann lässt sich alles knacken.

[Neq']

Zitat von mepeisen

Das wirkliche Problem entsteht doch erst, wenn der MD5-Passwort-Hash "offen" zugänglich ist. Beliebt ist ja, das per URL zu übergeben, weil jemand beispielsweise Cookies deaktiviert. Im Forum möchte nun jemand ein anderes Thema verlinken und prompt landet der MD5 öffentlich lesbar im Forum. Das wäre ein einfaches Szenario, wo sowas greift. Wenn ein Hacker erst soweit ist, dass er die Hashaes aus einer Datenbank holt, hilft auch kein Salz mehr oder eine andere Verschlüsselung, denn dann lässt sich alles knacken.

Auch wenn er offen zugänglich ist, heißt das noch nicht das dieser Hash schon geknackt wurde. Klar, Rainbow Tables vereinfachen und verschnelleren den Vorgang beim "entschlüsseln", trotzdem muss dieser Hash noch nicht entschlüsselt worden sein.

Dein folgender Satz drückt genau das aus, was ich die ganze Zeit sagen will:

Zitat von mepeisen

Wenn ein Hacker erst soweit ist, dass er die Hashaes aus einer Datenbank holt, hilft auch kein Salz mehr oder eine andere Verschlüsselung, denn dann lässt sich alles knacken.

[mepeisen]

Zitat von Orolhawion

aber man weiss in der regel nicht, wie man darauf nun kommt (ausser man schaut ins script).

Ich setze mal voraus, dass man leicht an die Hashes kommt, beispielsweise werden sie in Cookies auf dem Client-Rechner abgelegt, um einen "dauerhaften Login" zu erzeugen. Denn wenn man erst auf eine Datenbank zugreift als Hacker, hat man meistens auch schnell Zugriff auf Scripte oder Salts usw.

Nun nutze man das System selbst. Man generiert also einen Account und robiert mehrere Passwörter aus. Dabei werden ja immer neue Hashes generiert. Man hat also mehrfache Zuordnungen zwischen Hashes und Passwörtern. Die gleichen Programme, die die Rainbow-Tables erzeugen können, sind auch in der Lage, unbekannte Hashes mit einzubeziehen, sobald du mehrere funktionierende Zuordnungen zwischen Hashes und Passwörtern hast. Für die Salts gilt auch, dass es mehrere Salts gibt, die gleich funktionieren, man also nicht zwingend den Salt kennen muss. Auch wenn die Wahrscheinlichkeit niedriger ist, einen funktionierenden Salt zu errechnen, so dass die Zeitdauer bzw. Rechenleistung deutlich steigt.

Einen Schönheitsfehler hat das ganze "leider" (oder zum Glück) : Generiert man zufällige, gute Salts, klappt es nicht mehr. Insofern wären also Salts, die sich von User zu User unterscheiden, eine ziemlich stabile Lösung.
Edith sagt: Wenn man aber pro User zufällige Salts mit einbezieht, muss man diese wiederum in der Datenbank irgendwie ablegen und daraus ergibt sich wiederum, dass einer, der in die Datenbank kommt, wieder leichtes Spiel hat.

[devar]

Zitat von mepeisen

Einen Schönheitsfehler hat das ganze "leider" (oder zum Glück) : Generiert man zufällige, gute Salts, klappt es nicht mehr. Insofern wären also Salts, die sich von User zu User unterscheiden, eine ziemlich stabile Lösung.
Edith sagt: Wenn man aber pro User zufällige Salts mit einbezieht, muss man diese wiederum in der Datenbank irgendwie ablegen und daraus ergibt sich wiederum, dass einer, der in die Datenbank kommt, wieder leichtes Spiel hat.

Eine mögliche Lösung wäre die Salts an die Passwörter dran zu kleben.
Das würde zwar die länge des Passwort verlängern, gäbe aber die Möglichkeit
in der Generierung nochmals zu variieren. Man könnte die Salts vorne, hinten, in der Mitte oder sonst wo "verstecken".

Wobei mir noch keine Stabile Lösung zum Dynamischen positionieren der Salts eingefallen ist. Derzeit denke ich über eine PrimeryKey Steuerung nach, wobei das eine "Reservierung" des PrimeryKey(zB ID) und somit eines Datensatzes erfordern würde ....
Wie gesagt mir ist da noch nicht die zündelnde Idee gekommen.

[Jann Hendrik]

Kann man nicht einfach den salt jedes Mal, wenn es einen erfolgreichen login gab austauschen und damit den md5-hash verändern?

Wer dann den hash meines Passwortes hat (ggf. und salt) der kann damit dann nichts mehr anfangen, sofern er nicht länger direkten Zugriff auf die db hat..

Wäre das sinnvoll?

[mepeisen]

Generell sind dynamische Salts quasi nicht zu knacken, wenn man keinen direkten Zugriff auf die DB hat und sie nicht irgendwo versehentlich zum Client geschludert werden. Und wenn sie dann sogar noch bei jedem neuen Login ausgetauscht werden, ist es noch unmöglicher.
Aber wenn man einen MD5 des Passworts zum Client geschleust hat, kann den ein Trojaner auch immer noch klauen, auch wenn das MD5 bei einem Login-dynamischen Salt nur begrenzt gültig wäre. Alles, was man zum Client schaufelt, ist im Endeffekt unsicher.

[Jann Hendrik]

klar - alles was vom client kommt ist potentiell unsicher; egal ob man das dort sicher dort hinbekommen hat, oder nicht.

Darauf beruht ja wohl auch das wichtigste Prinzip eines Angriffes...

[devar]

In wie weit mach so was (siehe Beispiel) Sinn?

PHP-Code:

<?php
// NUR EIN BEISPIEL //
class Auth {
    /**
    *    #snip#
    **/
    public static function generateHash ( $plainText , $pos , $salt = null ) {
        if ( $salt === null )
            $salt = sprintf ( "%06x" , mt_rand ( 0, 0xffffff ) );
        
        if ( $pos % 2 )
            return $salt . sha1 ( $plainText . $salt );
        else 
            return sha1 ( $salt . $plainText ) . $salt ;
    }

    public static function checkHash ( $plainText , $hash , $pos ) {
        if ( $pos % 2 )
            $salt = substr ( $hash , 0 , 6 );
        else 
            $salt = substr ( $hash , -6 );

        return ( self::generateHash ( $plainText , $pos , $salt ) == $hash ) ? true : false;
    }
    /**
    *    #snip#
    **/
    public function login (  ) {
        /**
        *    $this->data = Daten aus Formular. Dursucht, gewaschen, sicher...
        *    $someone = Datensatz aus Datenbank, ausgewählt nach zB $this->data['form']['name']
        *
        *    #snip#
        **/

        if ( self::checkHash ( $this->data['User']['password'] , $someone['User']['password'] , $someone['User']['id'] ) ) {
            // benutzer erkannt, passwort ok.... 
            // Hash neu generieren & in die Datenbank packen
            $this->renewHash ( $this->data['User']['password'] , $someone['User']['id'] ); 
            // Benutzer zum Content weiterleiten oder was auch immer
        } else {
            // was man eben so tut wenn das Passwort falsch ist
        }
    }
    
    private function renewHash ( $plainText , $userId ) {
        // Datensatz holen
        $someone = $this->User->getById ( $userId );
        // Passwort hash ändern
        $someone['User']['password'] = self::generateHash ( $plainText , $someone['User']['id'] );
        // Datensatz speichern
        $this->User->save ( $someone );    
    }
    /**
    *    #snip#
    **/
}

?>

Und angenommen das ist gut so und auch brauchbar...
Was gebe ich den Benutzer als Keks zum Wiedererkennen bzw. Automatisch einloggen?

Ich den da an eine Identity generiert aus UniqueFeld ( zB Email oder Benutzername ) , DatensatzID(?bei der ID bin ich mir noch nicht sooo sicher?) & LastLoginTimestamp ) und wie das Passwort gehasht.
zusammen mit den Rohdaten in ein Array... serialize drüber und in den Keks packen. Beim Autologin kann man nachschauen ob die Cookie Daten in sich noch Konsistent sind und dann gegen die Datenbank prüfen...

Ist etwas nicht Koscher kann man intern die Nötigen schritte ablaufen
und nach außen hin dem Benutzer eine Fehlermeldung + Formular präsentieren.

[Neq']

Hälst du es für sinnvoll wenn du den Salt direkt vor/nach dem sha1-Hash ankettest? Ich weiß, du brauchst es wieder zum entsalzen, da würd ich mir jedoch was anderes überlegen. Außerdem würde ich noch immer md5 bevorzugen, sha1 wurde schon vor längerer Zeit geknackt.

[devar]

Zitat von Neq'

Hälst du es für sinnvoll wenn du den Salt direkt vor/nach dem sha1-Hash ankettest? Ich weiß, du brauchst es wieder zum entsalzen, da würd ich mir jedoch was anderes überlegen. Außerdem würde ich noch immer md5 bevorzugen, sha1 wurde schon vor längerer Zeit geknackt.

It's a sample script

Ich bin noch am überlegen. Da in meinen Gedanken jeder User einen andres Salt bekommt muss ich bzw. die Applikation wissen wo es zu finden ist.

Mit der Variante Salt mit in den Datensatz zu speichern kann ich mich noch weniger anfreunden. Und da wird es mit Alternativen knapp....

[mepeisen]

Zufallssteuerung ist ein witziges Thema. Also das Salz abhängig von einem Zufall, der sich aus einer Random-Funktion ergibt, erzeugen. Dann taucht er nicht mal in einer Datenbank auf. Man könnte den Random anhand der User-ID oder des registrierungszeitstempels initialisieren und dann eine Nummer in der Datenbank abspeichern, die immer mal geändert wird und angibt, die wievielte Zufallszahl für den Salt genutzt wird. Solche und ähnliche Spielereien sind dann quasi nicht mehr zu knacken. Und man braucht dann immer beides, sowohl Script als auch DB, um den zu knacken.