it-swarm.com.de

Ist "Daves Protokoll" nicht gut, wenn nur die Datenbank und nicht der Code durchgesickert ist?

Ich habe gelesen "Ist die Sicherheit des selbstgebrauten Passworts meines Entwicklers richtig oder falsch und warum?" , aber ich habe immer noch eine Frage im Kopf:

Selbst wenn jemand wie Dave einen schlechten, selbst gebrauten Sicherheitsalgorithmus verwendet, kann ein Angreifer das echte Kennwort nicht erhalten, wenn der Angreifer nur die Datenbank und nicht den Server gefährdet. Mark Burnetts Antwort auf Daves Frage scheint meine Vermutung zu beweisen.

Nehmen Sie wieder Daves Code als Beispiel. Dave verwendet unsichere/schnelle Hash-Funktionen, md5 und sha1, also können Sie sein Passwort einfach aus der Datenbank knacken (den Klartext abrufen). Sie können das echte Passwort jedoch immer noch nicht erhalten, wenn sein Server nicht kompromittiert ist.

37
Rick

Ja aber..

Um es schön und klar zu machen ... Wir sprechen von einem Kompromiss nur für Datenbanken, wenn ein Angreifer Zugriff auf die Datenbank hat, nicht jedoch auf den Quellcode der Anwendung. In diesem Fall erhält der Angreifer die Kennwort-Hashes, kann sie jedoch aufgrund des benutzerdefinierten Algorithmus von Dave nicht knacken und die ursprünglichen Kennwörter abrufen. Im Falle eines Verstoßes nur gegen die Datenbank schützt der Kennwortalgorithmus von Dave die Kennwörter besser als bei Verwendung von MD5 oder SHA1.

Dies ist jedoch nur ein möglicher Weg für Systemlecks. Es gibt eine wichtige Tatsache, die die "Mathematik" zerstört, die Daves Homebrew-Algorithmus vernünftig erscheinen lässt.

Die Hälfte aller Verstöße beginnt intern.

(Quellen 12 ) Was eine sehr ernüchternde Tatsache ist, wenn Sie es einmal einwirken lassen. Von der Hälfte der von Mitarbeitern verursachten Verstöße, Die Hälfte von ihnen ist zufällig und die Hälfte ist absichtlich . Daves Algorithmus kann hilfreich sein, wenn Sie sich nur um ein Nur-Datenbank-Leck sorgen. Wenn das alles ist, worüber Sie sich Sorgen machen, dann ist das Bedrohungsmodell, vor dem Sie in Ihrem Kopf schützen, falsch.

Um nur ein Beispiel zu nennen: Entwickler haben per Definition Zugriff auf den Anwendungsquellcode. Wenn ein Entwickler schreibgeschützten Zugriff auf die Produktionsdatenbank erhält, verfügt er jetzt über alles, was er zum einfachen Knacken der Kennwörter benötigt. Daves benutzerdefinierter Algorithmus ist jetzt nutzlos, da er auf alten und leicht zu knackenden Hashes basiert.

Wenn Dave jedoch einen modernen Passwort-Hashing-Algorithmus verwendet und sowohl Salz als auch Pfeffer verwendet hätte, hätte der Entwickler, der Zugriff auf einen Nur-Datenbank-Dump erhalten hat, absolut nichts Nützliches.

Das ist nur ein zufälliges Beispiel, aber der allgemeine Punkt ist einfach: Es gibt viele Datenlecks in der realen Welt, bei denen korrektes Hashing den tatsächlichen Schaden gestoppt hätte, wenn Daves Algorithmus dies nicht konnte.

Zusammenfassend

Es geht um Tiefenverteidigung. Es ist einfach, eine Sicherheitsmaßnahme zu erstellen, die vor einer bestimmten Art von Angriff schützen kann (Daves Algorithmus ist eine leichte Verbesserung gegenüber MD5 zum Schutz vor Nur-Datenbank-Lecks). Dies macht ein System jedoch nicht sicher. Viele reale Verstöße sind ziemlich kompliziert und nutzen Schwachstellen an mehreren Stellen in einem System aus, um endlich echten Schaden zu verursachen. Jede Sicherheitsmaßnahme, die mit der Annahme beginnt, dass dies der einzige Angriffsvektor ist, über den ich mir Sorgen machen muss (was Dave getan hat), wird die Dinge gefährlich falsch machen.

69
Conor Mancone

