/ ** Daves selbstgebrauter Hash ^ H ^ H ^ H ^ H ^ Hkinda dummer Algorithmus * /// Benutzerdaten $ user = ''; $ password = ''; // Zeitstempel, "zufällig "# $ time = date ('mdYHis'); // Angreifern bekannt - völlig sinnlos // ^ auch, wie jdm in den Kommentaren hervorhob, ändert sich dies täglich. sieht kaputt aus! // verschiedene Hashes für verschiedene Tage? huh? oder wird dies als Salz gespeichert? $ rand = mt_rand (). '\ n'; // mt_rand ist als Zufallszahlengenerator nicht sicher // ^ es ist noch weniger sicher, wenn Sie nur nach einer einzelnen 31-Bit-Zahl fragen. und warum ist die \ n? // Krypta gut, wenn sie richtig konfiguriert / gesalzen ist // ... außer Sie haben Krypta für den Benutzernamen verwendet? WTF. $ Crypt = crypt ($ user. $ Time. $ Rand); // Hashfunktion hash_it ($ string1, $ string2) {$ pass = md5 ($ string1); // Warum verwenden wir MD5 den gleichen Durchgang, wenn Krypta verfügbar ist? $ nt = substr ($ pass, 0,8); // < --- BAD BAD BAD - warum einen MD5-Hash mischen?!?!? $ th = substr ($ pass, 8,8); $ ur = substr ($ pass, 16,8); $ ps = substr ($ pass, 24,8); // Ernsthaft. Ich habe keine Ahnung. Warum? // ^ Mischen bringt _zero_ zusätzliche Sicherheit. es macht keinen Sinn, dies zu tun. // Und was ist mit den Variablennamen los? // und jetzt SHA1 wir es auch mit anderem Müll? wtf? $ hash = 'H'.sha1 ($ string2. $ ps. $ ur. $ nt. $ th); return $ hash} $ hash = hash_it ($ password, $ crypt); // ... bitte hör auf. es tut meinem Kopf weh.summon_cthulhu ();  

Dave, du bist kein Kryptograf. Hör auf.

Diese Methode zum Selbstbrauen bietet keinen wirklichen Widerstand gegen Brute-Force-Angriffe und vermittelt einen falschen Eindruck von "komplizierter" Sicherheit. In Wirklichkeit machen Sie kaum mehr als sha1 (md5 (pass) + salt) mit einem möglicherweise kaputten und übermäßig komplizierten Hash. Sie scheinen unter der Illusion zu stehen, dass komplizierter Code eine bessere Sicherheit bietet, aber dies ist nicht der Fall. Ein starkes Kryptosystem ist stark, unabhängig davon, ob der Algorithmus einem Angreifer bekannt ist - diese Tatsache wird als Kerckhoff-Prinzip bezeichnet. Mir ist klar, dass es Spaß macht, das Rad neu zu erfinden und es auf Ihre eigene Weise zu tun, aber Sie schreiben Code, der in eine geschäftskritische Anwendung eingeht, die Kundenanmeldeinformationen schützen muss. Sie sind dafür verantwortlich, es richtig zu machen.

Halten Sie sich an bewährte Algorithmen zur Schlüsselableitung wie PBKDF2 oder bcrypt, die jahrelange Erfahrung gemacht haben Tiefenanalyse und -prüfung durch eine Vielzahl von professionellen und Hobby-Kryptographen.

Wenn Sie eine gute Schulung zum richtigen Speichern von Passwörtern wünschen, lesen Sie die folgenden Links:

• Wie speichere ich Salz?
• Empfehlen Sicherheitsexperten bcrypt für die Kennwortspeicherung?
• Wie speichere ich Kennwörter sicher? ?

Vorteile eines öffentlichen Protokolls:

• Wahrscheinlich von klügeren Leuten als Ihnen geschrieben
• Von viel mehr Leuten getestet (wahrscheinlich einige von ihnen schlauer als Sie)
• Von viel mehr Leuten bewertet (wahrscheinlich einige von ihnen schlauer als Sie), hat oft mathematische Beweise
• Verbessert von viel mehr Leuten (wahrscheinlich einige von ihnen schlauer als Sie)
• Im Moment findet nur einer dieser Tausenden von Menschen einen Fehler, viele Leute beginnen ihn zu beheben.

Nachteile eines öffentlichen Protokolls:

• Wenn tatsächlich ein Fehler gefunden wird,
• UND veröffentlicht
• UND nicht schnell genug behoben wird

, beginnen Angreifer, nach anfälligen Websites zu suchen / Anwendungen. ABER:

• Sie werden wahrscheinlich zuerst wichtigere Ziele verfolgen.
• Wenn der Fehler aufgedeckt wird, wissen Sie, dass Sie ihn sperren können.
• Nicht Alle Fehler sind "kritisch" (die meisten sind wie "Kollisionen sind unter bestimmten Bedingungen möglich" oder "die Zeit bis zur Bruteforce beträgt nicht 10 12 Jahre, sondern 10 6 Jahre").

Sicherheit durch Dunkelheit wird als absolut schlecht angesehen. Das Erfinden Ihrer eigenen fällt unter diese Kategorie.

Wenn Dave wirklich "Ihr" Entwickler ist, da Sie die Berechtigung haben, ihn zu entlassen, haben Sie die Berechtigung, ihn anzuweisen, ein besser dokumentiertes Schema zu verwenden, und Sie sollten.

