Ersetzen Klartext-Passwort für App
https://stackoverflow.com/questions/59022
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Wir speichern derzeit Klartext-Passwörter für eine Web-Anwendung, die wir haben.
Ich halte Eintreten in eine Passwort-Hash bewegen, aber ein anderer Entwickler sagte, dass dies weniger sicher wäre -. Mehr Passwörter den Hash passen könnte und ein Wörterbuch / Hash-Angriff wäre schneller
Gibt es eine Wahrheit zu diesem Argument?
Lösung
Absolut keine. Aber es spielt keine Rolle. Ich habe eine ähnliche Antwort gepostet vor:
Es ist bedauerlich, aber die Leute, auch Programmierer, sind einfach zu emotional leicht durch Argument beirren werden. Sobald er in seiner Position investiert hat (und wenn du hier bist veröffentlichen, ist er) Sie sind wahrscheinlich nicht allein ihn mit Fakten zu überzeugen. Was Sie tun müssen, ist die Beweislast zu wechseln. Sie brauchen ihn für Daten suchen, um aus, dass er die überzeugen hofft, und in so die Wahrheit zu tun lernen. Leider hat er den Vorteil des Status quo hat, so haben Sie eine harte Straße dort ankamen.
Andere Tipps
Einige Computersysteme speichern Benutzer Passwörter, gegen die vergleichen Benutzer anmelden versucht, als unverschlüsselt. Wenn ein Angreifer Zugriff auf ein solches internes Passwort zu speichern, alle Passwörter und so alle Benutzerkonten werden kompromittiert. Wenn einige Benutzer verwenden die gleiches Kennwort für Konten verschiedene Systeme, werden diejenigen sein, ebenso beeinträchtigt wird.
Sicherere Systeme speichern jede Kennwort in einer kryptografisch geschützte Form vorliegen, so dass der Zugang zu dem aktuelles Passwort wird immer noch schwierig für einen Schnüffler, der gewinnt interner Zugriff auf das System, während Validierung von Zugriffsversuchen Benutzer möglich bleibt.
Eine gemeinsame approache speichert nur ein „Gehasht“ Form des Klartextes Passwort. Wenn ein Benutzer in einem Kennwort auf einem solchen System, das Passwort Handhabung Software läuft durch einen kryptographischen Hash Algorithmus, und wenn der Hash-Wert von dem Eintrag des Benutzers erzeugt stimmt mit dem Hash in der gespeicherten Passwort-Datenbank, der Benutzer ist erlaubt den Zugriff. Der Hash-Wert ist, geschaffen durch eine kryptographische Anwendung Hash-Funktion auf einen String aus des eingereichten Passwort und, in der Regel bekannt, ein anderer Wert als Salz. Das Salz verhindert Angreifer Aufbau einer Liste von Hash-Werten für gemeinsame Passwörter. MD5 und SHA1 sind Häufig verwendete kryptographische Hash Funktionen.
Es gibt viel mehr, dass Sie zu diesem Thema auf dieser Seite lesen können. Meiner Meinung nach, und in alles, was ich habe gelesen, und arbeitete mit, Hashing ist ein besseres Szenario, wenn Sie einen sehr kleinen (<256 Bit) Algorithmus verwendet werden.
Es gibt absolut keine Entschuldigung Passwörter im Klartext auf dem Web-App zu halten. Verwenden Sie einen Standard-Hash-Algorithmus (SHA-1, MD5 nicht!) Mit einem Salz-Wert, so dass Regenbogen Angriffe unmöglich sind.
Ich verstehe nicht, wie Sie Ihre anderen Entwickler Dinge ‚mehr Passwörter könnten den Hash Match‘.
Es gibt Argument einen ‚Hash-Angriff wäre schneller‘, aber nur, wenn Sie nicht die Passwörter Salze, wie sie gehasht sind. Normalerweise erlauben Hashfunktionen Sie ein Salz zu schaffen, die die Verwendung von bekannten Hash-Tabelle eine Verschwendung von Zeit macht.
Ich persönlich würde sagen, ‚Nein‘. Basierend auf den oben genannten, sowie die Tatsache, dass, wenn Sie irgendwie Klartext setzen Sie bekommen, ein gesalzen, ist gehasht Wert von geringem Wert zu jemand versucht, in zu erhalten. Hashing bietet auch Nutzen aller ‚Look‘ Passwörter machen die gleich lang sind.
dh wenn immer ein beliebige Zeichenfolge Hashing Hash führt zu einem 20 Zeichen, dann, wenn Sie nur den Hash haben zu sehen, kann man nicht sagen, ob das Original-Passwort acht Zeichen oder sechzehn zum Beispiel ist.
Ich traf genau dieses gleiche Problem in meinem Arbeitsplatz. Was ich tat, ihn davon zu überzeugen, dass war sicherer Hashing war eine SQL-Injection zu schreiben, die die Liste der Benutzer und Passwörter aus dem öffentlichen Bereich unserer Website zurückgegeben. Es wurde als ein wichtiges Sicherheitsproblem eskaliert sofort:)
gegen Wörterbuch / Hash-Angriffe zu verhindern, sollten Sie gegen einen Token Hash, die jeden Benutzer eindeutig ist und statisch (Benutzername / join Datum / userguid gut funktioniert)
Wenn Sie nicht Salz Ihr Passwort zu tun, sind Sie vermuten, dass Rainbow Table-Angriffe (vorkompilierte Wörterbücher, die gültige Eingaben für einen bestimmten Hash haben)
Der andere Entwickler soll reden über Sicherheit stoppen, wenn Sie Passwörter in Klartext sind die Speicher und startet um die Sicherheit zu lesen.
Kollisionen sind möglich, aber kein großes Problem für Passwort-Apps in der Regel (sie sind in erster Linie ein Problem in Bereichen, in denen Hashes als Weise verwendet werden, um die Integrität der Dateien zu überprüfen).
So:. Salz Ihrer Passwörter (durch das Salz auf die rechte Seite des Passworts Hinzufügen *) und verwenden Sie einen guten Hashing algorhithm wie SHA-1 oder vorzugsweise SHA-256 oder SHA-512
PS:. Ein wenig mehr Details über Hashes hier
* ich bin ein wenig unsicher, ob das Salz an den Anfang oder an das Ende der Zeichenfolge sollte. Das Problem ist, dass, wenn Sie ein Kollisionen (zwei Eingänge mit dem gleichen Hash) haben, und fügte hinzu, das Salz der „falschen“ Seite wird nicht die resultierende Hash ändern. Auf jeden Fall werden Sie nicht große Probleme mit Rainbow Tables haben, nur mit Kollisionen
Es gibt ein altes Sprichwort über Programmierer vorgibt entcoders zu sein:)
Jeff Atwood hat einen guten Beitrag zum Thema: Sie wahrscheinlich Passwörter speichern falsch
ausführlicher antworten, ich mit allen oben genannten zustimmen, macht die Hash es einfacher in Theorie , um das Kennwort des Benutzers zu erhalten, da mehrere Passwörter den gleichen Hash übereinstimmen. Jedoch, das ist viel weniger wahrscheinlich als jemand passiert Zugriff auf Ihre Datenbank zu bekommen.
Es ist die Wahrheit, dass, wenn Sie etwas hash, ja, es wird Kollisionen sein, so dass es für zwei verschiedene Passwörter möglich sein würde, das gleiche Konto zu entsperren.
Aus praktischer Sicht aber ist das ein schlechtes Argument - Eine gute Hash-Funktion (md5 oder sha1 wäre schön) kann ziemlich garantieren, dass für alle sinnvoll Streicher, vor allem kurze, wird es keine Kollisionen. Selbst wenn es, zwei Passwörter übereinstimmen für ein Konto ist kein großes Problem - Wenn jemand in der Lage ist, zufällig Passwörter zu erraten, schnell genug, dass sie wahrscheinlich in der Lage sein, zu erhalten, haben Sie größere Probleme bekommen <. / p>
Ich würde argumentieren, dass die Passwörter im Klartext zu speichern ein viel größeres Sicherheitsrisiko als Hash-Kollisionen in dem Passwort-Matching darstellt.
Ich bin kein Sicherheitsexperte, aber ich habe das Gefühl, dass, wenn Klartext sicherer war, Hashing in erster Linie existieren würde nicht.
In der Theorie ja. Passwörter können längere (mehr Information) als ein Hash, so gibt es eine Möglichkeit, Hashkollisionen. Allerdings sind die meisten Angriffe Wörterbuch-basiert, und die Wahrscheinlichkeit von Kollisionen ist unendlich kleiner als ein erfolgreiches Direktspiel.
Es hängt davon ab, was Sie verteidigen gegen. Wenn es einem Angreifer ist Ziehen Sie Ihre Datenbank (oder Ihre Anwendung trickst in die Datenbank anzeigt), dann Klartext-Passwörter sind nutzlos. Es gibt viele Angriffe, die auf dazu verleitet, die Anwendung verlassen, um disgorge es private Daten- SQL-Injection, Session Hijacking etc. besser Es ist oft nicht die Daten zu halten, überhaupt, aber die Hash-Version so Bösewichte zu halten können es nicht leicht verwenden .
Wie Sie Ihre Mitarbeiter schon sagt, kann dies belanglos, indem Sie den gleichen Hash-Algorithmus mit einem Wörterbuch und mit Rainbow Tables besiegt werden, um die Informationen zu ziehen. Die übliche Lösung ist ein Geheimnis Salz plus zusätzliche Benutzerinformationen zu verwenden, um die Hash-Ergebnisse unique- etwas zu machen, wie:
String hashedPass=CryptUtils.MD5("alsdl;ksahglhkjfsdkjhkjhkfsdlsdf" + user.getCreateDate().toString() + user.getPassword);
Solange Ihr Salz Geheimnis ist, oder der Angreifer kennt nicht das genaue Erstellungsdatum des Datensatz des Benutzers, ein Wörterbuch-Angriff wird aufhören- selbst in dem Fall, dass sie in der Lage sind das Passwortfeld nach unten zu ziehen.
Nichts ist weniger sicher als Klartext-Passwörter zu speichern. Wenn Sie einen anständigen Hash-Algorithmus (mindestens SHA-256, aber auch SHA-1 ist besser als nichts), dann ja, Kollisionen sind möglich, aber es spielt keine Rolle, weil ein Hash gegeben, ist es unmöglich * zu berechnen, was Strings Hash zu. Wenn Sie den Benutzernamen mit dem Passwort-Hash, dann geht die Möglichkeit, das Fenster als auch aus.
* - technisch nicht unmöglich, aber "rechnerisch unmöglich"
Wenn der Benutzername ist „graeme“ und das Passwort „Stackoverflow“, dann eine Zeichenfolge „graeme-Stackoverflow-1234“ zu erstellen, in der 1234 eine Zufallszahl ist, dann Hash es und speichern „ hashoutput 1234" in der Datenbank. Wenn es ein Passwort zu validieren kommt, nehmen Sie den Benutzernamen, das mitgelieferte Passwort und die Nummer aus dem Ende des gespeicherten Wertes (der Hash eine feste Länge hat, so dass Sie dies immer tun können) und Hash sie zusammen, und vergleichen Sie es mit dem Hash Teil des gespeicherten Wertes.
mehr Passwörter könnten den Hash und ein Wörterbuch / Hash-Angriff Match schneller wäre.
Ja und nein. Verwenden Sie einen modernen Hashing-Algorithmus, wie eine SHA-Variante, und das Argument wird sehr, sehr Woche. Müssen Sie werden besorgt wirklich, wenn der Brute-Force-Angriff nur 352 Jahre statt 467 Jahre dauern wird? (Anekdotische Witz dort.) Der Wert gewonnen wird (nicht das Passwort im Klartext auf dem System gespeichert ist) übersteigt bei weiten Anliegen des Kollegen.
Hoffe ihr könnt mir verzeihen zum Aufstecken einer Lösung, die ich auf dieser schrieb, Client-Seite JavaScript mit dem Kennwort Hash, bevor sie übertragen hat: http://blog.asgeirnilsen.com/2005/11/password-authentication-without.html
