Frage:
Ist es besser, einen ungeeigneten Hashing-Algorithmus zu verwenden, als überhaupt keinen?
JFB
2018-11-19 21:16:42 UTC
view on stackexchange narkive permalink

Ich muss Kennwörter auf einem System speichern, das keinen der für das Hashing von Kennwörtern empfohlenen Algorithmen bietet (z. B. bcrypt, scrypt oder PBKDF2). Wäre es besser, einen ungeeigneten Algorithmus (z. B. SHA-1 oder SHA-2-Familie) zu verwenden, bevor Sie keinen verwenden?


Zusätzliche Informationen : Ich werde der einzige sein Speichern von Passwörtern auf diesem System, damit ich 1) garantieren kann, dass keines der Passwörter zweimal verwendet wird, und 2) sicherstellen kann, dass die Passwörter eine sehr hohe Entropie haben.

Sie generieren also die Passwörter und verwalten sie?Sie sind keine Benutzerkennwörter?Existiert der Authentifizierungsmechanismus bereits oder ist dies eine neue Funktion?
Haben Sie die Möglichkeit, den Algorithmus zu * dehnen * - um denselben Algorithmus viele Male anzuwenden?Wenn ja, machen Sie das mindestens.
Es scheint, als hätten Sie ein hohes Maß an Kontrolle über die zu speichernden Passwörter. Haben Sie nicht ein ähnliches Maß an Kontrolle darüber, wie sie gespeichert werden?Können Sie sich nicht entscheiden, etwas Besseres zu finden?
Ich bin verwirrt.Wie können Sie beim Hinzufügen des Authentifizierungscodes keine Bibliothek abrufen, die neuere Hashing-Protokolle implementiert?Ich frage mich auch, ob Sie so etwas wie einen Administrator zu einem Gerät hinzufügen, das es dann verteilt hat.Ich denke, diese Frage ist nicht detailliert genug, um wirklich beantwortet zu werden.Bitte geben Sie weitere Details dazu an, was Sie implementieren, das das Kennwort enthält (eine Weboberfläche, ein IoT-Gerät usw.) und warum Sie etwas sperren müssen.(Wenn Sie ein Gerät verteilen, macht es keinen Sinn, auch nur das Passwort zu haben.)
Nein, das ist ein falsches Sicherheitsgefühl, das noch schlimmer ist. Zum Glück gibt es Verschlüsselungsdienste, mit denen Sie eine Schnittstelle herstellen können. Hier ist einer: https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
Wenn Sie wirklich keinen der Algorithmen verwenden können, die Sie verwenden sollten (bcrypt, scrypt, et al.), Verwenden Sie zumindest Salt- und Key-Stretching mit einer großen Anzahl (Zehntausende) von Iterationen.Aber im Ernst, Sie sollten einen Weg finden, einen geeigneten Algorithmus zu verwenden.SHA-1 wurde theoretisch aufgrund einer entfernten Wahrscheinlichkeit von Kollisionen gebrochen.In der Praxis ist es wahrscheinlich nicht kaputt, da Kollisionen äußerst unwahrscheinlich sind.Wenn Sie jedoch so etwas tun möchten, verwenden Sie stattdessen SHA-256 oder SHA-512.
@RandomUs1r Sie können solche Online-Verschlüsselungsdienste nur verwenden, wenn Sie sicher sind, dass Ihr System bei jeder Verwendung online ist.Dies wurde nicht angegeben, kann jedoch möglicherweise nicht garantiert werden.
Verwenden Sie einen leichtgewichtigen Docker-Container, um alle erforderlichen Bibliotheken zu installieren, und verwenden Sie dann den Container zum Hashing.
Warum erwähnen Sie, dass die pw's einzigartig sind?Das sollte überhaupt nicht relevant sein.
Außerdem ist die Sicherstellung der Eindeutigkeit des Kennworts eher ein Fehler als eine Sicherheit (wenn überhaupt): Sie müssen einem Benutzer, der versucht, ein vorhandenes Kennwort wiederzuverwenden, anzeigen, dass es nicht verwendet werden kann, und ihm daher den Hinweis geben, dass dieses Kennwort vorhanden istbereits in Ihrer Datenbank (oder zumindest ist diese Schlussfolgerung leicht zu finden)
Wir entwickeln Software, die bestimmten Einschränkungen entspricht.Sie haben zwei konkurrierende Einschränkungen: Sicherheit für Ihre Benutzer und Technologieumgebung, die keine Kennwörter hashen kann.Lösung: Ändern Sie Ihre Einschränkungen.Was schätzen Sie mehr, um die Passwörter der Benutzer zu schützen oder um an einer bestimmten Technologie festzuhalten?
Die "Zusatzinformationen" werfen weitere Fragen auf.Das Speichern von Hashes stellt nicht sicher, dass die Kennwörter eine hohe Entropie aufweisen. Wenn Ihr System verschiedenen Benutzern verbietet, dasselbe Kennwort zu verwenden ("keines der Kennwörter wird zweimal verwendet"), ist dies eine schreckliche Idee.Sie haben einem Angreifer ein Orakel gegeben, das ihm mitteilen kann, ob auf dem System bereits ein Kennwort verwendet wird.Mach das nicht!
Um meinen obigen Kommentar anders auszudrücken: Sie haben Ihr Bedrohungsmodell nicht angegeben.Es liegt zwischen extrem schwierig und unmöglich, eine Sicherheitsmaßnahme zu bewerten, ohne zu verstehen, gegen welche Bedrohung sie sich verteidigen soll.Ihre Daten stimmen nicht wirklich mit Standardfällen überein, wenn Sie überhaupt Konten benötigen, damit wir fundierte Vermutungen über die Bedrohungen anstellen können, an die Sie denken.Das Ergebnis ist, dass Sie Antworten unter der Annahme erhalten, dass der typische Anwendungsfall "Endbenutzer erstellt ein Konto und verfügt über einige Ressourcen, die geschützt werden müssen".
@LaurentS.Wenn das Passwort nicht verwendet werden kann, besteht kein Risiko, es zu kennen.Das Wissen darüber verringert den Angriffsraum ein wenig, aber da Sie bereits einige Arbeiten durchführen mussten, um dies festzustellen, scheint es für den Angreifer keinen Nettogewinn zu geben.
@LaurentS: Sie haben dem Angreifer nicht nur ein Orakel gegeben, indem Sie die Eindeutigkeit des Passworts sichergestellt haben, indem Sie dem Angreifer im Wesentlichen mitteilen, dass Sie Ihr Passwort nicht korrekt speichern.Bei ordnungsgemäßem Kennwort-Hashing sollte es unmöglich sein, festzustellen, ob zwei Konten dasselbe Kennwort verwenden.Das ist fast wie eine Einladung, mehr zu untersuchen.
@LieRyan: in der Tat.Das ist wahrscheinlich der Grund, warum ich unter den vielen Fehlern, die ich bisher gesehen habe, noch nie auf ein solches Merkmal gestoßen bin.
Ist es besser, die Tür Ihres Hauses mit einem Klebeband zu schließen, als sie beim Verlassen offen zu lassen (wenn Sie kein Schloss haben)?
Zwölf antworten:
dFrancisco
2018-11-19 21:22:01 UTC
view on stackexchange narkive permalink