In der Kryptographie ist es umso besser, je weniger Geheimnisse aufbewahrt werden müssen. Dies gilt insbesondere für "fest codierte" Geheimnisse wie die Hash-Funktion selbst, die keine Geheimnisse sind, sobald der Code, der das Geheimnis enthält, Ihr Gebäude verlässt.

Aus diesem Grund sind offene Standards für die Kryptografie a gute Sache; Wenn es das Schema schon seit Jahren oder sogar Jahrzehnten gibt, der grundlegende Algorithmus und verschiedene Implementierungen öffentlich bekannt sind und immer noch niemand einen Weg gefunden hat, hineinzukommen, ist es ein gutes Schema.

In diesem Fall lieferte Polynom eine sehr gute Aufschlüsselung der Fehler im Schema, aber hier sind die Hauptfehler des vorgeschlagenen Hash-Algorithmus:

• MD5 ist vollständig fehlerhaft ; Während ein Preimage-Angriff durch die primäre Art und Weise, wie MD5 beschädigt wird, nicht viel einfacher wird (es ist extrem anfällig für Kollisionen mit bekanntem Klartext; wenn man die Nachricht und den Digest kennt, kann man in 2 ^ 24-Zeit eine Kollision erzeugen), das Hashing Der Algorithmus ist viel zu schnell, um gegen moderne verteilte Cracking-Hardware sicher zu sein. Es sollte niemals in Anwendungen verwendet werden, die Datensicherheit erfordern.

• SHA-1 wird als anfällig angesehen ; Auch hier gibt es keinen eleganten Vektor für einen Preimage-Angriff, aber es gibt einen starken Kollisionsangriff (2 ^ 61 Mal für einen 160-Bit-Hash), und der Hashing-Algorithmus ist schnell genug und der Schlüsselbereich klein genug, damit die aktuelle Hardware realistisch brutal werden kann -force it.

• Mehr Hashes bedeuten nicht unbedingt besseres Hashing . Hashes sind ein deterministischer Prozess; Sie stehen für ein "zufälliges Orakel" in der theoretischen Kryptographie, aber da sie bei derselben Eingabe immer dieselbe Ausgabe erzeugen müssen, können sie dem, was der Eingabe bereits inhärent ist, keine Entropie hinzufügen.

  Einfach ausgedrückt, die Verwendung einer geheimen Kombination mehrerer Hashes wie Dave, selbst wenn diese Kombination unbekannt ist, fügt einer Brute-Force keinen nennenswerten Arbeitsaufwand hinzu (die relative Reihenfolge von drei Hashes bietet 6 Möglichkeiten). Erhöhen Sie die Komplexität, alle Möglichkeiten auszuprobieren, um weniger als 3 Potenzen von 2), und diese zusätzliche Komplexität verschwindet, sobald ein Angreifer Ihren Code dekompilieren und die relative Reihenfolge der Hash-Funktionen ermitteln kann.

• Passwörter haben von Natur aus eine niedrige Entropie . Die besten "vom Benutzer konsumierbaren" (Nicht-Kauderwelsch) Passwörter weisen eine maximale Komplexität von etwa 50 Entropiebits auf, was bedeutet, dass sie geknackt werden können, wenn Sie eine Vorstellung davon haben, wonach Sie suchen, in 2 ^ 50 oder einer besseren Zeit . Dadurch lassen sich Passwörter leichter knacken als andere Dinge, die Sie normalerweise hashen würden (z. B. Zertifikat-Digests), und es ist ein zusätzlicher "Arbeitsnachweis" erforderlich, um die Sicherheit zu erhöhen.

• Dieses Schema fügt keinen signifikanten Arbeitsnachweis hinzu ; Drei Hashes anstelle von einem fügen im großen Schema der Dinge dem Schema das Äquivalent von ungefähr 1,25 Bit Entropie hinzu, wenn zusätzliche Arbeit erforderlich ist. Sie könnten es besser machen, wenn Sie nur verlangen, dass Kennwörter ein Zeichen länger sind.

BCrypt hat im Gegensatz zu allen oben genannten als Hauptvorteil eine extrem langsame Schlüsselableitungsfunktion oder KDF. Blowfish, die Verschlüsselungs-Chiffre, die die Grundlage von BCrypt bildet, verwendet eine "SBox". ein großes Array von vorbestimmten Anfangswerten, das durch den Schlüssel und / oder IV modifiziert wird, um den Anfangszustand der Chiffre zu erzeugen, durch die der Klartext geführt wird. In BCrypt wird dieses SBox-Setup komplexer, indem die kleineren Kennwort- und Salt-Werte eine vorbestimmte Anzahl von Malen durch die "nicht verschlüsselte" Chiffre laufen und die Chiffre in einen Zustand "aufwärmen", der theoretisch nur durch Ausführen erzeugt werden kann die gleiche Anzahl von Iterationen des Setups mit dem gleichen Passwort und Salt. Dieser "aufgewärmten" Chiffre wird dann ein konstanter Klartext zugeführt, um den Hashwert zu erzeugen. In CS-Begriffen bildet der Hash einen "Arbeitsnachweis"; Eine Rechenaufgabe, die schwierig (zeit- und / oder ressourcenintensiv) durchzuführen ist, aber leicht auf ihre Richtigkeit zu überprüfen ist (stimmt der erzeugte Hash mit dem überein, den wir bereits haben?).