Dies beantwortet nicht speziell die Frage nach Daves Protokoll, aber ich wollte die allgemeinere Frage für die Daves auf der ganzen Welt ansprechen, die ihre eigenen Hashes schreiben. Es gibt ein paar Dinge, Daves, die Sie erkennen müssen:

  1. Sie sind kein Kryptograf . Das ist nichts gegen dich; Ich bin auch keiner. Aber selbst wenn Sie ein Kryptograf wären , müssten Sie der Beste auf der ganzen Welt sein, um sicherzugehen, dass Ihr Algorithmus keine Mängel aufweist, die die Sicherheit gefährden könnten, denn selbst die Experten messpalot (alle vier Wörter sind separate Links). Mögliche Fehler in Hashes sind unter anderem:
    • Versehentliche Reversibilität. Vielleicht haben Sie es nicht so gemeint, aber Sie haben zu viele Informationen in den "Hash" eingefügt, und jetzt kann es auch ohne rohe Gewalt trivial umgekehrt werden. Ein Beispiel für einen "komplexen" Algorithmus, der sich dennoch leicht umkehren lässt, finden Sie in linearen Kongruenzgeneratoren.
    • Nicht genügend Komplexität bei CPUs, GPUs, ASICs usw. Dies ist überraschend schwierig. Es gibt einen Grund, warum es nur drei Bibliotheken gibt, die Passwort-Hashing durchführen, und alle basieren auf denselben Ideen. Wenn Sie nicht genau mit der Funktionsweise von GPUs und ASICs vertraut sind, werden Sie höchstwahrscheinlich etwas erstellen, das auf GPUs viel schneller ausgeführt werden kann als auf CPUs, wodurch andere Schutzmaßnahmen sofort aufgehoben werden du hast.
    • Zu viel Komplexität, wo Sie es tatsächlich ausführen, kombiniert mit dem letzten Punkt. Es ist sehr einfach, auf Ihre Leistungstests zu verweisen und zu sagen: "Ich brauche 30 Sekunden, um 30 Hashes durchzuführen. Das ist großartig!" Abgesehen davon, dass Sie wiederum kein Kryptograf oder GPU-Entwickler sind, wissen Sie nicht, dass Ihre komplexen Ergänzungen und Multiplikationen tatsächlich recht einfach auf GPUs repliziert werden können, sodass sie während DoSing 30 Millionen Hashes in 30 Sekunden knacken können Ihren Dienst, indem Sie versuchen, sich mehr als einmal pro Sekunde anzumelden.
    • Unzureichende Gleichmäßigkeit. Die Ausgabe einer theoretisch perfekten Passwort-Hash-Funktion ist nicht von der eines echten Zufallszahlengenerators zu unterscheiden, wenn unterschiedliche Eingaben eingegeben werden. In der Praxis können wir nicht ganz dorthin gelangen, aber wir können unglaublich nahe kommen. Ihr Algorithmus könnte nicht. Und nein, "schauen" zufällig bedeutet nicht, dass es tatsächlich nah genug ist; Wenn Sie unerfahren genug sind, um Ihre eigene geheime Krypto für "bessere" Sicherheit zu schreiben, sind Sie unerfahren genug, um nicht zu wissen, wie man echte Zufälligkeit erkennt.
    • Selbst wenn Sie Ihren Algorithmus vollständig aus guten, soliden Krypto-Grundelementen erstellen, können Sie sie dennoch falsch zusammensetzen.
  2. Sie sind kein Cybersicherheitsprogrammierer . Es gibt wahrscheinlich ein besseres Wort dafür, aber der Punkt ist, dass Sie sich nicht darauf spezialisiert haben, Code zu schreiben, der Algorithmen korrekt implementiert, selbst solche wie Ihren eigenen. Für eine sehr kurze Liste möglicher Probleme, die allein in der Datenbank sichtbar sein könnten und die jeweils mit dem ersten Google-Ergebnis für "[item] attack" verknüpft sind:

Und alles, was nur ausschließlich über Offline-Angriffe auf Datenbanken nachdenkt, bei denen das Denken von einem College-Studenten durchgeführt wird, der sich nicht einmal mit Cybersicherheit befasst . Ich garantiere Ihnen, ich habe einige Dinge verpasst. Ich habe alle anderen Angriffsmethoden für MITMs, böswillige Clients usw. vollständig übersprungen. Außerdem habe ich die Erwähnung jedes Fehlers weggelassen, der auftreten könnte, selbst wenn Sie ein Standardprodukt verwenden. Betrachten Sie es als eine Übung für den Leser, um herauszufinden, wie Sie selbst gute Krypto falsch verwenden können. Schließlich habe ich die häufig auftretende Fehlerklasse, bei der der Entwickler Verschlüsselung verwendet, bei der Hashes verwendet werden sollen, gänzlich weggelassen gelegentlich sehen.