Die eigentliche Antwort auf Ihre Frage lautet: Speichern Sie die Kennwörter einfach nicht dort, wenn Sie sie nicht ordnungsgemäß schützen können.

"Das System unterstützt keine ordnungsgemäßen Kennwort-Hashing-Algorithmen" ist keine gültige Entschuldigung, um die zu gefährden Sicherheit Ihrer Benutzer. Finden Sie entweder einen Weg, um Passwörter mithilfe eines starken und richtig konfigurierten Algorithmus richtig zu hashen, oder speichern Sie sie nicht.

Um jedoch eine direkte Antwort auf Ihre Frage zu geben: Ja, etwas ist besser als nichts. SHA-1 oder SHA-2 ist definitiv eine Verbesserung gegenüber Klartext.

Um die Frage zu beantworten: "Wohin sollen dann die Passwörter gehen?" Frage - Aufgrund der Formulierung gehe ich davon aus, dass es eine neue Funktion / Anforderung für die Software gibt, bei der das System Kennwörter speichern muss.

Wenn das System Passwörter (nach modernen Sicherheitsstandards) nicht ordnungsgemäß und sicher speichern kann, würde ich die Anfrage (persönlich) ablehnen. Das absichtliche Üben einer schlechten Sicherheit aufgrund von Systembeschränkungen oder das Beruhigen eines Geschäftsanwendungsfalls ist eine schlechte Sicherheitspraxis. Ich würde denjenigen, der die Anfrage gestellt hat, darüber informieren, dass ich zwei praktikable Optionen habe:

  1. Wir müssen das System vollständig auf ein System umstellen, das moderne Sicherheitspraktiken unterstützt (z. B. ordnungsgemäßes Hashing von kryptografischen Passwörtern).

  2. Ich kann die neue Funktion / Anforderung einfach nicht zum vorhandenen System hinzufügen, da dies die Sicherheit beeinträchtigen würde.

  3. ol>
Ich habe meine Frage mit zusätzlichen Informationen aktualisiert. Hilft das?
@JFB Nicht übermäßig.Die zusätzlichen Informationen sind gut und bedeuten, dass der Schaden, der durch das Kompromittieren von schwach gehashten, starken und nie wiederverwendeten Passwörtern verursacht wird, offensichtlich weniger schädlich ist als das Kompromittieren von echten normalen Benutzerpasswörtern, aber nicht dazu beiträgt, meine Antwort zu sehr zu fokussieren.
Was ist, wenn mein Chef möchte, dass das System tatsächlich Passwörter erinnert und nicht nur zurücksetzt?Sie wollen es so sehr, dass sie bereit sind, die Sicherheit dafür zu opfern.Wie würden Sie auf eine solche Anfrage antworten?
@Gherman Wie bei allem anderen führen Sie eine Kosten-Nutzen-Analyse durch und lassen den Entscheidungsträger und den Risikoverantwortlichen entscheiden.
@dFrancisco, das sich weigert, eine neue Funktion hinzuzufügen, ist in Ordnung, wenn Sie der Systembesitzer sind, aber Sie haben keine Grundlage, sich zu weigern, wenn Sie der Administrator oder der Entwickler sind.*** Beraten und schulen *** ist Ihre Rolle als Sicherheitsexperte.
Es wäre besser, Ihre Ablehnung in * geschäftlichen Begriffen * umzuformulieren, als nur die vage "Sicherheit".Beispiel: "Wir würden wissentlich vertrauliche Daten so speichern, dass ein Angreifer sie leichter erhalten kann. Dies kann eine Verletzung von GDRP / HIPPA / eines relevanten Standards sein, den das Unternehmen möglicherweise erhältÄrger machen und uns für rechtliche Konsequenzen öffnen. "Dies ist jedoch die richtige Vorgehensweise für die allgemeine Benutzerverwaltung.
@Wildcard lasst uns nicht verrückt werden mit den logischen Sprüngen, den "rutschigen Hängen" und der Ad-Absurdum.Es gibt ein großes Spielfeld zwischen "nicht ablehnen" und "sollte die Funktion hinzufügen".Bitte nehmen Sie weitere Kommentare zum Chat.
Während ein schwacher Hash etwas besser als nichts ist, ist ein * gesalzener * schwacher Hash deutlich besser als nichts.Nichts in der Frage oder dieser Antwort bezieht sich auf das Salzen, daher ist es wahrscheinlich eine gute Idee, dies ausdrücklich zu erwähnen.
"etwas ist besser als nichts" ist nur wahr, wenn das etwas BESSER als nichts ist (und nicht die Implikation preisgibt, dass es effektiver ist) - zum Beispiel ungesalzenes MD5 oder ROT13 oder was auch immer.
@Joe Ich gebe Ihnen ROT13, aber ungesalzenes MD5 * ist * besser als nichts, und gesalzenes MD5 ist dramatisch besser als ungesalzenes SHA3.
@MartinBonner Wenn es überhaupt besser ist, ist es so trivial "besser", dass wir den Unterschied vernachlässigen können (und sollten, um irreführende Menschen zu vermeiden).
Mike Ounsworth
2018-11-19 21:28:28 UTC
view on stackexchange narkive permalink

Ja, ein schwacher kryptografischer Hash ist besser als kein Hash.

