Frage:
Ist "Daves Protokoll" nicht gut, wenn nur die Datenbank und nicht der Code durchgesickert ist?
Rick
2019-07-01 13:49:09 UTC
view on stackexchange narkive permalink

Ich habe "Ist die Sicherheit meines Entwicklers für das selbstgebraute Passwort richtig oder falsch und warum?" gelesen, aber ich habe immer noch eine Frage im Kopf:

Auch wenn Jemand verwendet einen schlechten, selbst gebrauten Sicherheitsalgorithmus wie Dave. Ein Angreifer kann das echte Passwort nicht erhalten, wenn der Angreifer nur die Datenbank und nicht den Server kompromittiert. Mark Burnetts Antwort auf Daves Frage scheint meine Vermutung zu beweisen.

Nehmen Sie noch einmal Daves Code als Beispiel. Dave verwendet unsichere / schnelle Hash-Funktionen, md5 und sha1. Ja, Sie können 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.

@Anders Eigentlich bin ich ziemlich verwirrt, wenn ich einige Fragen zur Sicherheit von Passwörtern mit hoher Abstimmung lese.Denn wenn ich von "kompromittiert" oder "geknackt" spreche, weiß ich nicht, ob sowohl der Server als auch die Datenbank kompromittiert sind oder nur die Datenbank.
"Ja, Sie können sein Passwort leicht aus der Datenbank knacken (den Klartext abrufen). Aber Sie können das echte Passwort immer noch nicht bekommen, wenn sein Server nicht kompromittiert ist." Ich verstehe diese Zeile nicht. Wenn Sie sein Passwort knacken können, wie geht das?Sie erhalten nicht das richtige Passwort?
@VipulNair Da Dave wie Kennwort den Kennwort-Hash nicht direkt speichert, wissen Sie nicht, welche Konvertierung er auf dem Server verwendet.
Acht antworten:
#1
+69
Conor Mancone
2019-07-01 14:51:46 UTC
view on stackexchange narkive permalink

Ja, aber ...

Um es schön und klar zu machen ... Wir sprechen von einem reinen Datenbankkompromiss, wenn ein Angreifer Zugriff auf die Datenbank hat, aber nicht 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.

Allerdings Dies ist nur ein möglicher Weg 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 1 2 3) Dies ist eine sehr ernüchternde Tatsache, wenn Sie sie erst einmal einwirken lassen. Von der Hälfte der von Mitarbeitern verursachten Verstöße sind die Hälfte versehentlich und die andere Hälfte sind 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, 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 Quellcode der Anwendung. 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, hat der Entwickler gewonnen Der Zugriff auf einen Nur-Datenbank-Dump hätte absolut nichts Nützliches.

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

Zusammenfassend

Es geht nur 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.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/95782/discussion-on-answer-by-conor-mancone-isnt-daves-protocol-good-if-only-the-d).
#2
+32
Fund Monica's Lawsuit
2019-07-01 22:48:20 UTC
view on stackexchange narkive permalink

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 einige Dinge, Daves, die Sie beachten müssen:

  1. Sie sind kein Kryptograf . Das ist nicht gering 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, da selbst die Experten durcheinander up a lot (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 den 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, und alle anderen Schutzmaßnahmen, die Sie haben, sofort aufheben.
    • 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, erkennen 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.
    • Auch wenn Sie Ihren Algorithmus vollständig aus dem Guten heraus bauen , solide Krypto-Grundelemente, können Sie immer noch 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 nur in der Datenbank sichtbar sein könnten, von denen jedes mit dem ersten Google-Ergebnis für "[item] attack" verknüpft ist:
  3. ol>

    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. Ich habe auch die Erwähnung aller Fehler weggelassen, die auftreten könnten, 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, was ich gelegentlich sehe.

    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, aus -das Regal, öffentliches, gründlich getestetes Produkt, denken Sie daran:

    Sie tun es 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 Ihr eigener Algorithmus zum Schutz von Passwörtern in der Produktion ist gefährlich, da Sie einen schwachen Algorithmus erstellen, der wenig bis gar keinen Schutz bietet. Erstellen Sie Ihren eigenen Algorithmus , um festzustellen, ob Sie ihn beschädigen können ist eine hervorragende Möglichkeit, sich die Zeit zu vertreiben, Ihren Geist zu stimulieren und vielleicht sogar etwas Krypto zu lernen.)