Also, Dave, wann immer Sie denken, Sie haben die beste Idee für einen geheimen, internen Hash, den Sie für Ihren Produktionscode verwenden können, und es ist nicht , einen Standard zu verwenden , handelsübliches, öffentliches, gründlich getestetes Produkt, denken Sie daran:

Das tust du nicht.

Verwenden Sie einfach bcrypt. (Oder Argon2 )

(Nebenbei bemerkt, wenn Sie nur einen Algorithmus zum Spaß und/oder zur Selbstbildung erstellen, können Sie dies alles ignorieren. Erstellen Sie Ihren eigenen Algorithmus , um Passwörter in der Produktion zu schützen ist gefährlich, weil Sie einen schwachen Algorithmus erstellen, der wenig bis gar keinen Schutz bietet. Das Erstellen eines eigenen Algorithmus , um festzustellen, ob Sie ihn brechen können , ist eine hervorragende Möglichkeit, die Zeit zu vertreiben , stimuliere deinen Geist und lerne vielleicht sogar etwas Krypto.)

32

Im Falle eines Verstoßes gegen die Datenbank und nicht gegen den Quellcode hätte Dave möglicherweise die Dinge besser gemacht als einfach SHA1 . Aber...

  1. Der Quellcode wird wahrscheinlich auch durchgesickert sein, wie Conor Mancone erklärt .

  2. Das Homebrew könnte den Hash vermasseln, was ihn noch weniger sicher macht als nur einen einfachen SHA1. Gott weiß, wie Daves seltsame Erfindung mit den Interna des Hashing-Algorithmus interagiert. Wenn nichts anderes, hat Dave für diejenigen, die nach ihm kommen, eine kleine Wartungshölle geschaffen, und große Unordnung ist niemals gut für die Sicherheit.

  3. Es gibt ein falsches Gefühl der Sicherheit. Wäre Dave nicht so stolz auf seine brillante Lösung gewesen, hätte er sich vielleicht die Zeit genommen, um zu lesen, wie man Passwort-Hashing richtig macht. Aus der Frage geht hervor, dass Dave der Meinung ist, dass das, was er getan hat, besser ist, als bcrypt zu sagen. Es ist nicht.

  4. Der kleine zusätzliche Schutz, den der Homebrew-Algorithmus bietet, hätte stattdessen mit einem Pfeffer erreicht werden können. Das ist in jeder Hinsicht besser als ein Homebrew-Algorithmus.

Ja, ein Homebrew könnte unter bestimmten Umständen besser sein als SHA1. Ob es im Durchschnitt besser ist, ist eine offene Frage, aber die Antwort spielt keine Rolle. Der Punkt ist, dass es im Vergleich zu einem echten Passwort-Hashing-Algorithmus schrecklich ist, und genau das hat Dave durch die Hausbrauerei von der Implementierung abgehalten.

Lange Rede kurzer Sinn, Dave hat das versaut.

10
Anders

TLDR: Unsichere Krypto ist nicht einmal sicher, wenn Sie den verschlüsselten Wert nicht sehen können.

Die anderen Beiträge erklären ziemlich gut viele Gründe, warum Sie keine eigene Krypto schreiben sollten, in einer Umgebung, in der der Angreifer den verschlüsselten Wert sehen kann, aber sie vermissen etwas wirklich Wichtiges: Sie sollten auch keine eigene Krypto schreiben, wenn der Angreifer die verschlüsselte Nachricht nicht sehen kann.

Es gibt dieses Ding, das "Seitenkanal" genannt wird. Seitenkanäle sind (normalerweise1) unbeabsichtigte Dinge, die Informationen darüber verlieren, was Ihre Anwendung tut. Zum Beispiel dauert es möglicherweise mehr CPU-Zyklen - und damit mehr Zeit -, um ein teilweise korrektes Kennwort mit dem "verschlüsselten" zu vergleichen.2 Wert. Dies würde es einem Angreifer ermöglichen, einen Brute-Force-Angriff zu beschleunigen, um langsam das richtige Passwort zu lernen.