Die Gründe für das Hashing Ihrer Passwörter sind für den Fall, dass Ihre Passwort-Datenbank gestohlen wird:

  1. Verhindern Sie, dass der Angreifer die Klartextkennwörter trivial erhält.
  2. Verhindern Sie, dass der Angreifer weiß, welche Benutzer dasselbe Kennwort haben (dies wird erreicht, indem jedem Benutzer ein eindeutiges Salt gegeben wird.
  3. ol>

    1 ist ein Wettrüsten: Sie möchten eine größere, langsamere Hash-Funktion verwenden, damit der Angreifer mehr Strom für das Brute-Force-Hash-Cracken benötigt. Eine einzelne Iteration von SHA-1/2 ist besser als kein Hash, weil Der Angreifer muss einige Cracking-Aktionen ausführen. Eine einzelne Iteration von gesalzenem SHA-1/2 zwingt ihn, einige Crackings durchzuführen, ohne vorberechnete Verwendung verwenden zu können Regenbogentabellen Wenn Sie zu den schickeren Passwort-Hashes (argon2, bcrypt oder der ältere scrypt, pbkdf2) mit einem höheren Arbeitsfaktor aufsteigen, werden die Stromkosten des Risses noch weiter steigen.

    Verwenden jede gesalzene Kryptog Raphischer Hash (auch solche, die für Passwörter wie SHA-1, SHA-2 nicht empfohlen werden) bietet die Vorteile von 2.


    PBKDF2 ist im Kern nur iteriertes und gesalzenes SHA-1 / 2, also würde ich ein bisschen nach PBKDF2-Implementierungen googeln und Ihren Wrapper um SHA-1/2 bauen, der es emuliert (oder besser, gehen Sie den ganzen Weg und implementieren Sie PBKDF2 tatsächlich).

Ich würde vorschlagen, Argon2 in Ihre Liste aufzunehmen, da dies derzeit der bevorzugte Algorithmus ist, wenn GPUs oder FPGA / ASIC-Cracking in Ihrem Bedrohungsmodell enthalten sind (was sie sein sollten).
+1.Beachten Sie, dass dies tatsächlich davon abhängt, wie lange Ihre Benutzerbasis bereit ist, auf die Authentifizierung zu warten (und wie viel Last Ihre Authentifizierungssysteme parallel aufnehmen können).Bei der Marke unter 100 ms ist bcrypt tatsächlich widerstandsfähiger gegen Bruteforce.Nur über ~ 1s / auth wird Argon2 überlegen.Refs: https://twitter.com/Sc00bzT/status/1063895918246862848, https://twitter.com/Sc00bzT/status/1041875128311840768
Ist das wirklich?Sie sagen mir, dass Sie meine Daten sicher speichern, ich gebe Ihnen vertrauliche Daten zum Speichern, Sie verlieren dann die Daten, weil sie nicht wirklich sicher sind. Wäre es nicht besser, im Voraus zu sein und anzugeben, dass Sie die Daten nicht sicher im Internet speichernerster Platz?... idealistisch gesehen
SHA-1 ist noch nicht gegen Preimage verletzt.Es wird halten.
@RandomUs1r Was meinst du mit "nicht sicheres Speichern der Daten"?PBKDF2 ist zwar etwas alt, gilt aber dennoch als sicher, wenn Sie 10.000 Iterationen von SHA-1 oder SHA-2 und eindeutige Salze pro Benutzer verwenden.Wenn Sie ein SHA-2-Grundelement zur Verfügung haben, können Sie PBKDF2 (oder etwas, das funktional äquivalent ist) erstellen.Bitte stützen Sie Ihre Aussage, dass dies nur eine Illusion von Sicherheit ist.
"Die Verwendung eines kryptografischen Hash bietet die Vorteile von 2."Ich nehme an, es sollte selbstverständlich sein, aber es könnte sich lohnen, nach "any" "gesalzen" hinzuzufügen.
Ich bin mit den Details der PBKDF2-Implementierung nicht vertraut.Wenn Sie jedoch eine solide Implementierung des zugrunde liegenden Hashing-Algorithmus wie SHA-1 oder SHA-2 haben, ist es akzeptabel, PBKDF2 selbst zu implementieren, wenn die Entwickler keine Krypto-Experten sind?
@JFB Ich denke schon, aber ich würde es nicht dem neuen Mitarbeiter geben.Ein Blick auf die PBKDF2-Spezifikation oder eine Open-Source-Implementierung und ein gewisses Maß an Liebe zum Detail würden den Trick tun.Anders ausgedrückt: Ich würde mir darauf verlassen, dass ich in ein oder zwei Tagen etwas PBKDF2-ähnliches implementiere und es in prod verwende.Ich würde mir unter keinen Umständen trauen, SHA-2 in weniger als einem Monat zu implementieren.
Royce Williams
2018-11-19 21:45:45 UTC
view on stackexchange narkive permalink

Versuchen Sie, wie andere bereits gesagt haben, nach Möglichkeit eine starke eigenständige Implementierung in der Sprache Ihrer Plattform zu finden.

Wenn Sie jedoch keinen starken Hash verwenden können, sollten Sie Auf jeden Fall hasht die Passwörter Ihrer Benutzer auch mit einem schwachen Hash immer noch - denn selbst ein schwacher Hash schützt ein starkes Passwort .

Wenn Tools wie hashcat Milliarden von Passwörtern pro Sekunde , schwache Hashes schützen schwache Passwörter nicht. Aber wenn einer Ihrer sicherheitsbewussten Benutzer ein nicht knackbares Passwort wie "SDXBZsRVBKVnXznpLTBMIKhTX" oder "afferent-imitiert-Schneeschmelze-Heirdom-Blutegel" wählt ... dann wird selbst ein schwacher Hash wie SHA1 dieses Passwort immer noch außerhalb der Reichweite einer Bruteforce platzieren Angriff.

Indem Sie selbst einen schwachen Hash verwenden, können Sie Ihren versierten Benutzern zumindest ermöglichen, sich selbst zu schützen, obwohl Ihr System schwach ist. (Und wenn Sie die Möglichkeit haben, zu strecken - denselben Algorithmus tausende Male hintereinander zu verwenden - wird dies auch den Angreifer verlangsamen.)

Aber Ihre versierten Benutzer Passwörter werden nicht wiederverwendet, daher ist auch dies von begrenztem Wert (mit Ausnahme von "halb versierten" Benutzern, die Passwörter ausgewählt haben, die stark genug sind, um Bruteforce zu widerstehen, dieses Passwort jedoch möglicherweise an anderer Stelle wiederverwenden oder ein vom Menschen analysierbares Passwortauswahlschema verwenden. .. also auch die Verwendung eines schwachen Hash schützt diese Benutzer).

Ihre beste Option für alle Benutzer besteht darin, einen Weg zu finden, einen starken Hash zu verwenden.

[Bearbeiten: Das OP hat die Frage aktualisiert, um anzuzeigen, dass sie der einzige Benutzer des Systems sind und ein willkürlich zufälliges Passwort festlegen können (was mir ziemlich seltsam erscheint; ich nicht Ich kenne ein System mit einer so seltsamen Kombination aus "Ich bin der einzige Benutzer", "Ich kann nur aus wenigen Hashing-Algorithmen auswählen" und "Alle Hashing-Algorithmen sind schwach". In beiden Fällen ist meine Sorge um den Schutz der schwachen Passwörter der allgemeinen Benutzer für diese spezielle Frage irrelevant. Andere Antworten sollten zu Beginn ihrer Antworten klarstellen, dass sie Ratschläge geben, die normalerweise ziemlich schlecht sind und nur für diese sehr spezifische Frage gelten.]

[Bearbeiten 2: Beachten Sie, dass "schwacher Hash" ist nicht dasselbe wie "schlechter Hash". Ein Beispiel für einen fehlerhaften Hash wäre die Entschlüsselung (da Kennwörter mit 8 Zeichen abgeschnitten werden). Selbst wenn Ihr Passwort sicher ist, kann ein 8-stelliger Entschlüsselungs-Hash innerhalb von 10 Tagen oder weniger auf einem Prosumer-Cracking-System (6 GPUs) brutal erzwungen werden.]

Ich habe meine Frage mit zusätzlichen Informationen aktualisiert, die Ihren Standpunkt ansprechen, zumindest sichere, eindeutige Passwörter schützen zu können
* Wiederverwendung von Passwörtern * ist, wenn Benutzer dasselbe Passwort auf mehreren Websites (Facebook, ihre Bank usw.) verwenden ... nicht, wenn zwei Benutzer dasselbe Passwort auf derselben * Website * verwenden.
Ich bin damit einverstanden, aber mit dem zusätzlichen Vorbehalt, dass Sie SHA-1 NICHT verwenden sollten, um eine Zusammenfassung sensibler Daten (wie Passwörter) zu erstellen, ohne zufälliges Salz zu verwenden, um die Wiederverwendung von Passwörtern sowie das Strecken von Schlüsseln zu adressieren.
Upvote für "Selbst ein schwacher Hash schützt ein starkes Passwort"
John Adams
2018-11-20 10:27:03 UTC
view on stackexchange narkive permalink

SHA-2 ist in diesem speziellen Fall genauso sicher wie PBKDF / scrypt / bcrypt. Iterationen sind unnötig und verschwenderisch. Generieren Sie Kennwörter mit hoher Entropie (256 Bit) und vergessen Sie KDFs und sogar Salze.

Tatsächlich ist die Verwendung von SHA-2 sinnvoller als die Verwendung von PBKDF, da keine Plattformimplementierung von vorhanden ist Der Algorithmus und "Rolling your own crypto" ist ein Nein-Nein.

Das ist eine ziemlich starke Aussage. Das Wesentliche hier in der Frage ist, dass das OP die volle Kontrolle über die Passwörter hat, die er auf dem System speichert, und weiß, dass er der einzige ist, der Passwörter auf dem System speichert.

Signal verwendet in seinem Doppelratschenalgorithmus eine Konstruktion namens HKDF, die den Hashing-Algorithmus im Wesentlichen nur für eine Iteration anwendet.

Warum ist das in Ordnung?

Passwort KDFs existieren aus genau einem Grund: Passwörter mit niedriger Entropie. Die meisten Menschen werden sich nicht an einen 128- oder 256-Bit-Schlüssel erinnern, der aus einem CSRNG in ihren Köpfen generiert wurde. Ich gehe davon aus, dass sich die meisten Leute lange genug an eine 40-Bit-Zufallszeichenfolge erinnern können, um sie zu verwenden.

So ziemlich alle Hash-Funktionen (sogar MD4, MD5 und SHA-1) Da Sie jedoch angegeben haben, dass Sie SHA-2 auf der Plattform haben, sollten Sie hier auf Nummer sicher gehen. Sie verfügen über eine Funktion namens Preimage Resistance, die für Ihre Anwendung ausreichend ist, da Sie alle gespeicherten Kennwörter steuern auf Ihrem System. Dies bedeutet, dass es bei einem Hash rechnerisch nicht möglich ist, etwas zu generieren, das mit demselben Hash hasht.

Um ein bisschen zu vereinfachen, ist es am praktischsten, ein Vorbild für eine dieser Hash-Funktionen zu generieren, es zu behalten versuchen Eingaben. Es gibt einige Beispiele für Angriffe, die etwas besser als Brute Force sind, aber völlig unmöglich. Wenn das Kennwort / der Schlüssel, das Sie in die Hash-Funktion eingegeben haben, nur 16 Bit Entropie enthält, kann diese Widerstandseigenschaft nicht viel bewirken, da der Angreifer alle 65536 verschiedenen Eingaben ausprobieren kann, die Sie hätten eingeben können.

Warum die Kontrolle über das Passwort wichtig ist

Denken Sie weniger an die Dinge, die Sie als "Passwörter" eingeben, als vielmehr an kryptografische Schlüssel. Solange Sie Hashing-Schlüssel verwenden, deren Entropie größer oder gleich der Anzahl der von Ihrer Wahl der Hash-Funktion ausgegebenen Bits ist (für SHA-256 sind das 256 Bits), können Sie nur eine Iteration des Hash ausführen darüber, um das Herausziehen von Schlüsseln zu verhindern. Der Vorbildwiderstand des Hash in Kombination mit der hohen Entropie Ihres Schlüssels bedeutet, dass ein Angreifer den von Ihnen eingegebenen Wert einfach nicht erraten kann. Es ist nicht erforderlich, Tausende von Iterationen durchzuführen oder mit der Geschäftsseite zu streiten oder über einen abstrakten Angriff nachzudenken, um dies nicht zu tun -so-empfängliche Chefs. Der FPGA / ASIC-Widerstand ist ein strittiger Punkt, wenn Sie eine 256-Bit-Eingabe in die Hash-Funktion erraten müssen.

Empfehlungen

Generieren Sie Ihre "Passwörter" mit einem Hardware-RNG oder einem CSPRNG und zerstören Sie umgehend jegliches Seed-Material, das zur Wiederherstellung eines internen Zustands und damit der Passwörter verwendet werden könnte. Stellen Sie sicher, dass diese 256 Bit lang sind. Wenn Ihr System keine nicht alphanumerischen oder nicht ASCII-Kennwörter unterstützt, codieren Sie nach nach dem Generieren der 256 Bits diese in Base-64 oder Base-26 oder binär, wenn Sie möchten. (Dies bedeutet, dass die tatsächlich von Ihnen übermittelten Kennwörter länger als 32 Byte sind, dies hilft jedoch nicht viel bei der Entropie.)

Behandeln Sie diese Kennwörter wie kryptografische Schlüssel - im Idealfall werden sie auf Hardware gespeichert Token. Ein Hardware-Passwort-Manager funktioniert für diesen Zweck sehr gut. Speichern Sie die SHA-256-Hashes in Ihrem System und überprüfen Sie die Kennwörter durch Hashing und Vergleichen. Sie sollten alle versuchten Kennwörter ablehnen, die nicht Ihrem Generierungskriterium entsprechen (ein Beispiel wäre ein vom Benutzer ausgewähltes Kennwort < 256 Bit), auch wenn die Hashes übereinstimmen, und Sie sollten niemandem erlauben, ein Kennwort festzulegen, das nicht von a stammt CSRNG. Das sollte sein dokumentiert. Noch besser ist es, wenn Sie am Ende der von Ihnen generierten Kennwörter ein unklares Prüfsummenbyte hinzufügen, das von der Plattform überprüft wird, bevor Sie das Kennwort festlegen können. Dies sollte alle außer den amüsantesten inkompetenten Personen davon abhalten, weniger als einen kryptografischen Schlüssel auf Ihrer Plattform zu platzieren.

Kryptografie mit öffentlichen Schlüsseln

Ihr Anwendungsfall ist ein bisschen merkwürdig. Die meisten Orte verwalten Kennwörter, da das Einrichten einer PKI und der Umgang mit Endbenutzern sehr schwierig ist, insbesondere bei öffentlichen Schlüsseln. Da Sie anscheinend der einzige sind, der Kennwörter in das System eingibt, ist es möglicherweise sinnvoller, öffentliche Ed25519- oder ECDSA-Schlüssel im System zu speichern und dort Code zu schreiben, der ein Challenge-Response-Protokoll implementiert (ein einfaches ist das Signieren dieses 256-). Bitwert - aber seien Sie vorsichtig, dass Sie diese Schlüssel nicht wiederverwenden, da Sie jemand dazu verleiten könnte, Ihr Bitcoin oder ein kriminelles Geständnis zu unterschreiben. Das Gerät, das hier mit Ihrem System verbunden ist und die privaten Schlüssel verwaltet, verfügt wahrscheinlich über eine starke Implementierung der Kryptografie mit öffentlichen Schlüsseln und kann sich problemlos authentifizieren. Ihre "Roll my own" -Implementierung der Signaturüberprüfung könnte in Bezug auf Seitenkanalangriffe (denken Sie daran, den gesamten Status auf eine Werbetafel oder die Blockchain zu setzen) die am wenigsten sichere der Welt sein, solange sie die richtige Antwort liefert. und Sie wären vollkommen in Ordnung, da der Überprüfungsalgorithmus einfach keinen Zugriff auf die privaten Schlüssel hat.

Ich ... ähm ... Der größte Teil dieser Antwort scheint sich auf ** völlig ** nicht verwandte Kryptografiethemen zu beziehen und / oder stark fehlgeleitet zu sein.Der Rest ist nicht mit der tatsächlichen Funktionsweise von Kennwortspeichertechniken verbunden.Salting und Iterationen sind 100%, wie Passwörter sicher gespeichert werden.Darüber hinaus ist es * sehr * ein schlechter Rat, jemandem zu empfehlen, gerade SHA-2 zu verwenden.Mein 6x 1080-Rig kann 18,7 * Milliarden Passwörter pro Sekunde * von SHA-2 erraten, aber nur 95.000 pro Sekunde von bcrypt kosten 5 (und bcrypt kostet 12 oder höher ist das derzeitige moderne Ziel).
@RoyceWilliams Ich bin kein Sicherheitsexperte, aber wenn ich OP richtig verstehe, befürworten sie, dass Benutzer nicht weniger als 256 Bit Entropie für Passwörter eingeben.Selbst bei Ihren 18,7 Milliarden Versuchen pro Sekunde würden Sie immer noch 1,963 * e + 59 benötigen, wenn meine Serviettenmathematik korrekt ist (`(2 ^ 256) / 18.700.000.000 / 60/60/24/365`)Jahre, um alle Kombinationen auszuprobieren, die meiner Meinung nach als "rechnerisch nicht realisierbar" gelten würden, selbst wenn Sie davon ausgehen, dass hochoptimierte Hardware 100.000-mal effizienter wäre.
Mit anderen Worten, für einen Nicht-Sicherheitsexperten wie mich scheint der Antwortende insofern richtig zu sein, als jeder vorbildresistente Hashing-Algorithmus als sicher angesehen werden kann, wenn Sie nicht wiederverwendete 256-Bit-Entropie-Passwörter garantieren können.
@RoyceWilliams Ja, ich denke, das Hauptproblem ist, dass der allgemeine Vorschlag, den JohnAdams macht, etwas klarer sein könnte.Es scheint, dass er vorschlägt, überhaupt keine Passwörter zu verwenden, sondern eine schlüsselbasierte Authentifizierung zu verwenden.In diesem Fall sind weder Iterationen noch Salzstoffe vorhanden.
Einfach ausgedrückt sind sehr lange, sicher generierte Passwörter im Wesentlichen kryptografische Schlüssel.
@RoyceWilliams Sie scheinen den Kern der Antwort falsch zu verstehen.Wenn Ihre Passwörter genügend Entropie haben, ist ein KDF nicht erforderlich.KDFs werden verwendet, da die meisten Passwörter eine niedrige Entropie aufweisen.Wenn Ihre Passwörter Entropieebenen erreichen, die mit denen von kryptografischen Schlüsseln vergleichbar sind, spielt es keine Rolle, wie sie gehasht werden, solange der Hash vor dem Bild resistent ist.
All das klingt großartig. * Wenn * Sie den dramatisch seltenen Luxus haben, alle Benutzer zu zwingen, nur automatisch generierte Passwörter zu verwenden.Sobald Benutzer ihre eigenen Passwörter auswählen dürfen, sind alle vorstehenden Überlegungen irrelevant.Und eine umfassende erste allgemeine Aussage, dass ein schneller Hash so gut ist wie ein langsamer Hash, sendet genau die entgegengesetzte Botschaft von dem, was Sysadmins und Entwickler wissen sollen: * Starke Hashes schützen schwache Passwörter, und die meisten Benutzer wählen schwache Passwörter *.
Beachten Sie auch, dass ich meine Antwort gegeben habe, bevor das OP uns mitgeteilt hat, dass sie der einzige Benutzer des Systems sind.Ich habe meine Frage entsprechend aktualisiert und schlage vor, dass alle anderen Antworten bearbeitet werden, um * sehr * klar zu machen, warum dies ein ungewöhnlicher Eckfall ist. Andernfalls geben sie Ratschläge, die für 99,9% von * sehr * schlecht sindFälle ... und viele SE-Benutzer werden die Frage überfliegen, zu den Top-Antworten gehen und zu genau der entgegengesetzten Schlussfolgerung kommen, die fast jeder braucht.
Mein Problem mit dieser Antwort ist, dass sie grundsätzlich in zwei Sätzen zusammengefasst werden kann: "Verwenden Sie keine Passwörter, verwenden Sie Schlüssel. Schlüssel können nicht brutal erzwungen werden. Wenn Sie also Schlüssel verwenden, müssen Sie sich nicht so viele Gedanken über das Hashing machen.""Dies ist sicherlich ein guter Sicherheitshinweis, und er ist zu 100% wahr (Schlüssel sind sicherer und können effektiv nicht brutal erzwungen werden).Es ist jedoch sehr unwahrscheinlich, dass das OP hilfreich ist, da die Einrichtung schlüsselbasierter Anmeldungen auch einige Zeit in Anspruch nimmt, um sie für den Benutzer bequem einzurichten.
Kurz gesagt, das OP versucht, die grundlegende Sicherheit mit minimalem Aufwand zu gewährleisten, und Sie schlagen eine Antwort vor, die erstaunliche Sicherheit mit einem großen Aufwand bietet.Es gibt oft einen Kompromiss zwischen Benutzerfreundlichkeit und Sicherheit.Das OP versucht eindeutig, die Usability-Seite dieses Spektrums zu bevorzugen, und Sie schlagen eine Lösung vor, die eine hohe Sicherheit auf Kosten einer verminderten Usability bietet.Einfach ausgedrückt: Wenn er keine Zeit hat, einen geeigneten Hashing-Algorithmus einzurichten, dann bezweifle ich, dass er Zeit hat, ein hardwarebasiertes RNG zu finden.
Conor Mancone
2018-11-19 23:49:13 UTC
view on stackexchange narkive permalink

Ich stimme Mike und Royce in ihren Antworten zu und habe nicht das Bedürfnis, das zu wiederholen, was sie gut behandelt haben. Ich wollte jedoch Ihren Kommentar direkter ansprechen:

Zusätzliche Informationen: Ich bin der einzige, der Kennwörter auf diesem System speichert, sodass ich 1) garantieren kann, dass keines der Kennwörter vorhanden ist zweimal verwendet und 2) sicherstellen, dass die Passwörter eine sehr hohe Entropie haben.

