Passwort Sicherheit

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Passwort Sicherheit

    HiHo,

    Derzeit werden bei mir die Passwörter mit sha1 und md5 Verschlüssellt sprich Passwort abwechselnd durch sha1 ud md5 jagen.
    Sicherer wie nur sha1 oder md5 finde ich das nicht.
    Vor einigen Tagen bin ich auf

    php-einfach.de/improved_hash_algorithm.php gestossen und halte es doch für ne Sichere Lösung.


    Nun arbeitet er mit microtime, dieser ist ja nicht immer der selbe und die Vermutung liegt nahe das am Ende das eingegebene PW mit dem dem aus der Datenbank nicht übereinstimmt.

    Wie realisiert Ihr das? Mit einem Ähnlchen Prinzip? Wie sollte man eurer Meinung nach die PW Verschlüsseln?
    Vorschläge, Beispiele, Lösungen, alles ist willkommen.

    Gruß
  • Ich löse das immer folgendermaßen:

    • Nutzung von Salts (heißt irgendeinen zufälligen String an das Passwort des Benutzers anhängen)
    • Nutzung von Runden (wie in dem Beispiel, eben pro Benutzer zufällig das Passwort X mal durch sha1 jagen


    Vorteile von Salts: Ausschaltung von Rainbow-Tables
    Vorteile von Runden: Zeit. Es dauert einfach länger, bis das Passwort gehasht ist. Das mag nicht viel sein, summiert sich aber bei Millionen von Kombinationen im Falle eines Bruteforce Angriffes.
    Jan Thurau
    Software and Systems Engineer
    janthurau.de

    [Blockierte Grafik: http://www.pageheroes.com/media/image/pageheroes_logo.png] - We get your page working!
  • Das mehrfache anwenden des ein und selben hash verfahren bring überhaupt keine Sicherheit mehr nur unötige Server auslastung.
    Ich empfehle dir Sha256 zu verwenden plus Salt. Am besten den salt aus dem Password selbst generieren so brauchst du den Salt nicht extra speichern.



    Schlim das der Blog Beitrag ersteller nicht den Unterschied zwischen einem Hash und Verschlüsseln kennt. :S

    Mfg Splasch
  • Das mehrfache anwenden des ein und selben hash verfahren bring überhaupt keine Sicherheit mehr nur unötige Server auslastung.


    Diese "unnötige" Server auslastung. Wenn wir mal Ehrlich sind handelt es sich meistens eh nur um kurze millisekunden. Auf die kommt es auch nicht an.
    Über die Serverauslastung kann man sich nun wieder Tagelang Streiten aber das ist hier nicht das Thema und sollte bei meinem 2 Servern auch keine Rolle spielen.

    Abgesehen von dem Unterschied zwischen einem Hash und Verschlüsseln in diesem Blog, was haltet Ihr von dem Beispiel?
  • splasch schrieb:

    Das mehrfache anwenden des ein und selben hash verfahren bring überhaupt keine Sicherheit mehr nur unötige Server auslastung.

    Angenommen das Berechnen eines Hashes dauert 0,1 Sekunden beim Login. Dann dauert der Login eben 0,1 Sekunden länger, weil wir das Passwort 400x hashen. Wen interessiert das?
    Das Berechnen eines Rainbow-Tables mit 100 Mio. Einträgen dauert direkt mal 100.000.000*0,1 Sekunden länger, als mit einfachem Hashen. Damit wären wir bei 100 000 000 * 0,1 / 60 / 60 = 2 777,77778 Stunden längerer Berechnungszeit für einen Angreifer. PRO LOGIN. Für jedes Passwort müssen die Berechnungen entsprechend der Rundenzahl sowie des Salts erneut vorgenommen werden. Und die Zeit kann man nutzen, die Kunden entsprechend zu informieren und Maßnahmen ergreifen, die die Schäden zumindest weiter eindämmen können.

    Und da das bisschen Rechenleistung bei heutigen CPUs fast nichts mehr kostet, sollte sie einem die zusätzliche Sicherheit durchaus Wert sein.
    Jan Thurau
    Software and Systems Engineer
    janthurau.de

    [Blockierte Grafik: http://www.pageheroes.com/media/image/pageheroes_logo.png] - We get your page working!
  • Und da das bisschen Rechenleistung bei heutigen CPUs fast nichts mehr kostet, sollte sie einem die zusätzliche Sicherheit durchaus Wert sein


    Ist unsin bring keine zusätzliche Sicherheit. Wenn du mehr Sicherheit haben willst dann kanst du den Hash danach noch verschlüsseln das würde wenigsten sin machen.

    Spätersten jetzt sollte man den Unterschied zwischen Hash und Verschlüsseln kennen!

    Siehe auch : mcrypt_create_iv und mcrypt_encrypt

    Mfg Splasch

    Ps:
    Übrings durch mehrfaches Hashen erhöhst du auch deutlich die Kollisionen!

    Hash + salt + Verschlüsseln und gut ist.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von splasch ()

  • Wie soll Verschlüsseln jetzt mehr Sinn machen? Die Anwendung muss die Daten ja entschlüsseln können, spätestens bei Zugriff auf die Anwendung erhält ein Angreifer also diesen Key.

    Man kann sich jetzt sicher darüber streiten, ob Mehrfachhashing Sinn macht, oder nicht. Aber da gibts schon massig Diskussionen im Internet.

    heise.de/security/artikel/Pass…53931.html?artikelseite=2
    en.wikipedia.org/wiki/Key_stretching

    HEISE schrieb:

    Brute-Force-Angriffe lassen sich durch das gewollte Verlangsamen des benutzten Hash-Algorithmus beziehungsweise durch viele Wiederholungen des Hash-Vorgangs unattraktiv machen. Für den Anwender ist die Geschwindigkeit dagegen kaum von Belang: Ob die Prüfung eines eingegebenen Passwortes auf einem System beim Login nun 1 Mikrosekunde oder 1 Millisekunde dauert, merkt er nicht. Einen Passwortknacker würde es aber um den Faktor 1000 ausbremsen – statt 100 Millionen Passwörter pro Sekunde kann er nur noch 100.000 pro Sekunde durchprobieren. Ein Brute-Force-Angriff auf das Kennwort "P4ssW0r7" würde so 48 Jahre statt 18 Tage.


    HEISE schrieb:


    [..]Das Verfahren ist als Password-Based Key Derivation Function 2 (PBKDF2) standardisiert und findet etwa bei WLANs mit WPA-PSK-Schlüssel Anwendung. Auch Smartphones nutzen PBKDF um Backup-Dateien vor dem Export mit einem Passwort zu verschlüsseln. Auch hier bremst es Knackversuche erfolgreich aus.


    Aber nur mal so:
    Angenommen, ich hashe "test", dessen Hash 098f6bcd4621d373cade4e832627b4f6 ist. Und jetzt hashe ich diesen 10^4x mit sha1 und Salt. Dann ist die Wahrscheinlichkeit, dass der letzte Hash mit dem eines anderen ROhwertes übereinstimmt, genau so hoch, wie wenn ich das ganze nur 1x hashe. Es wird ja schließlich einfach der erste Hash immer weiter gehasht, so dass Kollissionen nur bei diesem eine Rolle spielen. Eine Kollission im "End-Hash", der in der Datenbank steht, hilft ja nicht weiter - beim Login würde dieser schließlich noch 10^4x gehasht werden.
    Jan Thurau
    Software and Systems Engineer
    janthurau.de

    [Blockierte Grafik: http://www.pageheroes.com/media/image/pageheroes_logo.png] - We get your page working!
  • Wie soll Verschlüsseln jetzt mehr Sinn machen? Die Anwendung muss die Daten ja entschlüsseln können, spätestens bei Zugriff auf die Anwendung erhält ein Angreifer also diesen Key.


    Nein wenn du es Schlau machst hat der Angreifer nicht den Key (Das verschlüsselung Passsword). Selbt wenn er Zugang zum Quellcode hat.
    Wie das Funktioniert?

    Und zwar so das Password wird aus dem Password des User Generiert für die Verschlüsselung. So wird jedes User password erstens mit einem anderen Password verschlüsselt und kann aber immer durch eingabe des Richtigen Passwortes wieder entschlüsselt werden.

    Zum Generieren des Verschlüsselung Password überlegst du dir einen Algorytmen.

    Zum Beispiel password muss mindesten 6 Zeichen lang sein.

    Dann verstauscht du einfach die Zeichen nach einer bestimmten Reihenfolge. Zb 4,1,3,5,2
    So ensteht dann nun aus dem Passwort des User: BauernHof
    Das verschlüsselungs Password laut dem Algorythmen: eBura

    Somit wird dann das Password BauerHof mit dem Password eBura verschlüsselt und nirgendswo im Quellcode erschein das Password für die Verschlüsselung da sich das Password aus dem Password selbst generiert.

    Weiteres Beispiel
    Andere User sein Password: LiegeStuhl
    Verschlüsselungs Password laut dem festgeleten Algorythemn: gLeei

    So hast du für jedes Password auch ein anderes Verschlüsselungs Password. Das Entschlüsseln erfolgt dann nach dem selben Prinzip. Der User gibt sein Passwort ein daraus wird wieder mit dem selben Algotytmen das richtige Entschlüsselung Password generiert und geprüft ob die Eingabe richtig war.

    Ich hoff das das nun mal so weit verständlich war. Daher macht es sehrwohl dann sin die Passwörter zu verschlüsseln dadurch erhöt sich die Sicherheit enorm statt nun 10 oder 100 mal den selben Hash Anzuwenden.

    Selbt wenn nun der Angreifer den Algorythmus kenn kann er damit überhaupt nix anfangen. Die Sicherheit läst sich noch weiter erhöhen wenn man die Algortmus länge ändert so das daraus ein Passwort entsteht mit 16 oder mehr stellen. Im Beispiel hat es nur 5 Stellen der einfach halber zum erklären. (zb. 4,1,3,5,2,3,2,4,5,1 unsw.)

    http://www.phpgangsta.de/schoener-hashen-mit-bcrypt


    Nun die Email Adresse ins Hash verfahren mit einzubeziehen geht doch etwas weit weg von der Eigentlichen Password Sicherheit. Wenn der User seine Mail Adresse ändere were damit sein Password auch nicht mehr gültig und das kans ja wohl auch nicht sein.

    Mfg Splasch

    Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von splasch ()

  • splasch schrieb:

    Nun die Email Adresse ins Hash verfahren mit einzubeziehen geht doch etwas weit weg von der Eigentlichen Password Sicherheit. Wenn der User seine Mail Adresse ändere were damit sein Password auch nicht mehr gültig und das kans ja wohl auch nicht sein.


    Dazu müsste man auch die Idee in dem Artikel verstehen.
    Was wäre das Schlimmste, was er tun kann? Richtig, er ändert das Passwort oder die E-Mail Adresse. Wie kann ich das am effektivsten verhindern? Ganz klar, ich muss ihn zwingen zur Überprüfung das alte Passwort einzugeben. Durch die Kopplung der Hashes an die E-Mail kann ich das gar nicht vergessen