2016-04-07 3 views
0

Angenommen, ich habe eine Tabelle, wo ich ein Hash-Passwort und auch das Salz, mit dem das Passwort gesalzen wurde (für jeden einzelnen Benutzer).Gesalzene Passwort-Sicherheit

Basierend auf einer anderen Stackoverflow-Frage, habe ich verstanden, dass es in Ordnung ist, dass das Salz auf der gleichen Tabelle mit dem Hash-Passwort gespeichert wird.

How insecure is a salted SHA1 compared to a salted SHA512

Meine Frage ist, Wenn die Datenbank mit den Hash-Passwörter gehackt bekommen würde und dass der Benutzer würde eine Regenbogen-Tabelle für die Hash-Werte haben und die Salze in Betracht ziehen in der gleichen Tabelle mit den Hash-Passwörter gespeichert, Wäre es nicht einfach, das tatsächliche Passwort zu sehen? Sie müssten nur das Salz aus dem Passwort von dieser bestimmten Regenbogen-Tabelle entfernen.

In Anbetracht dieser, ich verstehe nicht, warum es in Ordnung ist, das Salz in der gleichen Datenbank, Tabelle mit dem Hash-Passwort zu speichern. Kann jemand bitte eine klarere Erklärung geben?

+1

* "Sie müssten nur das Salz aus dem Passwort von diesem speziellen Regenbogen-Tisch entfernen." * - Und wie würde das funktionieren?Da das Salz ein integraler Bestandteil des Hash-Prozesses ist, kann man es nicht "einfach eliminieren". Sie müssten das Salz in den Regenbogen-Tisch einarbeiten. Und da das Salz für jedes Passwort eindeutig ist, müssen Sie für jedes Salz/Passwort eine anders gesalzene Rainbow-Tabelle erstellen. Was genau ist der Punkt: Salze zwingen Angreifer, jedes Passwort einzeln anzugreifen, was eine Menge mehr Arbeit verursacht und Brute Forcing eine große Sammlung unmöglich macht. – deceze

+0

Wenn sie bereits die Datenbank haben. Es gibt nicht mehr viel zu schützen. –

+0

@deceze: Eigentlich, wenn es ein Salz gibt, würdest du als Angreifer überhaupt keinen Regenbogentisch brauchen. Warum sollten Sie jeden Klartext jedes möglichen Hashs berechnen, wenn Sie bereits den verwendeten Hash sehen? ;) Sie würden einfach das Salz zu jeder Passwortschätzung hinzufügen und dann hashen, um zu sehen, ob es übereinstimmt - auf diese Weise können Sie viel früher stoppen, als wenn Sie eine vollständige Rainbow-Tabelle erzeugen würden. – SilverlightFox

Antwort

7

Okay, Haltestelle genau dort. Wenn Sie überhaupt nach dem Salzen fragen, sind Sie bereits auf dem falschen Weg. Dies ist etwas, das sehr leicht falsch ist und es gibt so viele schrecklich schlechte Beispiele, wie man das da draußen macht, dass es einfach ist, über das völlig falsche Ding zu sehr selbstsicher zu werden.

Der einfachste richtige Weg, dies zu tun ist, um die password_hash function zu verwenden und nicht Ihre eigene skurrile Art und Weise zu tun, es zu erfinden. Dies ist tatsächlich viel einfacher und viel sicherer als das, was Sie hier in Betracht ziehen.

Die Funktion password_hash verwendet Bcrypt intern standardmäßig und es handelt sich um einen Hash, der extrem schwer zu Brute-Force-Zwecken entwickelt wurde und nicht mit Rainbow-Tabellen verwendet werden kann. Es ist auch einstellbar, so dass Sie es willkürlich noch schwieriger machen können, wenn Sie möchten.

Sie benötigen diesen Anpassungsfaktor, um Ihre Datenbank für längere Zeit zu schützen. Was heute schwer zu knacken ist, könnte in zehn Jahren trivial sein, wir wissen es einfach nicht. Sie können es jetzt schwieriger machen, um sicher zu sein, dass, wenn Ihre Datenbank irgendwie ausläuft, Sie noch für einige Zeit geschützt sind.

Das Speichern von Hash und Salz in der gleichen Tabelle ist oft eine Notwendigkeit und das Aufteilen ist in der Regel nutzlos, es ist kaum mehr Aufwand für einen Angreifer, zwei verschiedene Tabellen zu erfassen. Sie werden wahrscheinlich alles von einem Backup greifen, von dem Sie sowieso die Kontrolle verloren haben.

Moderne Cracking-Systeme stören nicht einmal an Rainbow-Tischen. Der Stand der Technik in GPU cracking is so insanely fast, dass es sinnlos macht, können gemeinsame Passwörter in Sekunden geknackt werden, seltener in Minuten, und die obskurenen in Stunden oder Tagen, wenn das sogar eine Priorität ist. Bitcoins Verwendung von SHA256 hat viele Forschungen in dieser Abteilung vorangetrieben, die diese Algorithmen für diese Art von Sicherheit größtenteils nutzlos machen. Es gibt Geräte auf dem Markt, die mehrere Billionen Hashes pro Sekunde ausführen können.

Das ist eigentlich schneller als Sie Ihren Regenbogen-Tabelle von der Festplatte lesen können. Rainbow Tische sind im Grunde Geschichte.

Die Bedrohung ist heute gigantische Wörterbücher mit bekannten Passwörtern und eine Möglichkeit, diese in eine noch astronomischere Anzahl von Varianten zu verwandeln. Diese halten die GPUs beschäftigt und können viele der weniger gebräuchlichen, absichtlich kniffligeren Kennwörter aufdecken, die Leute benutzen.