Diese Information ist sowohl wichtig als auch unwichtig. Hier ist der Grund:

Der Fall von Passwort-Hashing

Es ist immer wichtig, sich daran zu erinnern, warum wir Passwörter hashen, und alles kocht bis zur Wiederverwendung des Passworts. Der Grund, warum das Hashing von Passwörtern so wichtig ist, liegt darin, dass bei einer Gefährdung Ihres Systems und einem Diebstahl von Passwörtern nicht nur der Zugriff auf Ihre Site gefährdet wird, sondern auch der Zugriff auf jede Site, auf der Ihre Benutzer dieselbe E-Mail / dasselbe Passwort erneut verwendet haben Kombination, die (wie wir wissen) viel passiert. Beim Passwort-Hashing geht es darum, Benutzer vor sich selbst zu schützen. Wenn absolut jeder auf jeder Site sichere und eindeutige Passwörter verwenden würde, wäre ein Passwort-Hashing viel weniger notwendig. Es hätte immer noch einen gewissen Wert, da es Anwendungsfälle gibt, in denen ein Hacker möglicherweise schreibgeschützten Zugriff auf einen Datenbankspeicherauszug erhält, sodass gehashte Kennwörter einen gewissen Schutz vor Angreifern bieten können, die tatsächlich Zugriff auf Ihr System erhalten Passwörter überall, dann wird das Hashing von Passwörtern eher zu einem zweitrangigen Problem als zu der absolut kritischen Notwendigkeit, die es heute ist.