Diese "vorgegebene Zahl "der Iterationen des SBox-Setups ist konfigurierbar; Dies ist die wahre Kraft von BCrypt. Beim Hashing wird eine Anzahl von "Runden" des Schlüssel-Setups angegeben, und für n Runden werden 2 ^ n Iterationen des Schlüssel-Setups durchgeführt. Das bedeutet, dass durch Erhöhen der Anzahl der Runden der Hash doppelt so viel Arbeit leistet und auf derselben Hardware doppelt so lange benötigt, um den erforderlichen Arbeitsnachweis zu erstellen. BCrypt kann daher leicht mit Moores Gesetz Schritt halten, das der Fluch vieler vorheriger Hash-Funktionen war.

Die größte theoretische Schwäche von BCrypt ist die geringe Speichernutzung. Während die Rechenzeit exponentiell erhöht werden kann, bleibt die benötigte Speichermenge effektiv konstant (die SBox wird mit zunehmenden Iterationen nicht größer und es müssen keine "Zwischenergebnisse" beibehalten werden). Während BCrypt die reine Pipeline-Rechenleistung einer GPU behindert, bleibt es als anfällig für Cracking durch ausgefeiltere "feldprogrammierbare Gate-Arrays" (im Grunde genommen ein massiver, hochmodularer Satz von "weich verdrahteten" Logikeinheiten) aktueller Stand der Technik im Bereich hochverteiltes Rechnen), da aufgrund der geringen Speicherbeschränkungen nur relativ kostengünstigere Leiterplatten auf das Problem geworfen werden können.

Ein neuerer Algorithmus, SCrypt, bekämpft FPGA-Cracker Durch exponentielles Erhöhen des Speicherbedarfs sowie des Rechenaufwands für die Berechnung des Hashs macht der begrenzte Speicher, der jedem FPGA zur Verfügung steht, diese ebenfalls schnell unmöglich (verteiltes Cracken würde grundsätzlich eine große Anzahl von CPU / FSB / RAM-Kombinationen erfordern, im Wesentlichen volle Computer zusammengehakt). Das einzige Problem besteht darin, dass SCrypt erst 2 oder 3 Jahre alt ist und daher nicht den kryptoanalytischen Stammbaum von BCrypt (13 Jahre alt) hat. Und wirklich, wenn Sie sich Sorgen machen müssen, dass ein FPGA-bewaffneter Cracker in möglicher Zeit ein Passwort erhält (wie bevor Sie sowieso alle ändern können), haben Sie einige sehr mächtige Leute angepisst und haben bereits eine weitere schwerwiegende Sicherheitsanfälligkeit aufgedeckt (die es einem Angreifer ermöglicht, Ihre gespeicherten Passwort-Hashes zu erhalten, damit er eine "offline" knacken kann)

Verwenden Sie unter dem Strich BCrypt für das Passwort-Hashing. Es ist 13 Jahre alt und basiert auf einem 20 Jahre alten Verschlüsselungsalgorithmus. In dieser Zeit wurden keine bekannten Schwachstellen gefunden, die einem Passwort-Cracker helfen könnten. Es ist langsam wie Melasse und kann so konfiguriert werden, dass es immer so ist, vorausgesetzt, Sie müssen es mit der Anforderung kombinieren, dass Benutzer ihr Kennwort etwa alle 90 Tage ändern müssen, damit neue Kennwörter immer häufiger mit teureren Konfigurationen gehasht werden.