Nehmen wir ein naives Beispiel. Stellen wir uns vor, es dauert 1 Sekunde, um ein einzelnes Zeichen des übermittelten Kennworts anhand des in der Datenbank gespeicherten Werts zu testen. Stellen Sie sich vor, das richtige Passwort ist 8 Zeichen lang und ein ungültiges Passwort wird beim ersten falschen Ergebnis abgelehnt. Der Algorithmus könnte ungefähr so ​​aussehen:

boolean encrypt_password(string password) {
    if(not isascii(password) ) { return false; } // ERROR! 
    string result;
    foreach(char c : password) {
        result += daves_magic_that_takes_1s(c)
    }
    return true;
} 

boolean is_correct_password(input, pw_from_db) {
    if(input.length != pw_from_db.length) { return false }
    foreach(char c_in, c_db : input, password) {
         c_in = daves_magic_that_takes_1s(c_in)
        if(c_in != c_db){ return false}
    }
    return true; // valid password!
}

Stellen wir uns nun vor, das gültige Passwort ist "Passwort" und der Angreifer versucht die Eingabe "a". Dies schlägt fehl, da die Passwörter die falsche Länge haben. Der Angreifer kann zufällig verschiedene Passwörter ausprobieren. Die Verarbeitung jedes falschen Passworts, das länger oder kürzer als "Passwort" ist, dauert weniger als eine Sekunde. Nehmen wir an, sie versuchen es bald mit "12345678". "12345678" hat die gleiche Länge wie "Passwort", daher dauert die Verarbeitung eine Sekunde. Das Timing ist anders und der Angreifer bemerkt es. Sie versuchen mehrmals, dies zu überprüfen, und es ist konsistent.

Der Angreifer versucht nun mehrere 8-stellige Passwörter. Sie alle brauchen 1 Sekunde. Der Angreifer hat einen Seitenkanal entdeckt, der ihm mitteilt, dass das gültige Passwort wahrscheinlich 8 Zeichen lang ist. Jetzt müssen sie feststellen, welches 8-stellige Passwort das richtige ist.

Der Angreifer versucht zufällig, 8-Zeichen-Passwörter zu verwenden. Schließlich versuchen sie "p2345678" und stellen fest, dass dies 2 Sekunden dauert. Sie testen eine Menge und stellen fest, dass alle Versuche, die mit "p" beginnen, 2 Sekunden dauern. Der Angreifer vermutet, dass der Algorithmus über einen Seitenkanal verfügt, der angibt, wie viele Zeichen korrekt sind.

Anstatt jetzt alle 96 ^ 8-Passwörter versuchen zu müssen, um das gültige zu erzwingen, muss der Angreifer nur noch 96 * 8-Passwörter versuchen3. Abhängig davon, wie viele Passwörter parallel getestet werden können, können sie das Passwort wahrscheinlich in sehr angemessener Zeit erfolgreich erzwingen. Das ist großartig für den Angreifer! Und es ist schrecklich für die Sicherheit Ihres Systems.4

Wie schützen wir uns vor zeitlichen Seitenkanälen? Wir garantieren, dass alle Vorgänge, bei denen das Timing vertrauliche Informationen verlieren würde, immer dieselbe Zeit in Anspruch nehmen MÜSSEN.

Dies mag wie ein sehr einfaches Beispiel aussehen. Es ist in freier Wildbahn passiert. Wenn Sie NVD nach "Timing Side Channel" durchsuchen, erhalten Sie viele reale Sicherheitslücken, die alle die gleichen Ergebnisse liefern, sodass ein Angreifer geheime Informationen erfahren kann, für die er nicht autorisiert ist. Wenn per Definition alle Vorgänge unabhängig von der Eingabe dieselbe Zeit in Anspruch nehmen, sagt die Zeit, die etwas benötigt, nichts über die Eingabe aus.

In der realen Welt sind Seitenkanäle unglaublich einfach einzuführen. Dave hat wahrscheinlich noch nicht einmal von ihnen gehört und ist wahrscheinlich ein guter Ingenieur, der sich mit der Leistung seines Systems befasst - was eigentlich ein Anti-Muster zum Schutz vor Seitenkanälen ist. Daves Algorithmus hat möglicherweise sowohl offensichtliche als auch subtile Seitenkanäle, die er nie entdecken wird, die Forscher und Angreifer zu suchen wissen und die ziemlich einfach automatisierte Tests schreiben können, um sie zu erkennen.5