Wenn Sie also garantieren können, dass jeder Benutzer Ihres Systems immer nur sichere und eindeutige Passwörter verwendet (dh Passwörter, die nicht auf anderen Websites verwendet wurden), dann denke ich, dass selbst etwas Einfaches wie SHA2 tatsächlich eine absolut vernünftige Wahl wäre, unabhängig davon, ob bessere Funktionen verfügbar waren oder nicht.

ABER: sich ändernde Geschäftsanforderungen

Ich möchte Sie jedoch dazu ermutigen, Ihre Annahmen zu überprüfen (dass starke eindeutige Kennwörter die einzigen sind, die jemals in Ihrem System verwendet wurden). Ich habe gesehen, dass sich die geschäftlichen Anforderungen in der Vergangenheit zu oft geändert haben, um sich auf solche Annahmen in kritischen Geschäftsbereichen zu stützen (was dies möglicherweise nicht ist - offensichtlich weiß ich nicht, was dies bewirkt). Das Problem ist, dass sich die geschäftlichen Anforderungen ändern müssen. Vielleicht bin ich es nur, aber meiner Erfahrung nach werden Dinge, die nur vorübergehend oder auf ein paar Personen beschränkt sein sollten, unweigerlich zu kritischen Geschäftsanwendungen, die von allen im Unternehmen verwendet werden, und plötzlich haben Sie ein schwaches Passwortschema, das kritische Geschäfte schützt Infrastruktur. Es wird nicht immer passieren, weil die Leute versuchen , Abstriche zu machen, aber weil Sie 12 Monate später vergessen, dass Sie keinen großartigen Passwort-Hash verwendet haben, oder Sie gehen und der nächste Kerl es nicht tut. Wenn Sie sich das nicht ansehen, stehen Sie unter dem Druck, eine Frist einzuhalten, und Sie vergessen, oder, oder, oder ...

