ice-breaker schrieb:
Ich sagte doch, wenn es dich glücklich macht, dann kannst du auch einen globalen Salt und einen Salt pro User gleichzeitig nutzen, dann hast du das Beste aus beiden Welten.
Das ist, wie ich finde, die einzig sinnige Lösung. Denn wenn du wirklich 1 Salt pro User nutzt, dann rechnest du im Endeffekt nur damit, dass für deine Salts keine RTs existieren. Das ist aber eher eine Zeitfrage.
Du erinnerst dich aber schon daran, dass Hashes deterministisch und nicht einzigartig sind?
ein md5($a) wird für das gleiche $a somit immer den gleichen Hash erzeugen. Mit deinem globalen salt $salt hast du nun das Problem, dass 2 Personen mit gleichem Plaintext-Passwort $pw den gleichen String $a erzeugen und somit den gleichen Hash haben.
Der Hash ist nicht einzigartig.
Das ist mir schon klar. Deshalb zwingt man seine User auch dazu, etwas sicherere PWs zu verwenden. So eine Passwortstärke-Anzeige auf JS-Basis macht beim Anlegen des Accounts schon teilweise viel aus. Wenn man ihm dann sein "rotes" PW auch noch um die Ohren haut und erst ab "gelb" überhaupt zu lässt, dann hat man schon ein Problem weniger.
du musst dich nicht auf Rainbowtables begrenzen, dann nimm Bruteforce, und den Bruteforce-Angriff stört das doppelte Hashing nicht, es macht die Laufzeit nur länger, wobei die Rainbowtable eben unnütz wird.
Hängt vom Grad der Kompromittierung ab. Du kannst z.B. mal versuchen ein PW zu bruteforce'n, dass nach 3 Fehlversuchen für 15Min geblockt wird... oder bei dem jeder PW-Check durch hirnlose Schleifen künstlich auf 500ms hochgedrückt wurde.
Für viele Angriffe in realistischer Zeit muss man davon ausgehen, dass Zugriff aufs Dateisystem, nicht nur auf die DB, ermöglicht wurde. Wenn es schon so weit ist, dann muss man Passwörter gar nicht mehr knacken und sich keinerlei Sorgen um Salts machen. Deine User kennen ihre Passwörter doch eh am besten und senden sie dir doch freiwillig. 2-3 Zeilen frischer Code in der Login-Funktion, schon hat man alle Credentials im eigenen Postfach, und im Zweifel hats nicht einmal jemand gemerkt.
dcobra schrieb:
Aber aus Interesse eine andere Frage zu deiner Bemerkung oben: Bei 1-9 Zeichen eine RT mit 109GB - dort sind also alle Permutationen bis 9 Zeichen drin?
In dieser immerhin RT sind nur Kleinbuchstaben, Zahlen sowie (so wie ich das verstanden hab) eben Leerzeichen. Pack ein % irgendwo in den String und er taucht nicht in diesen 109GB auf. Ich würde noch nicht einmal darauf wetten, dass diese 109GB auch unsere Umlaute umfassen, geschweige denn Accents, dieses lustige französische oe, dieses nordeuropäische durchgestrichene o, das spanische ñ,...
Wenn ich nicht total daneben liege, dann sind das 37^9 Kombinationen (26 Buchstaben, 10 Ziffern, Space). Das sind 1,299617398×10¹⁴ Kombinationen. Pack jetzt einfach nur EINEN Buchstaben mehr rein, eben z.B. é, schon werden daraus 1,652161013×10¹⁴ Kombinationen, bei gleicher Zeichenlänge, eine ~28%ige Steigerung des Aufwands durch EIN neues Zeichen.
Um diese RT auszuhebeln kannst du als User sogar dein Geburtsdatum als PW nehmen, du musst nur vorher Capslock anschalten. 8 Stellen, davon keines alphanumerisch.... ein simpler Substitutionschifre.
Um eine RT gezielt einzusetzen musst du diese RT auf dein Zielgebiet anpassen. Wenn deine User englischsprachig sind, dann kannst du getrost a-z A-Z 0-9 annehmen. Hast du einen Deutschen an der Backe, schon musst du um ßäöüÄÖÜ erweitern. Diese Zeichen hast du bei nem Franzosen wiederum nicht, dafür knallt der dir vielleicht alles mit Accents zu... und n Russen kriegst du so oder so nicht dran, der pumpt dir kyrillische Passwörter in die Datenbank. Der braucht n völlig neuen Ansatz.
Der effektivste Weg gegen Passwörter vorzugehen ist und bleibt Social Engineering. Knacken kostet Zeit, die Leute zur Preisgabe zu überreden erfordert nur Köpfchen.
Nachtrag zur Erzeugung von Salts:
Wie wärs mit "pwgen -1ys 50" ? natürlich vorausgesetzt, das Paket existiert im System...
Reproduzier mal dieses Salt: Pf&]wKb,~"\>Z:NTylcrn~!*rt~o1>e%7L`V@{,3)7j/N7qYS^
Ja ist klar dass RTs nur eine Möglichkeit darstellen.