Nur weil Sie die Krypto nicht sehen können, heißt das nicht, dass Sie die Nebenwirkungen einer schlechten Krypto nicht sehen können, und verwenden Sie diese Nebenwirkungen, um das geschützte Geheimnis zu erfahren.


Endnoten

1: Nun, wenn Sie ein Geheimdienstagent oder ein guter Zeitungsjournalist sind, haben Sie wahrscheinlich absichtlich Seitenkanäle eingerichtet, damit Sie mit Ihren Agenten/Quellen kommunizieren können, ohne dass "der Feind" es weiß. In ähnlicher Weise können Sie, wenn Sie hinterhältig sind, ein Kryptoprotokoll mit einem Seitenkanal erstellen, um geheime Informationen zu verlieren.

2: Da wir immer davon ausgehen können und sollten, dass benutzerdefinierte Krypto unsicher ist (aus den Gründen, die andere in diesem Thread und mehr erwähnt haben), sollten wir die Verwendung von benutzerdefinierten Krypto-Algorithmen wahrscheinlich nicht als "Verschlüsselung" oder "Entschlüsselung" bezeichnen ... vielleicht "unsichere Verschlüsselung" oder "defekte Entschlüsselung" ...

3: Ich ignoriere Brute-Force-Angriffe, die im Durchschnitt erfolgreich sind, wenn der Angreifer 50% + 1 Passwörter ausprobiert hat, um die Beschreibung zu vereinfachen. Ich konzentriere mich auf Seitenkanäle, nicht auf Brute-Force-Angriffe. Ich beschönige auch die Mathematik eines Brute-Force-Angriffs, da dies auch tangential zum Hauptthema ist. Einige Google-Fu im Auftrag des Lesers sollten viele Ressourcen finden, die tief in die Details gehen.

4: "1 Sekunde ist viel zu langsam", richtig? Kein reales System konnte über das Internet auf reale Timing-Seitenkanäle überprüft werden, oder? Falsch. Ich habe die Referenzen nicht zur Hand, aber es gab einige Jahre später Untersuchungen, die zeigten, dass Sie das Timing in der Größenordnung von Millisekunden über HTTP-Transaktionen statistisch testen können.

5 Tatsächlich würde ich wetten, dass es entweder Frameworks oder vorhandene Tools (höchstwahrscheinlich beides) gibt, mit denen Sie Ihre Anwendung auf offensichtliche Seitenkanäle testen können, wenn Sie Ihr Google-Fu ausüben.

7
atk

Bekannte Klartext-/Ausgewählte Klartext-Angriffe

Angenommen, Sie kennen das Passwort eines bestimmten Benutzers oder können sich noch besser so oft anmelden und erstellen, wie Sie möchten.

Und Sie haben Lesezugriff auf die Datenbank.

Nehmen wir weiter an, Sie vermuten (oder wissen), dass es sich um einen ziemlich einfachen Homebrew-Algorithmus handelt.

An diesem Punkt können Sie den Algorithmus brutal erzwingen und versuchen, den Hash in die Datenbank zu bekommen. Zum Beispiel könnten Sie den Algorithmus "erraten"

$hash = md5($pass . $salt . 'some random string');

Sie würden die zufällige Zeichenfolge brutal erzwingen. Dies wird schwieriger, wenn die Zeichenfolge länger wird. Möglicherweise können Sie jedoch eine md5-Schwäche ausnutzen, indem Sie die Kennwörter sorgfältig auswählen.

Sie können alternativ den Algorithmus "erraten"

$hash = sha1(md5($pass . $salt . 'abc') . 'def');

und dann versuchen Sie es erneut mit brutalem Forcen.

Etwas so Kompliziertes wie Daves Algorithmus wäre ohne einige Hinweise extrem schwierig. Wenn Sie wüssten, dass eine Neuordnung der Charaktere erforderlich ist, würde dies helfen.

4
Artelius

Ich habe viel mehr als diese Frage gelernt, indem ich die Antwort von @Conor Mancone und besprochen mit @Conor Mancone und @Anders gelesen habe, also entscheide ich mich, sie aufzuschreiben. Korrigieren Sie mich, wenn ich wieder falsch liege.


md5 Und sha1 Sind kaputt, aber nicht so, wie ich denke

