Passwörter sicher abspeichern

  • Najo also der Link ist jetzt nicht wirklich hiflreich

    Ja also wenn der Angreifer Vollzugriff auf das Filesystem und die Datenbank hat hast du natürlich keine Chance das er den Salt nicht bekommen kann


    Es geht darum wenn jemand nur auf eins von beiden Zugriff hat bzw beschränkt Zugriff hat zb durch ne Sicherheitslücke

    Dodo, ob der Angreifer nun den Salt oder den Publickey weist bleibt beidesmal gleichschwer
    Salten sollte man bei RSA auch zumindest sollte der ciphertext nicht abhängig von der Länge des Passwortes sein

    mfg

    3 Mal editiert, zuletzt von Pion (16. August 2010 um 15:50)

  • Ja aber wenn er zum Beispiel nur den Hash hat, dann weiss der auch nicht, ob ich das jetzt dreissig Mal mit MD5 und SHA1 verschlüsselt habe.
    Von daher geht deine Logik vom vorvorvorherigen Post nicht gut auf.
    Da gehst du davon aus, der Hacker hat Vollzugriff und dann ist das dreissigmalige Verschlüsseln genauso unsicher, wie der Salt.

  • Da gehst du davon aus, der Hacker hat Vollzugriff und dann ist das dreissigmalige Verschlüsseln genauso unsicher, wie der Salt.

    Eben nicht: Der Vorteil am Public Key ist, dass er für jeden einsichtbar ist. Und aus ihm kann nicht mehr entschlüsselt werden. Und auch mit bekanntem Salt gibt es keine Rainbow-Tables bei RSA.

    Dodo, ob der Angreifer nun den Salt oder den Publickey weist bleibt beidesmal gleichschwer
    Salten sollte man bei RSA auch zumindest sollte der ciphertext nicht abhängig von der Länge des Passwortes sein



    Nein, das hat nicht dasselbe Gewicht. Wie oben schon erwähnt ist es bei RSA ja der große Vorteil, dass der Hacker sowohl public key, als auch ciphertext kennt.
    Die einzigen Schwachstellen, die bei RSA auftreten sind real world angriffe - und ich denke nicht, dass die jemand versuchen wird. Das zahlt sich für Online-Anwendungen nicht wirklich aus - da kostet das Equiptment schon zu viel.

    Something big is coming. And there will be pirates and ninjas and unicorns...

  • Dodo:
    Ich kann nicht ganz verstehen, warum das ein Vorteil ist, wenn der Hacker sowohl Public Key als auch Ciphertext kennt.
    Ist das eigentlich nicht gerade der Nachteil???

  • Mag sein Hauptsache ich hab dich überzeugt das ein Salt gegenüber mehrfacher Hashung sinnvoller ist (mag es nur das Userbezogene sein).
    Ich weis nicht ob es bei md5, sha1 auch der Fall ist aber es gibt Hashverfahren die sich bei nacheinander ausführung sogar vereinfachen.
    !Außerdem erhöht es die Wahrscheinlichkeit eine Kollision zu bekommen!


    Nun widmen wir uns hier über Rsa, dafür ist der Tread ja da, ansonsten finde ich bei Speicherung von Passwörtern Rsa nicht sinnvoll(bei Broutforcing geht überall). Außderm bekommst du ewig lange Passwörter. Außerdem lässt sich von der länge teilweise auf die länge des Passwortes schließen. Das sind Gründe die eindeutig dagegen sprechen....

    Ich appeliere einfach bleibt beim Standard was im Moment immer noch md5 oder sha1 ist, wenn ihr mehr Sicherheit wollt nehmt einen Salt.

    Kryptografie ist kompliziert das haben nicht wir mit unseren Wissen zu erforschen

    5 Mal editiert, zuletzt von Pion (16. August 2010 um 17:05)

  • Dodo:
    Ich kann nicht ganz verstehen, warum das ein Vorteil ist, wenn der Hacker sowohl Public Key als auch Ciphertext kennt.
    Ist das eigentlich nicht gerade der Nachteil???



    Nein darin liegt ja die Grundidee von der asymmetrischen Verschlüsselung! Es gibt zwei schlüssel: einen öffentlichen und einen privaten. Was der öffentliche verschlüsselt, entschlüsselt der private. und umgekehrt.
    Wenn jetzt aber der private Schlüssel nicht gespeichert wird, kann der ciphertext auch nicht mehr entschlüsselt werden. Im Normalfall kennt nur eine Person den privaten Schlüssel - hier niemand.
    Und trotz öffentlichem Schlüssel kann der private Schlüssel nicht berechnet werden.
    Das ist ja genau der Grund, warum RSA verwendet wird.
    Der Ciphertext, den darf ruhig jeder wissen - Nur der private Schlüssel kann den entziffern. Und dank genügend höherer Mathematik - Von Module-Berechnungen bis Galois-Feldern - ist der RSA-Algorithmus unknackbar.
    Die einzige Angriffe sind Real-World-Angriffe - Zum Beispiel kann man von der Entschlüsselungsdauer auf die Schlüssellänge des privaten Schlüssels rückrechnen - aber das fällt bei Internetanwendungen wohl weg, weil sich der Angriff nur mit Oszilloskopen durchführen lässt.

    Edit: Zusammenfassen

    Nun widmen wir uns hier über Rsa, dafür ist der Tread ja da, ansonsten finde ich bei Speicherung von Passwörtern Rsa nicht sinnvoll, bzw sogar unsicherer als mit Hash, vorallem die Länge ist hier anzusprechen (bei Broutforcing zb)

    Das ist egal - Dank der relativ hohen Dauer der Verschlüsselung hilft auch Bruteforce nichts.

    Kryptografie ist kompliziert das haben nicht wir mit unseren Wissen zu erforschen



    Nein ist es nicht. Mit etwas mathematischem Verständnis kann man die einzelnen Verfahren nachvollziehen. Ich hab lange genug mit meiner Mathematik-Professorin aus der HTL darüber gesprochen - hab immerhin mit ihrer Hilfe eine Arbeit darüber verfasst, die sogar von der Landesschulinspektorin (hat Informatik studiert) gelobt wurde.

    Something big is coming. And there will be pirates and ninjas and unicorns...

    3 Mal editiert, zuletzt von Dodo (16. August 2010 um 16:21) aus folgendem Grund: Zusammenfassen

  • Pion:
    Finde es ein bisschen seltsam dass Du MD5 hier relativ gut aussehen lässt, nachdem Du bei mir schon öfter kritisiert hast dass ich Passwörter "nur mit MD5" hashe.
    Naja mittlerweile mach ich das auch anders - 1000mal mit zwei 512bit - Algorithmen

    Das dürfte auch jede Rainbow-Table unbrauchbar machen.

  • Ich kritisierte wenn dann das du keinen Salt nimmst...Ansonsten empfehle ich auch sha in Gegensatz zu MD5 , den das gibt weniger Kollisionen

    Jetzt überleg mal wo es weniger Kollisionen gibt bei 1000 mal den selben Hash in Gegensatz zu einem Hash

    Mal ehrlich einmal Hash + Salt ist sicherer als 1000 mal das selbe

    Btw nur aus Interesse, wie lange dauert dein Script?
    Aber gegen Rainbowtables hilft die Funktion das ist unumstritten, ein $pw.'donkey'; würde den selben Effekt erziehlen.

    http://php.net/manual/de/function.hash-hmac.php

    Dodo
    Das hab ich gemeint, lieber lassen als im guten glauben eigene Hashmethoden zuschreiben weil man denkt es würde allgemein sicherer

    Naja schöne Woche euch

    3 Mal editiert, zuletzt von Pion (18. August 2010 um 04:34)

  • Btw nur aus Interesse, wie lange dauert dein Script?

    Schätze Du meinst die Laufzeit.

    Meine Messung ergibt ca. 0,02 Sek. im Durchschnitt


    Erklärst Du mir das mit dem HMAC?
    Is das sowas wie ne Salt?

  • "aber es gibt Hashverfahren die sich bei nacheinander ausführung sogar vereinfachen."
    Das kann nicht sein. Sagen wir mal wir nehmen sha1(md5(x)), das kann nicht einfacher sein als md5(x), denn md5(x) ließe sich ja dann durch Anwendung von sha1 genau so einfach umkehren.

  • Ja bei diesen ist dies nicht der Fall aber ich habe es mal bei welchen gehört kann es dir aber leider nicht sagen, ich gebe bescheid wenn ich wieder was davon höre ;)


    Ansich sollte man nicht doppel Hashen schon allein weil keinen Mehrwert bringt
    Außerdem gibts ja auch die oben genannten Nachteile

    Bin auf das Jahr 2012 gespannt dort soll ja aus diesem Wettbewerb interessantere Hashfunktionen als die die auf SHA aufbauen rauskommen

    mfg

    Einmal editiert, zuletzt von Pion (27. August 2010 um 00:51)

  • BTW: weiss jemand von einer guten RSA-implementierung in Java? Hab per google nix mit hand und fuß gefunden, also nur long's verschlüsselbar oder die keys haben iwie keine aufmerksamkeit in den codebeispielen gefunden.

    Der, der weiß dass er nichts weiß, weiß mehr als der, der nicht weiß, dass er nichts weiß.

    Wer nach etwas fragt, geht grundsätzlich das Risiko ein, es auch zu bekommen!

  • Hey danke, jetzt hab ich meine RSA-Klasse xD

    Der, der weiß dass er nichts weiß, weiß mehr als der, der nicht weiß, dass er nichts weiß.

    Wer nach etwas fragt, geht grundsätzlich das Risiko ein, es auch zu bekommen!