Nach meiner Erfahrung haben Unternehmen Sicherheitsverletzungen, nicht weil Sicherheit ist schwer , aber weil sie nicht verstehen, wie wichtig es ist, Zeit (auch bekannt als Geld) für gute Sicherheitspraktiken aufzuwenden und Abstriche zu machen, wo sie nicht sollten. Sicher, im Moment spielt ein großartiges Passwort-Hashing-Schema keine Rolle, aber können Sie wirklich garantieren, dass sich dies in Zukunft nicht ändern wird? Wenn Sie jetzt keine Zeit haben, das richtige Passwort-Hashing einzugeben, können Sie dann garantieren, dass Sie Zeit haben, dies zu tun, wenn sich die Anforderungen ändern und es plötzlich wichtig ist?

Natürlich muss am Ende des Tages jedes Unternehmen Geld verdienen, und manchmal ist "Lassen Sie uns dies vorerst einfach halten, um dies aus der Tür zu bekommen" eine völlig vernünftige Antwort. Seien Sie jedoch vorsichtig, denn wenn Sie diese Entscheidung zu oft treffen, erhalten Unternehmen Systeme mit Sicherheitslücken. Als Unternehmen müssen Sie dieses Gleichgewicht für sich selbst finden. Das Problem ist, dass Unternehmen, die chronisch an der Sicherheit sparen, letztendlich am meisten von ihren Kunden betroffen sind.