Ich habe einige Schrecken, die speziell dafür entwickelt wurden, dass sich ein ASIC-Board-Designer Sorgen macht, aber ich habe Angst, sie zu verwenden, da die Zuweisung von 5600 KB RAM pro Kennwortprüfung ein einfaches DOS für meinen Server eröffnet.
"Verwenden Sie einfach Bcrypt" - nein, verwenden Sie Argon2.Es ist seit geraumer Zeit der Goldstandard.
@Polynomial Im ursprünglichen Beitrag hat Dave versucht, Bcrypt zu ersetzen, weshalb in der ursprünglichen Version dieses Beitrags nur auf Bcrypt verwiesen wurde.Guter Punkt;Ich habe Argon2 hinzugefügt.
Wenn Sie die Zeile "Und alles, was nur an Offline-Angriffe auf Datenbanken denkt ..." mit 4 Leerzeichen einrücken, wird sie als Teil des nummerierten Abschnitts darüber gerendert und mit diesem Inhalt in Einklang gebracht.
@jpmc26 Es würde, aber ich habe versucht, es auf beide Abschnitte anzuwenden.Alle Probleme, die ich im ersten Bit erwähnt habe, können die Datenbank alleine, knackbar, direkt oder auf andere Weise verlassen.Wenn ich es auf etwas erweitern würde, das zu einem Angriff führen könnte, wäre diese Liste viel länger ...
@Polynomial Der Wikipedia-Artikel über Argon2 ist ziemlich kurz und abgesehen von dem Verweis auf den "Password Hashing Competition", der anscheinend von keiner großen seriösen Organisation durchgeführt wurde.Nicht zu sagen, dass es schlecht macht, aber gibt es eine detaillierte Analyse von bekannten Experten, die ich mir ansehen könnte?(Sogar eine Frage auf dieser Site [erwähnt sie nicht prominent] (https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords). Es ist schwer, mit dem auf dem Laufenden zu bleibenständig wechselnde Algorithmen und entscheiden, was gut genug getestet ist, um verwendet zu werden.
@Voo Diese Frage stammt aus dem Jahr 2010. Mit Ausnahme der automatischen Bearbeitung durch die Community zur Korrektur von Links stammt die letzte Bearbeitung aus dem Jahr 2015, und das scheint keine Inhaltsbearbeitung gewesen zu sein, sondern nur eine Grammatikbearbeitung.Wenn Sie sich den Bearbeitungsverlauf ansehen, werden Sie feststellen, dass diese Informationen tatsächlich aus dem Jahr 2013 stammen. Eine Menge kann sich in sechs Jahren ändern, insbesondere in digitalen Bereichen, insbesondere in der Cybersicherheit.Ich habe absichtlich eine neuere Frage ausgewählt, da etwas aus dem Jahr 2018 weniger veraltet ist als etwas aus dem Jahr 2013, und diese Frage nennt Argon2 ausdrücklich die bevorzugte Wahl.
@Nic Irgendwie haben Sie Ihren Link in der Antwort verpasst, ich beschuldige mein Telefon.
@Voo Argon2 wurde sowohl von Wissenschaftlern als auch von der Sicherheitsgemeinschaft stark überprüft.Während in einem der Modi einige Angriffe zur Kostenreduzierung entdeckt wurden, beeinträchtigen sie in keiner Weise die allgemeine Überlegenheit von Argon2 gegenüber bcrypt.Ich würde es dringend für neue Designs (und Design-Upgrades) empfehlen, es sei denn, Sie befinden sich in einer Situation, in der eine Verschlüsselungsimplementierung nativ auf der Plattform / dem Framework Ihrer Wahl verfügbar ist und Argon2 nicht.Ich würde bcrypt im Allgemeinen nicht für neue Designs empfehlen, außer für IoT-Geräte mit sehr wenig Speicher.
@Voo Sagen Sie einfach, es wurde kompromittiert, weil es Daves Algorithmus verwendet, um Ihr Passwort zu speichern :)
@Polynomial Ich bin mir ziemlich sicher, dass Sie, wenn Sie versuchen, ein IoT-Gerät mit sehr wenig Speicher zu sichern, überhaupt keine Passwort-Hash-Datenbank verwenden.Sie bauen die Kennwortfunktionalität in die Steuerungs-App ein, indem Sie eine Schlüsselableitungsfunktion und dann eine standardmäßige schlüsselbasierte Krypto verwenden.Zumindest würde ich das so machen ...
@NicHartley Nicht alle Geräte interagieren mit externen Systemen.Es gibt immer noch häufige Fälle in der Firmware, in denen Sie eine Schlüsselableitung von einem Kennwort durchführen oder ein Kennwort auf sichere Weise lokal speichern müssen.
@Polynomial ... Ich bin nicht sicher, ob ich verstehe, was du meinst.Können Sie Beispiele für IoT-Geräte nennen, die nur indirekt mit anderen Geräten mit extrem geringem Stromverbrauch interagieren?Ich frage, weil selbst in der industriellen Automatisierung normalerweise eine Art zentraler "Standard" -Computer vorhanden ist, der das Strecken von Schlüsseln auf eine wesentlich brutalere Art und Weise durchführen kann als jedes eingebettete Gerät.
@NicHartley Sie sind nicht unbedingt IoT, sie können nur normale Hardware sein.Standalone-Geräte wie Hardware-Passwort-Manager kommen in den Sinn.Ich habe auch IoT-Geräte gesehen, auf denen ein RAS-Kennwort lokal als Hash gespeichert ist und die eingehenden Anforderungen dieses Kennwort nehmen und auf Gültigkeit prüfen - PBKDF2 ist hier in Ordnung, Argon2 oder Verschlüsselung sind nicht möglich.
@Polynomial Ohh, ich verstehe, was du meinst - richtig, das ist ein guter Punkt.In diesem Fall wird hoffentlich jeder, der es herstellt, erkennen, dass ein PC unabhängig von der verwendeten Funktion sofort ein Vielfaches schneller knacken kann, nur weil er kein Gerät mit geringem Stromverbrauch ist ... Was "richtige" IoT-Geräte betrifftIch nehme sicher, das ist erledigt. Mein Punkt ist nur, dass es nicht sein sollte.Ich gebe Ihnen mehr Anerkennung als den meisten IoT-Entwicklern.Selbst bei eingebetteten Nicht-IoT-Geräten sollte versucht werden, die Verwendung von Kennwörtern zu vermeiden.
#3
+10
Anders
2019-07-01 15:16:29 UTC
view on stackexchange narkive permalink