Um Dave gegenüber fair zu sein, ist dies in Bezug auf die Sicherheit von Homebrew-Passwörtern einer der besseren Fälle, da alles nur eine kleine Verschleierung (und wirklich nicht viel) ist, die hash = SHA1 (salt + MD5 '(Passwort) maskiert. ) wobei MD5 ' einen reversiblen Austausch der Reihenfolge der Bytes des MD5-Hashs durchführt. Jetzt wird der Benutzername / Zeit / Zufall / Krypta-Teil nur verwendet, um ein Salz zu erzeugen, und die einzige Anforderung, die wir an Salze haben, ist, dass sie nur eine sehr gute Wahrscheinlichkeit der Eindeutigkeit haben müssen; Obwohl es zu kompliziert ist, hat es wirklich keinen Sinn, darüber zu sprechen.

Wieder hash = sha1 ($ salt + md5 '($ password)) . Durch das Neuanordnen des MD5 wird keine Sicherheit hinzugefügt ( swap (00112233445566778899aabbccddeeff) wird zu ccddeeff8899aabb0011223344556677 ) Tauschen). Das Vorhandensein des einzigartigen Salzes macht die Regenbogentabellen jedoch unmöglich.

Um kritisch zu sein, läuft dies auf eine einfache kryptografische Hash-Funktion hinaus, die zweimal angewendet wird. Dies ist besser als das Speichern von Klartext-Passwörtern (siehe Klartext-Straftäter) und besser als das Speichern eines ungesalzenen Hashs (siehe Linkedin-Leck). Im Zeitalter billiger massiv paralleler GPUs ist dies jedoch für den modernen Einsatz zu schwach. Jeder mit ein wenig Erfahrung in der GPU-Programmierung für allgemeine Zwecke, der irgendwie auf den Live-Server gelangt ist (um die Hashes mit seinem Salz zu erhalten), kann wahrscheinlich seinen Quellcode sehen, sein eigenes Passwort als Testfall ausprobieren und dann jedes brutal erzwingen bestimmtes Passwort mit einer Rate von Milliarden von Versuchen pro Sekunde pro GPU.

Wenn also ein Benutzer ein Kennwort in einer Liste von etwa einer Million zuvor durchgesickerten Kennwörtern verwendet (z. B. von LinkedIn), kann der Angreifer es fast augenblicklich knacken. Wenn das Passwort eines Benutzers ein zufälliger 8-Buchstaben aus dem Zeichensatz A-Za-z0-9 ist; Es würde durchschnittlich etwa 60 Stunden dauern, um pro GPU zu brechen (wenn Sie also 60 GPUs hätten; würde 1 Stunde dauern). Die Verwendung gängiger Cracking-Techniken, bei denen Formen gängiger Kennwörter ausgenutzt werden, könnte dies erheblich beschleunigen. Es ist auch erwähnenswert, dass, da $ password eine 128-Bit-MD5-Hashing-Funktion durchläuft, die Verwendung von mehr als 128-Bit-Entropie in der Passphrase absolut keinen Vorteil bringt (obwohl dies fairerweise sehr wichtig ist sicheres Passwort (wie eine 10-Wort-Diceware-Passphrase oder ein zufälliges alphanumerisches Passwort mit 22 Zeichen).

Wirklich, Sie sollten iterierte kryptografische Hash-Funktionen verwenden. Das ist so etwas wie bcrypt oder PBKDF, das die Brute-Force-Rate von Angreifern um einen großen konstanten Faktor verlangsamt (z. B. 10 ^{5 sup>) (also statt 60 Stunden, um ein zufälliges 8-Zeichen-Passwort von a zu knacken 62-Zeichen-Set (A-Za-z0-9); mit einer einzelnen GPU dauert es 6 Millionen Stunden (~ 700 Jahre, bis es wahrscheinlich kaputt geht), und dies wird mit stärkeren Passwörtern besser (z. B. würde ein 10-Zeichen-Passwort ~ dauern 3 Millionen Jahre; selbst mit einer Million GPUs würde es 3 Jahre dauern. Eine kleine Tastenverstärkung verschiebt also ein relativ schwaches Passwort (8 zufällige Zeichen aus 62 Zeichen) aus dem Bereich der Machbarkeit, von einem Angreifer geknackt zu werden. Weitere Informationen Die Obergrenzen für die Verwendung eines einfachen, durch Tastenverstärkung verstärkten Kennworts finden Sie in dieser Antwort.}

Kollisionsangriffe im Vergleich zu Pre-Image-Angriffen (oder warum Kollisionsangriffe auf eine Hash-Funktion für das Kennwort-Hashing irrelevant sind)

KeithSs Antwort, obwohl es gute Ratschläge gibt (verwenden Sie bcrypt und keine einfache kryptografische Hash-Funktion, um Ihr Passwort zu hashen), kritisierte MD5 und SHA1 ursprünglich für die falsche Begründung (verwenden Sie MD5 nicht als dessen anfällig für Kollisionsangriffe). Es gibt einen subtilen Unterschied zwischen Vorbild- und Kollisionsangriffen, und die Argumentation in den Kommentaren war zu komprimiert, daher werde ich hier näher darauf eingehen. Ich empfehle dringend, den Wikipedia-Artikel über Pre-Image-Angriffe zu lesen.

Ein Pre-Image-Angriff besagt, dass ein bestimmter 128-Bit-Hash hexadezimal geschrieben ist: h = ad2baf26a87795b3c8a8366a08b44112 , eine bestimmte Hash-Funktion H , finden Sie eine Nachricht m , so dass h = H (m) ; Es ist zu beachten, dass es N = 2 128 verschiedene unterschiedliche Hashes gibt. Wenn Ihre kryptografische Hash-Funktion nicht unterbrochen ist, hat jedes Bit in Ihrem Hash eine 50% ige Chance, 0 oder 1 für eine zufällige Nachricht m zu sein. Dann muss ich im Durchschnitt Hashes für ungefähr N = 2 128 Hashes generieren, bevor ich das Glück habe, eine Nachricht m zu finden, so dass h = H (m ) (Diese Nachricht ist möglicherweise nicht dieselbe Eingabe, die ursprünglich zum Generieren des Hashs verwendet wurde. Dies fällt jedoch immer noch unter die Kategorie "Pre-Image" -Angriff.)

Ein Kollisionsangriff sagt, finde mir zwei beliebige Nachrichten m1 und m2 , so dass H (m1) = H (m2) . Beachten Sie, dass m1 , m2 (und H (m1) ) alle frei geändert werden können. Dieser Fall ist ein viel einfacheres Problem, da ich, wenn ich M Hashes für M verschiedene Nachrichten generiere, nicht nur die M Nachrichten mit einem bestimmten Hash vergleiche (also M Chancen haben, eine Kollision zu finden), sondern jetzt M * (M- 1) / 2 Paar Hashes, also ungefähr M ^ 2 Chancen auf eine Kollision. In diesem Fall muss ich also ungefähr sqrt (N) ~ 2 ^{64 sup> -Hashes generieren, bevor es wahrscheinlich ist, dass einer von ihnen mit einem anderen auf einem idealen 128-Bit-Hash kollidiert. P. >}

Schauen wir uns die beiden Arten von Geburtstagsproblemen an. Das Kollisionsproblem führt zu dem üblichen "Paradoxon" zum Geburtstag. Wie viele Personen brauchen Sie in einem Raum, bevor zwei Personen einen Geburtstag mit N = 365 Tagen im Jahr haben? Die Antwort ist paradox, da Sie nur ungefähr sqrt (N) ~ 23 Personen benötigen, bevor sich wahrscheinlich zwei Personen einen Geburtstag teilen (wie bei 23 Personen in einem Raum haben Sie 253 verschiedene Personenpaare, die übereinstimmen könnten). (Ich weiß, dass sqrt (365)! = 23: Ich verwende eine ungefähre Mathematik, die sich nicht auf unbedeutende konstante Faktoren konzentriert. Wiederholen Sie die Berechnung mit sqrt (365) ~ 19 Personen im Raum und dann P (zwei gemeinsame Geburtstage) ) = 19! * Comb (365,19) / 365 ** n = 37,9% , was zwar nicht streng 50% bedeutet, aber dennoch bedeutet, dass es ziemlich wahrscheinlich ist). Hinweis für das Kollisionsgeburtstagsproblem: Sie können nicht N + 1 = 366 Personen in einem Raum haben und es besteht die Möglichkeit, dass Sie keine Kollision haben (Schalttage ignorieren). Bestenfalls hatten die ersten 365 Personen unterschiedliche Geburtstage und die letzte Person verursachte eine Kollision.

Das Problem vor dem Bild ist eine ganz andere Frage: Wie viele Personen brauche ich in einem Raum, bevor dies sehr wahrscheinlich ist? Jemand hat einen bestimmten Geburtstag (sagen wir B = 18. Dezember). In diesem Fall brauche ich ungefähr N ~ 365 Leute, bevor es wahrscheinlich ist. Beispiel: Bei 365 Personen im Raum haben Sie ein P (jemand hat Geburtstag B) = 1 - (1 - 1/365) ^ (# Personen) , also für # Personen = 365 Sie haben eine 63% ige Chance, dass jemandes Geburtstag ein festes Datum B ist. In diesem Fall können Sie sich leicht vorstellen, dass sich eine beliebige Anzahl von Personen in einem Raum befindet und niemand an einem bestimmten Datum Geburtstag hat. (Angenommen, Sie haben nur Personen in den Raum eingeladen, wenn der Geburtstag kein bestimmtes Datum war. Die Anzahl der Personen, die Sie einladen können, ist unbegrenzt.)

Wenn eine Hash-Funktion wie MD5 / SHA1 für Kollisionsangriffe unterbrochen wird, bedeutet dies, dass Sie eine Kollision in weniger Arbeit als der Brute-Force-Zeit von sqrt (N) ~ 2 ^{numbits / 2 sup> erzeugen können. Für MD5 dauert es nur etwa 2 bis 24 Stunden, um eine Kollision zu erzeugen. für SHA1 dauert es ~ 2 ^ 61 Zeit. Das bedeutet, dass Kollisionsangriffe auf MD5 extrem einfach durchzuführen sind. Praktische Angriffe auf SHA1 sind jedoch immer noch schwierig. Kollisionsangriffe sind jedoch nur dann von Bedeutung, wenn es Ihnen egal ist, mit welchem ​​Hash Sie übereinstimmen möchten. Diese Kollisionsangriffe sind für einige Anwendungen wie das kryptografische Signieren von Nachrichten sehr relevant, um die Nachrichtenintegrität sicherzustellen. Achten Sie daher in diesen Fällen auf die Verwendung von MD5 / SHA1. Wenn Sie jedoch ein eindeutiges Salz und einen bestimmten Hash haben, den Sie zur Authentifizierung abgleichen möchten, spielen Kollisionsangriffe keine Rolle.}

Siehe den entsprechenden Beitrag zum Security Meme

Obwohl dies sehr simpel erscheint, gelten die Regeln - Entwerfen von Krypto-Algorithmen und Implementieren sie richtig / sicher ist sehr schwer. Sogar diejenigen, die von Experten entworfen und im Laufe der Jahre von Tausenden von Menschen ausgewählt wurden, haben irgendwann Löcher entdeckt.

Also Rollen Sie nicht Ihre eigene Krypto ist ein guter Rat für alle (möglich) Ausnahmen sind Persönlichkeiten wie Rivest, Adleman, Pornin, Shamir)

Obwohl wir mit Daves Algorithmus viele Fehler finden können, ist es wirklich nicht schrecklich , weil es nicht zu 100% hausgemacht ist. Er verwendet Hashing-Protokolle, die (wenn auch schwach) auf soliden Prinzipien basieren. Andererseits unternimmt er Schritte, die die Komplexität für den Entwickler erhöhen, aber wenig zur Verbesserung der Sicherheit seines Algorithmus beitragen.

Aber der Grund, warum ich hier eine weitere Antwort hinzufüge, ist das uralte Argument, dass Dunkelheit einen Wert hat. Die primäre Verteidigungslinie sollten immer starke, allgemein akzeptierte Hashing-Algorithmen sein, aber es schadet nicht, selbst die kleinste Menge an Dunkelheit als zusätzliche Verteidigungsschicht hinzuzufügen.

Diese Schicht der Dunkelheit sollte niemals als Verteidigung an sich betrachtet werden, sondern lediglich als zusätzlicher Faktor, der die Wahrscheinlichkeit eines Kompromisses verringert. Da für einen erfolgreichen Angriff normalerweise eine Reihe von Faktoren erforderlich sind, können selbst kleine Abwehrkräfte einen großen Einfluss auf die Reduzierung Ihres Gesamtrisikos haben.

Ich kann Ihnen nicht sagen, wie oft ich Hash-Dumps gesehen habe, die ich zu knacken versucht habe, wo ich einfach nichts bekomme, weil irgendwo Dave an diesen dummen Nicht-Standard-Algorithmus gedacht hat, den ich nicht knacken kann ohne eine intensive Kryptoanalyse durchzuführen oder in die Webserver einzudringen, um den Algorithmus zu erhalten. Sie können nicht leugnen, dass diese dummen Algorithmen ein gültiger Abwehrfaktor sind.

Wenn Dave nun seinen dummen Algorithmus als Schicht zu stärkeren Algorithmen wie PBKDF2 oder bcrypt hinzugefügt hat, hat er Unklarheiten mit dem Unterstützung solider Sicherheitspraktiken. Außerdem muss Dunkelheit nicht so komplex sein wie Daves Code. Alles, was Sie wirklich brauchen, ist ein bisschen anders zu sein, um dunkel zu sein. Denken Sie daran, dies ist keine Verteidigung, sondern nur eine Schicht der Dunkelheit.

Bessere Möglichkeiten, um Dunkelheit zu erreichen, sind die Verwendung eines HMAC, die Verkettung einer serverseitigen Salzkonstante und / oder die Verwendung einer großen, nicht standardmäßigen Anzahl von Iterationen. Keine dieser Maßnahmen steht für sich allein, aber sie befassen sich mit Sicherheit mit bestimmten Angriffsmethoden, die zu Ihrem Gesamtrisiko beitragen.

tl: dr; Sicherheit durch Dunkelheit ist schlecht, aber solide Sicherheit plus ein angemessenes Maß an Dunkelheit ist eine gültige Strategie.

OK, feuere Dave ab. Zumindest schlug ihn mit einem sehr großen Hinweisschläger. Offene Protokolle sind gut, da jeder nach Schwachstellen und strukturellen Problemen suchen und versuchen und Korrekturen implementieren kann. Die Sichtbarkeit verbessert das Protokoll. Gute Sicherheit bedeutet, dass jeder wissen kann, wie das System funktioniert, und dass es dennoch sicher ist.

Überzeugen Sie ihn mit guten Überlegungen. Beschimpfe ihn nicht.

Sie müssen darüber nachdenken, warum wir Hashing-Passwörter verwenden: Der Grund dafür ist, das ursprüngliche Passwort zu schützen, indem der Hashing-Prozess viel CPU-Zeit in Anspruch nimmt, um ausgeführt zu werden. Brute Force ist die Art und Weise, wie die Passwörter normalerweise wiederhergestellt werden.

Wenn der Angreifer Ihre Kennwortdatenbank stehlen kann, hat er es geschafft, auf Ihre Datenbank zuzugreifen. Wenn sie Zugriff auf die Datenbank haben, haben sie wahrscheinlich auch Zugriff auf den Code, der diese Kennwörter erzeugt. Nach Überprüfung des Codes können sie damit beginnen, die Kennwörter brutal zu erzwingen, da die Ausführung des Hashing-Algorithmus zu wenig Zeit in Anspruch nimmt.

Die Idee hinter bekannten Hashing-Methoden und -Praktiken wie mit PBKDF2 mit 10.000 Iterationen bedeuten, dass die Ausführung auf der aktuellen Hardware viel Zeit in Anspruch nimmt.

Wenn Sie etwas Zeit zur Verfügung haben, können Sie auch ein Brute-Forcing-Programm schreiben und ihm zeigen, wie viele Angriffe Sie pro Sekunde ausführen kann mit seinem Algorithmus gegen vorherrschende Standards ausführen.

Ich habe mehrere Hashing-Algorithmen geschrieben. Es ist nichts falsch daran, wenn Sie wissen, was Sie tun. In sehr geringem Maße hat er Recht damit, dass bewährte Algorithmen etwas anfälliger für Angriffe sind. Wenn Sie also einen guten -Algorithmus erstellen können, sind Sie goldrichtig. Das einzige Problem ist, dass er aus einer Reihe von Gründen total scheiße ist.

1. // Zeitstempel, zufälliges # $ time = Datum ('mdYHis');

   Ich habe nicht einmal das Gefühl, dass ich das erklären muss. Er hat versucht, eine gesetzte "Zufallszahl" zu erstellen, wenn dies keinen Sinn ergibt. Die Hashes ändern sich von Tag zu Tag. Ich kann mir nicht vorstellen, dass dies in einem vernünftigen Szenario funktioniert.

2. Er sagt, dass er von bekannten Hashing-Algorithmen abweichen möchte, verwendet jedoch MD5 (das bekannteste von allen und ein faires) auch schwach) für den Großteil "seines" Algorithmus. Seine Methode ist nur eine sehr leichte Ableitung von einfachem ole MD5-Hashing. Das bringt mich zu:
3. Er mischt sein MD5-Ergebnis. Äh, warum? Bitten Sie ihn als lustige kleine Aktivität, seine Argumentation dort zu erklären. Und ich gebe Ihnen einen Tipp, um Ihnen zu helfen: Was auch immer seine Antwort ist - es ist falsch. Das Mischen eines Hash-Werts ist wie das Mischen eines Kartenspiels mit leeren Karten. Es gibt keinerlei zusätzlichen Nutzen daraus.
ol>

Es gibt auch mehr Dinge, die daran falsch sind, aber dies sind die großen. Sagen Sie ihm, er soll zu seiner gewohnten Arbeit zurückkehren und einfach bcrypt (oder scrypt verwenden, was wahrscheinlich sogar etwas sicherer ist, um die Tatsache zu tun, dass es wirklich CPU-intensiv ist).

Die Steganographie würde besser von Daves Betriebsgeheimnis profitieren als die Kryptographie. Dies könnte das sein, was Dave intuitiv anstrebte.

Kryptografie

Jede kryptografische Lösung profitiert von einer größtmöglichen Belichtung , weil sie sich darauf verlässt Ein anderes Geheimnis als der private Schlüssel erschwert die Betriebssicherheit für einen Krypto-Konsumenten viel . Ein Schlüssel ist ein einzelnes, einfach zu verwaltendes, tragbares, vorhersehbares und genau definiertes Sicherheitsrisiko, bei dem Krypto-Experten große Anstrengungen unternommen haben, um sicherzustellen, dass alle Risiken im Algorithmus auf only beschränkt sind der Schlüssel.

Schlüssel können nicht erraten werden (hohe Entropie), um Brute-Force- oder Seitenkanalangriffe zu erfordern. Geheimnisse in anderen Aspekten eines Algorithmus können nicht als unschätzbar angesehen werden, da jeder andere Aspekt eines Verschlüsselungsalgorithmus in eine universelle Klasse von (möglicherweise schwächeren) Verschlüsselungsalgorithmen + einen konstanten Wert verallgemeinert werden kann. Dieser konstante Wert repräsentiert die gesamte verbleibende invariante Entropie in der Struktur oder Verschleierung des Algorithmus. Dieser Wert ist in einem Home-Brew-Algorithmus niemals besonders groß oder entropisch und in jedem nicht selbstmodifizierenden Computerprogramm von Natur aus konstant. Ein Angreifer kann entweder die Quelle erfassen und diese (geringfügige) Entropie direkt entfernen oder den Chiffretext über eine verallgemeinerte Klasse von Algorithmen ausführen. Die NSA würde dies beispielsweise genau für unbekannte Varianten gängiger Algorithmen tun, die von ausländischen Mächten verwendet werden.

Steganographie

Jede steganographische Lösung profitiert von der geringste öffentliche Exposition , da der Angreifer beim Verbergen des Ortes von Geheimnissen seine Suche auf eine für dieses Opfer möglicherweise einzigartige Weise anpassen muss; und skaliert auf die Menge möglicher Verstecke und Versteckmethoden, die dem Opfer zur Verfügung stehen.

Dies kann so einfach sein, als ob Sie eine gefälschte Hash-Passwortspalte haben und die echte in vier (64-Bit) time_t -Spalten in verschiedenen Tabellen ausblenden, in denen Benutzerinformationen aufgezeichnet werden. Dies kann so komplex sein wie das Ausblenden von a Tragbare Linux-Emulation in einem BluRay-Film.

Steganografie basiert letztendlich auf der Erstellung oder Änderung eines Artefakts, das eine öffentliche semantische Bedeutung oder einen öffentlichen Zweck und einen sekundären privaten semantischen Sinn oder Zweck hat. Eine Person oder Organisation profitiert davon, sekundäre semantische Bedeutungen auf die gleiche Weise zu verbergen wie jede Lüge durch Unterlassung. Sei es " Meine Socke ist langweilig und enthält keine Diamanten " oder " Dies sind die Hashes, nach denen Sie suchen. Ignorieren Sie diesen Honeypot oder diese Socket-Verbindung zu einem Audit-Server ".

In Kombination

Dave sollte also öffentlich geprüfte High-Level-Bibliotheken wie BouncyCastle anstelle eines Home-Brews von Low-Level-Krypto-Primativen verwenden. Sie sollten sich jedoch frei fühlen, damit der Hacker, der durch die Serverökologie navigiert, das Gefühl hat, ein Brainfuck -Programm zu lesen, dem einige Zeichen fehlen.

Vorausgesetzt, die vollständige Supportdokumentation wird für Daves Nachfolger an einem sicheren Offline-Speicherort aufbewahrt ...

Ich werde einen anderen Ansatz versuchen, um dies zu beantworten. Ich werde Ihnen nicht sagen, dass etwas schlecht ist, und nicht erklären, warum. Ich werde Schritt für Schritt genau erklären, warum es schlecht ist, und zeigen Ihnen, wie Sie es brechen können, aber ich werde nicht zu tief in die Regenbogentabellen gehen ... es wird davon ausgegangen, dass Sie wissen, was das ist ist.

Hier ist der Grund, warum der Hash Ihres Entwicklers falsch ist: weil er nur einige Faktoren einführt, die nach der Entdeckung der Methode völlig brutal erzwungen werden könnten, selbst wenn er das Mischen zufällig auswählen würde.

Wie? Denn wenn ich Zugriff auf Ihren Server habe, kenne ich auch die Methode, mit der Ihr Entwickler Ihr Kennwort hasht, weil ich diesen Code ebenfalls gestohlen habe, und ich kann alles neu anordnen, um es meiner kleinen Crackpot-Anwendung anzupassen.

Nehmen wir an, ich habe Ihr Unternehmen gehackt und Zugriff auf Ihre Datenbank erhalten, damit ich diese Hashes erhalten kann. Ich weiß, wann sich Benutzer registrieren, richtig? Ich weiß, wann sie ihr Passwort zuletzt geändert haben, denn wenn Sie kein Neuling sind, sollten Sie diese Informationen in der Datenbank protokollieren.

  $ time = date ('mdYHis');  

Dieser Zeitstempel ist wahrscheinlich ungefähr zu der Zeit, zu der der Benutzer sein Passwort registriert oder geändert hat. Wir können dies wissen, da das letzte Mal, als es aktualisiert wurde, in der Datenbank gespeichert werden sollte. Die Zeit, die Sie registriert haben, sollte in der Datenbank gespeichert werden. Ein Teil der Krypta wurde besiegt.

  $ rand = mt_rand (). '\ n';  

Cool, ein Zufallszahlengenerator. Wissen Sie, auf Computern ist nichts wirklich zufällig. Zufallszahlengeneratoren sind nicht wirklich zufällig. Dies ist der Mersenne Twister . Ich brauche nur 624 verschiedene Kombinationen, um alle zukünftigen Zahlen herauszufinden. Ich habe auch Ihr "Salz" aus der Datenbank gestohlen und weiß, wie Sie es berechnen.

Da ich die Daten kenne, an denen sich Ihre Benutzer registriert haben, kann ich die richtige Nummer für die Mersenne Twister-Routine zu diesem bestimmten Zeitpunkt neu erstellen. Ich kann eine kleine Cracking-Methode schreiben, um die genaue Zahl zu ermitteln, die zu diesem Zeitpunkt wahrscheinlich auftreten würde. Dein Salz ist nicht mehr zufällig. Aber weißt du was? Es ist irrelevant. Ich kenne das genaue Format, das Sie für dieses Salz verwenden, und ich habe es wahrscheinlich trotzdem aus Ihrer Datenbank erhalten. Dann kann ich Rainbow Tables verwenden, um Ihr Salz in weniger als einer Sekunde vollständig zu vernichten, da mt_rand () allein maximal 10 ^ 10 Hashes und ein Minimum von erzeugt 10 ^ 9 , was 11 Milliarden Möglichkeiten bedeutet, und da alle Zahlen sind und ich das Format Ihres Salzes kenne, werden sie in weniger als einer Sekunde geknackt.

Also jetzt Ich weiß, wem dieser Benutzername gehört, weil ich Ihre Datenbank aufgebockt habe. Ich weiß, wann sie sich registriert haben, wann sie ihr Passwort zuletzt geändert haben und ich kenne Ihre Zufallszahl. Ich sehe dich, Dave, einen Dieb auf dem Dach. Meine neue Satellitenverbindung hat sowohl Infrarot- als auch Röntgenspektrum. Ich sehe dein Herz schlagen. Ich sehe, Sie haben Angst.

Nachdem $ crypt besiegt wurde, werfen wir einen Blick auf die -Funktion hash_it () .

  -Funktion hash_it ($ string1, $ string2) {$ pass = md5 ($ string1); $ nt = substr ($ pass, 0,8); $ th = substr ($ pass, 8,8); $ ur = substr ($ pass, 16,8); $ ps = substr ($ pass, 24,8); $ hash = 'H'.sha1 ($ string2. $ ps. $ ur. $ nt. $ th); return $ hash}  

Schauen wir uns nun einige Beispieleingaben an: hash_it (Dave, testpassword1);

Ergebnisse:

  $ pass = "b7e055c6165da55c3e12c49ae5207455" $ nt = "b7e055c6"; $ th = null; $ ur = "3e12c49a"; $ ps = "e5207455";  

$ hash Input : "H" + "Benutzername +" Registrierungsdatum "+" 1604716014 "+" e5207455 "+" 3e12c49a "+" b7e055c6 "(tldr: "HDaveRegistrationDate1604716014e52074553e12c49ab7e055c6" )

  $ hash = 'H'.sha1 ("DaveRegistrationDate1604716014e52074553e12c49ab7e055c6);  

` $ hash output : "6b347a1521b6b84501806268614abe1e7324c703; Zeit)

So könnte ein Angriff funktionieren :

1. Mersenne Twister ( mt_rand () ) nach 624 brechen Beobachtungen oder einfach Rainbow Table das Salz.
2. Nimm Daves REGISTRATION_DATE aus der Datenbank oder den USER_LAST_MODIFIED_DATE
3. Nimm Daves SHA1 Hash
4. Initiieren Sie einen Brute-Force-Angriff (er wird zu einem statischen sha1-Hash, nachdem wir Ihre "Sicherheit" verletzt haben) mit den folgenden Parametern:
   • "Benutzername" + "RegistrationDate" + YourRandomNumber + DictionaryAttack[‹
ol>

Und das ist die Geschichte, warum Sie Ihre eigene Kryptographie nicht rollen sollten, es sei denn, Sie wissen wirklich, was Sie tun. Stellen Sie sich vor, ich wäre ein echter Cracker. und nicht so jemand, der gerade Ihren Code rückwärts durchgesehen hat.