Ich habe fälschlicherweise gedacht, dass die Hash-Ausgabe von md5 Und sha1 Immer leicht geknackt werden kann (den ursprünglichen Eingabetext erhalten), egal wie groß die Eingabe ist.

Nein, ist es nicht .

Wenn ich einen ausreichend langen Pfeffer auf dem Server verwende, selbst wenn ich md5 Oder sha1 Zum Hashing eines Passworts verwende, ist es immer noch sicher Server ist nicht gefährdet .

Zum Beispiel: Speichern Sie md5($ 128bits_long_pepper . $password) in der Datenbank.
Auch ohne Salz kann man es nicht knacken. Angenommen, Ihre md5 - Hash-Geschwindigkeit ist 100 billion hash/s. Nehmen wir es der Einfachheit halber als 2^40 hash/s, Da 2^40 > 100 billion. Um es brutal zu erzwingen, braucht man noch 2^128 / 2^40 = 2^88 seconds = 9.80719764 × 1018 years. Und natürlich denke ich, dass niemand einen solchen Regenbogentisch vorberechnen würde.

Aber ich sage nicht, dass ich md5 Wählen würde, um mein Passwort zu hashen. Ich würde nicht. Denn sobald Ihr Server ebenfalls kompromittiert wird, unterscheiden sich diese Hash-Passwörter nicht mehr von Klartext.

Ich bin ein Neuling und habe viele hochgewählte Beiträge gelesen, in denen es darum geht, wie schlecht md5 Und sha1 Sind, aber ich sehe keine Antworten, die darüber sprechen ⬆️. Ich bemerke nur einige in den Kommentaren.


Salz, Pfeffer, Hash-Funktion

Schließlich denke ich, dass ich diese 3 Konzepte und ihre Anwendungsfälle/Zusammenhänge vollständig verstehe.
Zunächst fasse ich drei Arten von Angriffen selbst zusammen: 1. Brute-Force-Angriff (der Weg "alles versuchen") 2. Regenbogentischangriff (der direkte umgekehrte Blick nach oben) 3. Wörterbuchangriff ($pepper. $common_password. $salt Brute Force, teilweise Brute Force im Vergleich zu 1.)

Also denke ich:

  1. Salz soll den Angriff auf den Regenbogentisch verteidigen.
  2. Eine gute Hash-Funktion (eine langsame) zielt darauf ab, Brute-Force-Angriffe zu verteidigen.
  3. Pepper zielt hauptsächlich darauf ab, Wörterbuchangriffe zu verteidigen, da der Server nicht gefährdet ist.

Erklären Sie mit einem Beispiel:

( Salz ) Man sollte erkennen, dass ein Salz keine sehr große Sache ist, wie viele Leute beschreiben. Es verteidigt nur eine Sache: Ein Angreifer kann nicht einfach in seiner Rainbow-Tabelle nachschlagen, um Ihr nicht verwaschenes Passwort zu erhalten. Wenn man nur salt + fast hash function Verwendet (kein Pfeffer auf dem Server), kann ein Angreifer für jedes gehashte Passwort Brute Force anwenden. Eine weitere Voraussetzung ist natürlich, dass Ihr Benutzer kein 128bit Langes Passwort für die Registrierung speichern muss :).

Damit :

  • salt + fast hash function Verteidigt keinen Brute-Force-Angriff. Ob es Rainbow Table Attack oder Dictionary Attack verteidigen kann, ist jetzt nicht wichtig.
  • salt + slow hash function Verteidigt Brute-Force-Angriffe. Es verteidigt auch den Regenbogentischangriff. Es verteidigt keine Wörterbuchangriffe.

( Pfeffer ) Aber für die salt + fast hash function - Kombination, wenn Sie einen Pfeffer lange genug auf dem Server verwenden, vorausgesetzt, Ihr Server ist nicht gefährdet Wenn nur die Datenbank dies tut, ist das Passwort weiterhin sicher.

Damit :

  • salt + fast hash function + long pepper(e.g.128bits) + server not compromised kann jetzt Brute-Force-Angriffe verteidigen. Es verteidigt auch Rainbow Table Attack und Dictionary Attack.

( Hash-Funktion ) Aber sobald der Server kompromittiert wird, ist die obige Kombination wie eine Scheiße. Der Angreifer würde den Pfeffer kennen. Die Schwierigkeit, salt + fast hash function + long pepper(e.g.128bits) + server gets compromised zu knacken, ist dieselbe, als wenn jemand nur einen fast hash function Verwendet.