+1 für "Dinge, die nur vorübergehend oder auf wenige Personen beschränkt sein sollten, werden unweigerlich zu kritischen Geschäftsanwendungen"
Luis Casillas
2018-11-20 07:15:06 UTC
view on stackexchange narkive permalink

Ich muss Kennwörter auf einem System speichern, das keinen der für das Hashing von Kennwörtern empfohlenen Algorithmen bietet (z. B. bcrypt, scrypt oder PBKDF2). Wäre es besser, einen ungeeigneten Algorithmus (z. B. SHA-1 oder SHA-2-Familie) zu verwenden, bevor Sie keinen verwenden?

Die strikte Antwort auf Ihre Frage lautet Ja. Der Grund dafür ist, dass schnelle Hashes schwache Passwörter nicht schützen, aber sehr starke, und das ist strikt besser als Klartext.

Wenn Sie jedoch SHA-1 oder SHA-2 haben, gibt es solche Es gibt nur sehr wenige (wenn überhaupt!) Ausreden, PBKDF2 nicht zu verwenden. Ja, der allgemeine Rat lautet: "Rollen Sie keine eigene Krypto", aber wenn Sie SHA-1 oder SHA-2 haben, ist dies bereits der Schlüsselbaustein für PBKDF2 und für den Fall, dass Sie ein Passwort-Hashing schreiben Die eigene Implementierung von PBKDF2 kann kaum schlechter sein als nicht . Hier ist der relevante RFC und Abschnitt:

Wenn sie "Pseudozufallsfunktion" sagen, sollten Sie eine HMAC-Variante verwenden (idealerweise HMAC-SHA-512, aber jede von ihnen reicht aus). Ihre Bibliothek verfügt wahrscheinlich bereits über HMAC-Implementierungen. Wenn dies nicht der Fall ist, ist das Kennwort-Hashing erneut ein Fall, in dem die Implementierung Ihrer eigenen Bibliothek nicht schlechter sein kann als nicht.

AMADANON Inc.
2018-11-20 03:25:05 UTC
view on stackexchange narkive permalink

Um Ihre Frage zu beantworten: Ja, verwenden Sie den besten Algorithmus, auf den Sie Zugriff haben. Wenn Sie mehrere haben, können Sie diese kombinieren (Hinweis: Die Verkettung von Passwörtern, z. B. sha1 (Passwort) + md5sum (Passwort), ist anfälliger für Vermutungen, da ein Angreifer auswählen kann, welchen Hash er erraten möchte, Kollisionen jedoch viel geringer sind wahrscheinlich, da beide Passwörter übereinstimmen müssen. Verwenden Sie für jedes Passwort ein zufälliges, unterschiedliches Salz.

Sie sagen, Ihr System bietet "keinen der für das Hashing von Passwörtern empfohlenen Algorithmen". Ich würde Ermutigen Sie Sie, diese Annahme erneut zu überprüfen.

Fast jede moderne Programmiersprache verfügt über Implementierungen sicherer Hashes. Sie müssen diese nicht unbedingt in einer vorgefertigten, vorinstallierten Bibliothek implementieren - zum Beispiel Wenn Ihr Programm in C geschrieben ist, sollten Sie in der Lage sein, Implementierungen von Hash in C als eigenständige Funktion zu finden. Selbst winzige Prozessoren wie Arduino verfügen über bcrypt und PBKDF2 von der Stange. Der zusätzliche Arbeitsaufwand ist minimal könnte es sogar selbst implementieren (aber seien Sie sehr vorsichtig und testen Sie es sehr gründlich!).

Ich bezweifle nicht, dass es Ausnahmen gibt, aber es gibt nicht viele.

Matija Nalis
2018-11-20 03:07:26 UTC
view on stackexchange narkive permalink

JA, selbst Hash von geringer Qualität ist viel besser als das Speichern von Passwörtern im Klartext.

Wenn ich verstehe, dass Sie aktualisieren, führt jemand anderes die Authentifizierung durch (unabhängig davon) Sie und Ihre Datenbank), und Sie werden Ihre Passwort-Hash-Datenbank nur zur Erkennung doppelter Passwörter verwenden? Die Anforderung zur Bestimmung der Kennwortentropie basiert auf Klartext und hat nichts mit dem Speichern von Kennwort-Hashes zu tun, oder?

Dann können Sie nur einen kleinen Teil des berechneten in Ihrer Hash-Datenbank speichern sha2 Hash von salt + Klartext (zum Beispiel nur niedrige 8 Bytes von 32 Bytes speichern, die von sha256 zurückgegeben werden), was ausreicht, um Duplikate mit zu erkennen Keine Fehlalarme im wirklichen Leben, aber immer noch nicht genug, um es dem Angreifer zu ermöglichen, Regenbogentabellen zu verwenden, um das ursprüngliche Passwort zu erraten, falls Ihre Datenbank gestohlen wird.

(Haftungsausschluss: Wenn Sie eine Authentifizierung durchführen und nicht nur ein doppeltes Kennwort erkennen, wäre es offensichtlich eine schreckliche Idee, einen Teil des Hashs zu löschen!)

Lithilion
2018-11-20 14:19:29 UTC
view on stackexchange narkive permalink