Im Falle eines Verstoßes gegen die Datenbank und nicht gegen den Quellcode hat Dave möglicherweise die Dinge im Vergleich zu einfachem SHA1 verbessert. 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. Dies ist nicht der Fall.

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

  5. ol>

    Ja, ein Homebrew ist unter bestimmten Umständen möglicherweise besser 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 das Hausbrauen Dave davon abgehalten, es zu implementieren.

    Lange Rede, kurzer Sinn, Dave hat das versaut.

Ich würde argumentieren, wenn das Hinzufügen eines Pfeffers bedeutet, dass der Pfeffer direkt an das Passwort angehängt und dann gehasht wird.Es ist nutzlos und Daves schlechtes Algo gewinnt in dieser Situation.
@Rick Warum sollte es nutzlos sein?
Ich verstehe auch nicht, warum einige hoch bewertete Antworten besagen, dass das Anhängen eines Pfeffers direkt an das Passwort und den Hash sicherer sein kann.Sie können die Salzlänge einfach erhöhen, wenn Sie lediglich den Pfeffer und das Kennwort verketten, unabhängig davon, ob Sie es anhängen oder voranstellen.Ich denke, ein Pfeffer sollte als geheimer Schlüssel verwendet werden, zum Beispiel zusammen mit "HMAC".Aber wie ich unter der Antwort von @Conor Mancone kommentiere, würde es ausreichen, nur ein bisschen zu ändern.
@Rick Ja, ein Pfeffer sollte geheim sein und nicht in der Datenbank gespeichert werden.Es schützt also vor genau der Situation, die Sie beschreiben - Datenbank durchgesickert, Code nicht durchgesickert.Dafür ist ein Pfeffer da, also kann man ihn nicht mit einer Verlängerung des Salzes vergleichen.
@Rick Ich nehme keine Position zum Einmischen des Pfeffers ein - das liegt außerhalb des Rahmens dieser Frage.
@Rick Frage bleibt: Warum sollte ein Pfeffer nutzlos sein?
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (https://chat.stackexchange.com/rooms/95578/discussion-between-rick-and-anders).
#4
+7
atk
2019-07-02 12:14:09 UTC
view on stackexchange narkive permalink

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

In den anderen Beiträgen werden viele Gründe erläutert, warum Sie dies tun Sie sollten keine eigene Krypto schreiben, in einer Umgebung, in der der Angreifer den verschlüsselten Wert sehen kann, aber etwas wirklich Wichtiges übersehen: Sie sollten auch keine eigene Krypto schreiben, wenn der Angreifer die verschlüsselte Nachricht nicht sehen kann.

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

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 (Zeichenfolgenkennwort) {if (nicht isascii (Kennwort)) {return false; } // ERROR! String-Ergebnis; foreach (char c: password) {result + = daves_magic_that_takes_1s (c)} return true;} boolesches is_correct_password (input, pw_from_db) {if (input.length! = pw_from_db.length) {return false} foreach (char c_in, c_db: Eingabe, Passwort) {c_in = daves_magic_that_takes_1s (c_in) if (c_in! = c_db) {return false}} return true; // gültiges Passwort!}  

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 herausfinden, welches 8-stellige Passwort das richtige ist.

Der Angreifer versucht zufällig, 8-stellige Passwörter auszuprobieren. 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 nun alle 96 ^ 8 Passwörter zu versuchen, um das gültige zu erzwingen, hat der Angreifer nur noch um 96 * 8 Passwörter 3 sup> zu versuchen. 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 sup>

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, nach denen Forscher und Angreifer suchen müssen, und kann ziemlich einfach automatisierte Tests schreiben, um sie zu erkennen. 5 sup>

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.


Endnotizen 1

1: Nun, wenn Sie ein Geheimdienstagent oder ein guter Zeitungsjournalist sind, haben Sie sich wahrscheinlich absichtlich eingerichtet Seitenkanäle, 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. Sup>

2: Da wir immer können und sollten Angenommen, benutzerdefinierte Krypto ist unsicher (aus den Gründen, die andere in diesem Thread und mehr erwähnt haben), sollten wir die Verwendung benutzerdefinierter Krypto-Algorithmen wahrscheinlich nicht als "Verschlüsselung" oder "Entschlüsselung" bezeichnen ... möglicherweise als "unsichere Verschlüsselung" oder "fehlerhafte Entschlüsselung" "... sup>

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-Benutzer sollten im Auftrag des Lesers viele Ressourcen finden, die tief in die Details eingehen. sup>

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. Sup>

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. sup>

#5
+4
Artelius
2019-07-02 05:31:24 UTC
view on stackexchange narkive permalink

Angriffe auf bekannten Klartext / ausgewählten Klartext

Nehmen wir an, 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 "erraten", dass der Algorithmus

  $ hash = md5 ($ pass. $ Salt. 'Irgendeine zufällige Zeichenfolge') ist;  

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.

Alternativ können Sie den Algorithmus

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

und versuchen Sie es erneut mit Brute Forcing.

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

* Dies. * Der Angreifer kann den Algorithmus ohne so viel Aufwand bestimmen!Das ist es, was Kerckhoffs Prinzip erfordert.Ich bin nur anderer Meinung, dass es schwer herauszufinden ist.Ich würde annehmen, dass es für einen Angreifer einfach ist, dies herauszufinden, obwohl es möglicherweise etwas mehr Aufwand erfordert als ein einfaches MD5.
@jpmc26 Mit der Datenbank ist es einfach, einen potenziellen Algorithmus zu überprüfen, aber immer noch schwer zu erraten.Sie können die niedrig hängenden Früchte abholen (wie der Programmierer, der ein Salz in der DB speichert, aber vergisst, es zu verwenden!), Aber darüber hinaus gibt es einfach zu viele Permutationen, um sie zu erkunden.In einer Codezeile können Sie alle ASCII-Werte mit 3 multiplizieren, verketten, als Hex interpretieren und dann 730 subtrahieren, bevor Sie Hashing durchführen. Wie schreiben Sie überhaupt einen Brute-Forcer, um diesen Mist zu untersuchen?
Die einzige Ausnahme ist, dass, wenn Sie feststellen, dass die Verteilung der Endwerte ungleichmäßig ist und / oder in irgendeiner Weise von der Eingabe abhängt, Informationen über den Algorithmus verloren gehen können.Wenn die letzte Stufe des Algorithmus jedoch eine Standard-Hash-Funktion (sogar md5) ist, wird dies nicht passieren.
"Wie schreibt man überhaupt einen Brute-Forcer, um diesen Mist zu erforschen?"Eines der Dinge, die ich gelernt habe, ist, dass Angreifer weitaus klüger sind, als ich mir vorstellen kann.=) Wir können nicht beweisen, dass jemand keinen völlig unerwarteten Weg gefunden hat, und die Tatsache, dass so viele kryptografische Schemata einem sehr cleveren Angriff zum Opfer gefallen sind, den niemand für möglich gehalten hat, ist der Grund, warum wir nicht darauf angewiesen sindGeheimhaltung.Ich bin einfach nicht bereit zu glauben, dass niemand es getan hat.
@jpmc26 Natürlich.Alles sollte als anfällig für kreative Angriffe angesehen werden;Wir machen jedoch Aussagen über Dinge, damit andere Sicherheitsleute Schwachstellen erkennen können.Es würde mich sehr interessieren, von bekannten Schwächen in solchen Dingen zu hören.Denken Sie daran, dass die Verwendung von Paprika als zusätzliche Maßnahme üblich ist und sie auf Geheimhaltung angewiesen sind.Was wir hier haben, ist (wenn es richtig gemacht wird) eine andere Form von Pfeffer, wie ich es sehe.
#6
+4
Rick
2019-07-02 20:23:54 UTC
view on stackexchange narkive permalink

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


md5 und sha1 sind defekt, aber nicht so, wie ich es mir vorstelle

Ich habe fälschlicherweise gedacht, dass die Hash-Ausgabe von md5 und sha1 immer leicht geknackt werden kann (erhalten Sie den ursprünglichen Eingabetext), 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 verwende, um ein Passwort zu hashen, ist es dennoch sicher. vorausgesetzt, der Server ist nicht gefährdet .

Beispiel: Speichern Sie md5 ($ 128bits_long_pepper. $ password) in der Datenbank.
Auch ohne Salz können Sie es nicht knacken. Angenommen, Ihre md5 -Hash-Geschwindigkeit beträgt 100 Milliarden Hash / s . Nehmen wir es der Einfachheit halber als 2 ^ 40 Hash / s , da 2 ^ 40 > 100 Milliarden . Um es brutal zu erzwingen, benötigt man immer noch 2 ^ 128/2 ^ 40 = 2 ^ 88 Sekunden = 9,80719764 × 1018 Jahre . 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 / Kombinationen vollständig verstehe.
Zunächst fasse ich 3 Arten von zusammen Angriffe von mir: 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 zielt darauf ab, den Angriff auf den Regenbogentisch zu verteidigen.
  2. Eine gute (langsame) Hash-Funktion 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.
  4. ol>

    Erklären Sie mit einem Beispiel:

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

    Also:

  • Salt + schnelle Hash-Funktion verteidigt keinen Brute-Force-Angriff. Ob es Regenbogentischangriffe oder Wörterbuchangriffe verteidigen kann, ist jetzt nicht wichtig.
Salt + langsame Hash-Funktion verteidigt Brute-Force-Angriffe. Es verteidigt auch den Angriff auf den Regenbogentisch. Es verteidigt keine Wörterbuchangriffe.

( Pfeffer ) Aber für die Salt + Fast Hash-Funktion Conbination, wenn Sie a verwenden Pfeffer lange genug auf dem Server, da Ihr Server nicht kompromittiert wird, nur die Datenbank, das Passwort bleibt weiterhin sicher.

Also:

  • Salz + schnelle Hash-Funktion + langer Pfeffer (z. B. 128 Bit) + Server nicht kompromittiert kann jetzt Brute-Force-Angriffe verteidigen. Es verteidigt auch Regenbogentischangriffe und Wörterbuchangriffe.

( Hash-Funktion ) Aber sobald der Server kompromittiert ist, ist die obige Kombination wie eine Scheiße. Der Angreifer würde den Pfeffer kennen. Die Schwierigkeit, Salz + schnelle Hash-Funktion + langer Pfeffer (z. B. 128 Bit) + Server zu knacken, wird kompromittiert ist dieselbe, da jemand nur eine schnelle Hash-Funktion verwendet.

Also:

  • Salz + schnelle Hash-Funktion + langer Pfeffer (z. B. 128 Bit) + Server wird kompromittiert verteidigt keinen Brute-Force-Angriff. Ob es Regenbogentischangriffe oder Wörterbuchangriffe verteidigen kann, ist jetzt nicht wichtig.
  • Wenn Sie jedoch eine sichere / langsame Hash-Funktion verwenden, ändern sich die Dinge.
    Salz + langsame Hash-Funktion + Pfeffer (muss nicht sehr lang sein, z. B. 6 Zeichen, vielleicht gut genug?) + Server wird kompromittiert Brute-Force-Angriff verteidigen. Es verteidigt auch den Angriff auf den Regenbogentisch. Es verteidigt keine Wörterbuchangriffe.

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


Sagen Sie etwas für Dave

Wie Sie von oben sehen können, ist ein Pfeffer nur etwas, das Sie verwenden Führen Sie eine Konvertierung auf der Serverseite durch.
Es ist die "Konvertierung auf dem Server", die wirklich wichtig ist, solange der Server nicht gefährdet ist.
Zum Beispiel nehmen Sie eine zufällige Konstante und verketten sie mit dem Kennwort. Hash ($ Pfeffer. $ Passwort, $ Salz) , 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).