Damit :

  • salt + fast hash function + long pepper(e.g.128bits) + server gets compromised verteidigt keinen Brute-Force-Angriff. Ob es Rainbow Table Attack oder Dictionary Attack verteidigen kann, ist jetzt nicht wichtig.
  • Wenn Sie jedoch eine sichere/langsame Hash-Funktion verwenden, ändern sich die Dinge.
    salt + slow hash function + pepper (not necessary to be very long e.g. 6 chars maybe good enough?) + server gets compromised Brute-Force-Angriff verteidigen. Es verteidigt auch den Regenbogentischangriff. Es verteidigt keine Wörterbuchangriffe.

Was ist mit salt + slow hash function, Ist es nicht genug? Diese Kombination verteidigt Brute-Force-Angriffe und Rainbow-Tischangriffe. Aber es verteidigt nicht Wörterbuchangriff. Das Hinzufügen eines Pfeffers auf dem Server ist einfach, warum nicht?


Sag etwas für Dave

Wie Sie von oben sehen können, ist ein Pfeffer nur etwas, mit dem Sie auf der Serverseite eine Konvertierung durchführen.
Es ist die "Konvertierung auf dem Server", die wirklich wichtig ist, solange der Server nicht kompromittiert wird.
Zum Beispiel nehmen Sie eine zufällige Konstante und verketten sie mit dem Passwort hash($pepper . $password, $salt), es ist eine Art der Konvertierung. Wenn Sie also wie Dave einige beschissene Algorithmen auf dem Server erfinden, führen Sie auch eine Konvertierung durch. In beiden Situationen muss der Angreifer den Server kompromittieren. Bei ersteren kann der Angreifer nur Ihren konstanten Wert erfassen. Für letzteres muss der Angreifer herausfinden, wie Ihr beschissenes Ding funktioniert, und einen umgekehrten Vorgang ausführen.

Mein Punkt ist also, ich denke, Daves Idee ist völlig in Ordnung (einige Konvertierungen auf dem Server durchführen), aber es ist einfach nicht notwendig, eine solche Dunkelheit/Komplexität hinzuzufügen. Denn Wartung könnte höllisch sein, wenn sie auf diese Weise immer komplexer wird. Eine "Konvertierung" wie das Verketten eines Pfeffers auf dem Server ist weit genug. Wieder denke ich, dass es immerhin ein Kompromissproblem ist. Und Daves Idee ist von Anfang an richtig (er möchte zusätzliche Sicherheit auf der Serverseite einsetzen).

4
Rick

Die Verwendung eines "versteckten" benutzerdefinierten Algorithmus ist zwar sinnvoll, es gibt jedoch bereits eine einfache und etablierte Methode, um benutzerdefinierte sichere Hash-Algorithmen zu erstellen: Pepper *

Da es die sehr billige, sehr schnelle und sehr sichere Möglichkeit gibt, einen Pepper zu verwenden, sind Leute, die stattdessen einen Krypto-Algorithmus von Grund auf neu schreiben, um "sicherer" zu sein, immer Anfänger. "Daves Protokoll" ist also nicht nur eine Verschwendung von Zeit und Geld, sondern auch ein (angeblich) sicheres Protokoll, das von jemandem geschrieben wurde, der nicht viel über sichere Protokolle weiß. Und das wird im Allgemeinen als unkluge Wahl angesehen, unabhängig von der tatsächlichen Sicherheit (oder dem Fehlen derselben) in Daves Protokoll.

* Kurz gesagt, ein Pfeffer ist ein geheimes Salz, das für alle Benutzer gleich ist.

2
Peter

Faustregel: Keine Sicherheit beim Selbstbrauen.

Weil es oft schief geht. Und die Person, die es geschrieben hat, kann es nicht testen. Wenn jemand beim Schreiben eine falsche Annahme hat, hat er es beim Testen immer noch. Ein unabhängiger Test ist überraschend teuer/zeitaufwändig - viel mehr als das Schreiben.

Sie müssen auch alle zugehörigen Änderungen einbeziehen. Zu wissen, dass es kein Problem geben kann, weil ..., ist einfach kein gültiger Ansatz. Aus den gleichen Gründen wie oben.

Software-Sicherheit ist ein schwieriges Thema. Es ist so schwierig, dass es schwer zu verstehen ist, wie schwierig es ist.

0
Volker Siegel