Ja Die Verwendung eines schwachen Hashs ist besser als keine.

Ich denke, Sie sollten auch die administrative Vorgehensweise berücksichtigen. Wenn Sie die Datenbank pflegen (aber die Struktur nicht ändern dürfen, wer weiß warum ...), sollten Sie keine Nur-Text-Passwörter sehen, selbst wenn Sie die ganzzahligste Person sind und diesen Informationen keinen Schaden zufügen würden. Genau wie das Sprichwort: Gelegenheit macht den Dieb.

Damon
2018-11-20 15:05:32 UTC
view on stackexchange narkive permalink

Ja, es ist definitiv besser, einen einfachen Hash als keinen zu verwenden (obwohl ich sehe, wie Sie das System anscheinend implementieren , sehe ich nicht, was Sie daran hindert, die Dinge richtig zu machen).

Angesichts Ihrer Bearbeitung "Zusätzliche Informationen" könnte man jedoch so kühn sagen, dass Sie nicht einmal Salz benötigen! Das bedeutet nicht, dass es ein gutes Design ist, und das würde ich nicht empfehlen, aber wenn Sie Ihre Garantien ernst nehmen, reicht genau genommen ein einfacher sicherer Hash von angemessener Größe aus.

Warum macht man das? so viel Aufhebens um das Speichern von Passwörtern? Normalerweise haben Passwörter eine niedrige Entropie, und selbst wenn sie gehasht werden, besteht eine gute Chance, ein Passwort zu erraten. Auch Hash-Funktionen sind sehr schnell , trivial parallelisierbar und es gibt Regenbogentabellen, die eine billige Verknüpfung bieten . Selbst wenn Sie nach dem Hashing nicht lesbar sind, bedeutet dies nicht unbedingt, dass Kennwörter nicht wiederherstellbar sind.
Im Prinzip können Sie bei unendlicher Zeit jedes Kennwort auf jedem System wiederherstellen (oder zumindest ein Kennwort, das funktioniert). Dies ist nur eine Folge der Tatsache, dass eine Hash-Funktion eine begrenzte Anzahl von Ausgaben enthält. Bei einer quasi erschöpfenden Suche muss eine Eingabesequenz notwendigerweise eine Ausgabe erzeugen, die funktioniert.
Glücklicherweise haben Angreifer keine unendliche Zeit, daher ist es unsere Aufgabe, sicherzustellen, dass sie keine haben eine vernünftige Chance, eine Eingabesequenz zu finden, die innerhalb einer begrenzten Zeit und mit einer begrenzten Energieversorgung funktioniert.

Nun ... Sie sagen, dass Sie der einzige Benutzer sind und garantieren können dass Passwörter zufällig sind und eine hohe Entropie aufweisen. Dies schließt die meisten Bedenken hinsichtlich des Ratens aus.

Bei einer "vernünftigen" Digestgröße bedeutet dies, dass die Wahrscheinlichkeit, den Hash in einer Regenbogentabelle zu finden, minimal ist (null, mehr oder weniger) und die Wahrscheinlichkeit, ihn mit roher Gewalt zu finden, gleich mehr oder weniger null ist. Es gibt keine Möglichkeit, dass jemand SHA-256 Digest Brute Force bricht, geschweige denn SHA-512. Diese Idee ist einfach nicht mit unserem Verständnis der Funktionsweise der Physik vereinbar.
Wenn der Digest groß genug ist und Passwörter garantiert (wie Sie sagen) eindeutig, zufällig und mit hoher Entropie sind ... dann sind Sie es tatsächlich Es ist einfach gut, einmal mit dem Hashing zu beginnen.

Normalerweise sollte ein System jetzt zuverlässig funktionieren, auch wenn Sie diese Garantie (oder keine Garantie) bieten können für diese Angelegenheit). Daher ist es nicht das beste Design.

Jake
2018-11-21 01:49:36 UTC
view on stackexchange narkive permalink

Ja, es sollte dir gut gehen. SHA1 und 2 sind immer noch ziemlich stark für die Speicherung von Passwort-Hashes mit hoher Entropie und bieten einen angemessenen Schutz vor Brute Forcing. SHA2 bietet einen besseren Schutz als SHA1. Die Sicherheitsanfälligkeiten in SHA2 sind für dieses Szenario nicht relevant, da sie sich auf das Erstellen von Kollisionen beziehen, bei denen der ursprüngliche Klartext bereits bekannt ist.

Das ist einfach falsch.https://www.pcworld.com/article/3173791/security/stop-using-sha1-it-s-now-completely-unsafe.html https://dusted.codes/sha-256-is-not-a-secure-password-hashing-algorithm
Auch ... https://crypto.stackexchange.com/a/35642
Es ist richtig.Der PC-World-Artikel befasst sich mit der Erzeugung einer Kollision aus bekanntem Klartext.Das sind schlechte Nachrichten für bestimmte Arten von Zertifikaten oder für die Dateiintegrität, aber gut für Passwörter.Der zweite sagt nur, dass schwache ungesalzene Passwörter leicht zu knacken sind.Dies gilt für alle Hashing-Algorithmen und ist in diesem Szenario irrelevant.Der SE-Link sagt dasselbe, was ich getan habe.Stellen Sie einfach sicher, dass der Rest des Systems korrekt implementiert ist, und verwenden Sie sichere Kennwörter.
Gregory Currie
2018-11-23 09:20:32 UTC
view on stackexchange narkive permalink

Um den oben genannten hervorragenden Antworten zu folgen, möchte ich eine kostenlose, aber gegenteilige Antwort geben:

Nein . Die Verwendung eines schwachen Hashs ist schlimmer als die Verwendung eines Hashs überhaupt nicht.

Ein schwacher Hash gibt Ihnen die Illusion von Sicherheit.

Während Sie und Ihre Manager Vielleicht verstehen Sie derzeit, dass der Hash keine echte Sicherheit bietet. Ein Manager oder Entwickler auf der ganzen Linie könnte denken, dass der Hash sicher ist. Diese Personen entscheiden sich möglicherweise dafür, zusätzliche Informationen mithilfe des betreffenden Hashs zu speichern.

Es besteht auch das Risiko, dass das Management nicht einfach versteht, dass der Hash zunächst nicht sicher ist. Wenn sie vor der Entscheidung stehen, in die Sicherheitsentwicklung zu investieren, entscheiden sie möglicherweise, dass "das aktuelle System gut genug ist", da es bereits gehasht ist und Hashing als bewährte Methode angesehen wird.



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