"Für letzteres muss der Angreifer herausfinden, wie Ihr beschissenes Ding funktioniert, und einen Rückwärtsgang machen."- Für die meisten selbst erstellten kryptografischen Funktionen benötigen Angreifer keinen Zugriff auf Ihren Quellcode, um herauszufinden, wie er funktioniert.- Und niemand sagt, wenn Sie kein Experte sind, sollten Sie aufhören ... Wir sagen, wenn Sie kein Experte sind, dann willkommen im Club, und wenn Sie Experte werden möchten, großartig!Denken Sie nur nicht, dass Sie Experte genug sind, um Ihre selbstgebraute Krypto einzusetzen, um die tatsächlichen Geheimnisse zu sichern, bis Sie den Mahn-Krüger-Effekt weit hinter sich gelassen haben.
Ich würde auch gerne etwas pedantischer sein (weil es in diesem Fall wichtig ist, weil PHP-Entwickler wie meine Kollegen und viele andere Entwickler Stack Exchange lesen und weggehen und denken, sie seien Experten) - "Langsame Hashing-Algorithmen"sollten" Schlüsselableitungsfunktionen "sein, von denen einige sichere Hash-Algorithmen als Grundelemente verwenden und nicht wie Hashes umkehrbar sind ... KDFs verfügen jedoch über Einstellungen, die den Arbeitsaufwand optimieren und GPUs und GPUs widerstehenASICs.SHA2 ist langsam.PBKDF2 mit SHA2 ist sicher.
@Ghedipunk Ja, mit langsam meine ich Hash-Funktionen wie "bcrypt" und "PBKDF2".
@Ghedipunk Warum muss ein Angreifer nicht auf den Quellcode zugreifen, zum Beispiel verwende ich ein selbstgebrautes Algo auf dem Server sowie "bcrypt" und "salt" in der Datenbank?
* Wenn * Sie auch eine sichere Passwort-Stretching-Funktion verwenden, sind Sie mit oder ohne Ihren Homebrew-Hash / Crypto-Algorithmus so sicher wie möglich.Dies ist jedoch häufig nicht der Fall bei Personen, die selbstgebraute Krypto in der Produktion verwenden. Obwohl es Nuancen gibt (und infosec voller Nuancen ist), werden allgemeine Ratschläge gegeben, vorausgesetzt, ein naiver Entwickler wird die Dinge auf die naivste Weise implementieren.
Um es anders auszudrücken: Die Sicherheit in der Tiefe ist gut, aber nur so gut wie das Aggregat jeder Ebene.Eine schwache Schicht verringert nicht die Sicherheit *, solange sie nicht die Entropie verringert * (das ist ein großes Problem), aber sie muss mit starken Schichten verwendet werden, was ein Schritt ist, den viele vergessen.
Der Pfeffer ist nicht dazu gedacht, Wörterbuchangriffe abzuwehren, aber um sicherzustellen, dass ein Leck der Datenbank nicht ausreicht, um die Passwörter zu knacken.Es ist im Grunde eine sichere Möglichkeit, einen Hash-Algorithmus "anzupassen".
@forest "Stellen Sie sicher, dass ein Leck der Datenbank nicht ausreicht, um die Passwörter zu knacken."Inwiefern?Stellen Sie sicher, dass der Angreifer keinen Wörterbuchangriff ausführen kann.Sie können argumentieren, dass mit "langer Pfeffer + Salz + MD5-Hash-Funktion" auch Brute-Force-Angriffe verteidigt werden.Aber das ist nur für jemanden, der schlechte Hash-Funktionen wie "md5" verwendet.
@Rick Ein Pfeffer ist wie ein globales Salz, das außerhalb der Datenbank gespeichert ist.Sie könnten es sogar im Quellcode speichern, so dass es notwendig wäre, den Code zu verlieren, um überhaupt zu beginnen, die Hashes zu knacken.Stellen Sie sich einen Pfeffer als eine benutzerdefinierte Version eines Hashs vor, für die Sie kein Kryptograf mit jahrzehntelanger Erfahrung sein müssen, um einen benutzerdefinierten Hash oder eine benutzerdefinierte Änderung zu entwerfen.Ein Pfeffer bietet perfekten Schutz gegen ein Datenbankleck.
Ihnen fehlt eine Art von Angriff: Kryptoanalyse ... Viele Kryptoalgorithmen, die selbst von etablierten Kryptographen entwickelt wurden, sind unter bestimmten Bedingungen schwach - und dies kann häufig ohne den Algorithmus festgestellt werden.Angenommen, ich habe einen "bekannten Klartext" -Angriff - ich kann beliebigen Text angeben und dann den Chiffretext abrufen und dann statistische Methoden verwenden, um Schwachstellen im Algorithmus zu finden.
@Blackhawk Diese sind verdammt leicht zu vermeiden.Ganz zu schweigen davon, dass beim Passwort-Hashing selbst der schwächste (und einer der frühesten) Hash, MD4, nicht anfällig für Angriffe ist, die das Knacken von Passwörtern ermöglichen.Als schneller Hash und nicht als KDF ist es natürlich immer noch schlecht, Passwörter zu verwenden, aber die Kryptoanalyse ist kein Problem.Verdammt, das stimmt sogar mit dem alten Hash, der davor kam, MD2!
#7
+2
Peter
2019-07-04 00:06:53 UTC
view on stackexchange narkive permalink

Während die Verwendung eines "versteckten" benutzerdefinierten Algorithmus von Nutzen ist, gibt es bereits eine triviale und etablierte Möglichkeit, benutzerdefinierte sichere Hash-Algorithmen zu erstellen: Pepper *

Weil das sehr billig ist Es gibt eine sehr schnelle und sehr sichere Möglichkeit, einen Pepper zu verwenden. Leute, die stattdessen einen Krypto-Algorithmus von Grund auf neu schreiben, um "sicherer" zu sein, sind 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. P. >

#8
  0
Volker Siegel
2019-07-03 17:08:54 UTC
view on stackexchange narkive permalink

Faustregel: Führen Sie keine Hausbrühsicherheit durch.

Weil dies häufig 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 damit verbundenen Änderungen berücksichtigen. 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.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...