it-swarm-eu.dev

Ist AES die Verschlüsselung eines Passworts mit sich selbst sicherer als SHA1?

Dies ist keine praktische Frage, sondern eher eine Frage der Neugier. Ich habe gehört, dass ein CS-Professor empfohlen hat, von md5ing-Passwörtern nicht zu SHA1, sondern zu AES zu wechseln, um das Passwort mit sich selbst als Schlüssel zu verschlüsseln. Hat jemand einen Einblick, ob dies tatsächlich mehr oder weniger sicher ist?

Einige Gedanken zu diesem Thema:

  • SHA1 ist eine Einbahnstraße, die es sicherer machen sollte als eine Funktion, die die Daten bewahrt.
  • Andererseits kann der Hacker die entschlüsselbare Natur von AES unmöglich ausnutzen, da er das Passwort noch nicht kennt.
  • Es sei denn, er ahnt es. Aber dann wäre er egal, wie ich es verschlüsselt habe.
  • Da Sie wissen, dass das AES-Kennwort entschlüsselt wird, wenn der Entschlüsselungsschlüssel mit der Ausgabe übereinstimmt, kann es auf dem Computer des Hackers brutal erzwungen werden.
  • Aber der Hacker weiß nicht, wie es verschlüsselt ist, also würde er das nicht versuchen.
  • Aber der Hacker hätte auch den Verschlüsselungscode haben können. In diesem Fall ist es einfach eine Frage, welche Daten länger brauchen, um Gewalt anzuwenden.
  • Die meisten Websites verwenden md5 oder sha1 (richtig?), Daher sind Nachschlagetabellen für diese Hashes weitaus weiter verbreitet als für die AES-Methode. Dadurch wird die AES-Methode sicherer.
  • Wenn wir jedoch beide Methoden salzen, sind sie gleichermaßen immun gegen Nachschlagetabellen.

Einige häufige Punkte in den Antworten und Gegenpunkte :

Die AES-Verschlüsselung ist nicht kollisionssicher und weist daher wahrscheinlich mehr Kollisionen bei gleicher Länge der Hash-Zeichenfolge auf.

Wenn wir ein längeres Salt verwenden, ist das verschlüsselte Passwort länger als ein SHA1-Hash. Dies kann ausreichen, um die Kollisionen auf ein vergleichbares Niveau zu bringen - oder auch nicht.

Die AES-Verschlüsselung gibt an, wie lange das Kennwort innerhalb von 16 Byte gedauert hat.

Wir können die AES-Methode ergänzen: Nach dem Verschlüsseln füllen oder schneiden wir sie auf eine angemessene Länge (die länger als die von SHA1 ist, um Kollisionen zu vermeiden).

30
skier88

Kurze Antwort: schlechte Idee, tu es nicht.


Längere Antwort: Der Sinn der Übung besteht darin, etwas zu speichern, das es dem Server ermöglicht, zu überprüfen ein gegebenes Passwort, aber erlaubt es nicht, neu zu erstellen das Passwort; Die letztere Eigenschaft ist wünschenswert, damit die Folgen eines unzulässigen Lesezugriffs eines Angreifers auf die Serverdatenbank begrenzt bleiben.

Wir wollen also eine deterministische Einwegtransformation, die ein gegebenes Passwort in den Verifizierungswert umwandelt. Die Transformation soll sein:

  • konfigurierbar langsam, um Wörterbuchangriffe zu verhindern;
  • für jede Instanz unterschiedlich, um parallele Wörterbuchangriffe zu verhindern, einschließlich vorberechneter Tabellen (darum geht es bei Salzen).

Ein einzelner Aufruf von MD5 oder SHA-1 schlägt auf beiden Konten fehl, da diese Funktionen sehr schnell und nicht gesalzen sind. Langsamkeit kann durch Verschachteln vieler Anrufungen (Tausende, möglicherweise Millionen) erreicht werden, und das Salz kann "irgendwo" injiziert werden, obwohl es gute und schlechte Möglichkeiten gibt, dies zu tun. PBKDF2 ist eine Standardtransformation, die genau das tut, und sie ist nicht schlecht darin (obwohl bcrypt sollte etwas vorzuziehen sein ).

MD5 und SHA-1 machen jedoch mindestens eines richtig: Sie waren entworfen, um einseitig zu sein. Das ist schwer zu machen; Es ist nicht einmal theoretisch bewiesen, dass Einwegfunktionen überhaupt existieren können. Kryptografen auf der ganzen Welt sind derzeit an einem Wettbewerb beteiligt, um eine neue, bessere Einweg-Hash-Funktion zu entwerfen.

Ihr Professor scheint also zu empfehlen, eine Funktion, die für Einbahnstraßen ausgelegt ist, durch eine Funktion zu ersetzen, die nicht für Einbahnstraßen ausgelegt ist. Es korrigiert nichts an Langsamkeit und Salzen, aber es entfernt das einzig Gute an MD5 und SHA-1. Darüber hinaus ist bekannt, dass AES relativ schwach in Bezug auf Angriffe mit verwandten Schlüsseln ist - das ist kein Problem, solange AES für das verwendet wird, was es beabsichtigt war, dh Verschlüsselung, aber es wird wichtig Problem, wenn es in einen Baustein für eine Einweg-Hash-Funktion umgewandelt wird. Es scheint möglich zu sein, eine sichere Hash-Funktion zu erstellen, indem Teile des AES-Designs wiederverwendet werden. Dies erfordert jedoch erhebliche Nacharbeiten (siehe z. B. Whirlpool und [~ # ~] echo [~ # ~]). ).

Verwenden Sie daher kein hausgemachtes AES-basiertes Passwort-Hashing-Schema. Verwenden Sie für diese Angelegenheit nichts, was "hausgemacht" ist: Das ist ein Rezept für eine Katastrophe. Sicherheit kann nicht getestet werden; Die einzige bekannte Möglichkeit, einen sicheren Algorithmus zu erstellen, besteht darin, dass Hunderte von ausgebildeten Kryptographen ihn einige Jahre lang genau betrachten. Das kannst du nicht alleine machen. Selbst ein einsamer Kryptograf wird das nicht riskieren.

Verwenden Sie stattdessen bcrypt. PBKDF2 ist auch nicht schlecht.

32
Thomas Pornin

Die meisten Websites verwendeten md5 oder sha1 (richtig?), Also ist dies das, was ein Hacker erwarten würde. Dadurch wird die AES-Methode sicherer.

Selbst wenn die meisten Websites MD5 oder SHA1 verwenden, würde ein Wechsel zu AES nur aus dem Grund, dass es dort normalerweise nicht verwendet wird , die Sicherheit nicht erhöhen - das ist es nur Sicherheit durch Dunkelheit , was normalerweise nicht effektiv zur Erhöhung der Sicherheit beiträgt; Es ist weitaus sicherer, einen guten Algorithmus (der für den jeweiligen Zweck gut getestet wurde) zu verwenden und öffentlich zu dokumentieren, als einen Algorithmus zu verwenden, bei dem Sie nicht sicher sein können, ob er gut ist, und nicht zu sagen, dass Sie es sind es benutzen.

Im Moment kann ich mir die folgenden möglichen Nachteile vorstellen, wenn ich AES oder einen anderen Verschlüsselungsalgorithmus wie diesen verwende:

  1. Verschlüsselungsalgorithmen sind normalerweise nicht zur Vermeidung von Kollisionen ausgelegt: Wie in den Kommentaren unten ausgeführt, ist dies aufgrund des erwarteten pseudozufälligen Verhaltens der Blockverschlüsselung möglicherweise kein Problem. Trotzdem verwenden Sie einen Verschlüsselungsalgorithmus für etwas, für das er nicht entwickelt wurde.
  2. Es ist vorstellbar, dass es Angriffe auf Verschlüsselungsalgorithmen gibt, die viel einfacher durchzuführen sind, wenn man weiß, dass Klartext und Passwort tatsächlich ein und dasselbe sind (sollte die Tatsache über den Algorithmus, den Sie verwenden, irgendwie lecken, was nicht so unwahrscheinlich ist dass es zB hier besprochen wird).
  3. Verschlüsselungsalgorithmen erzeugen Daten, die in vielen Fällen mit der Länge des Klartextes variieren. Das heißt, der Chiffretext enthält Informationen darüber, wie lang das Passwort ist. Im Fall von AES ist dies ein Vielfaches von 16 Bytes, soweit ich das beurteilen kann ; Hash-Werte haben andererseits eine feste Größe (z. B. 160 Bit/20 Bytes für SHA1); Dies bedeutet, dass ein potenzieller Hacker die Chance hat, mehr Informationen aus einem verschlüsselten Text als aus einem Hashwert zu erhalten.
  4. In der Kryptografie ist es normalerweise immer weniger sicher, etwas selbst zu kochen (was später wahrscheinlich auch nur von Ihnen verwendet wird), als etwas zu verwenden, das bereits lange Zeit in der Community getestet und getestet wurde (was bedeutet, dass es Zeit hatte, gründlich überprüft zu werden) von einer Reihe von Kryptoanalytikern).
  5. Sie möchten sicherstellen, dass Ihr Passwort-Hashing-Algorithmus langsam ist, damit potenzielle Angreifer daran gehindert werden, ihren Weg in Ihr System brutal zu erzwingen. Eine Möglichkeit, dies zu erreichen, besteht beispielsweise darin, das Hashing iterativ in mehreren Runden durchzuführen, wie dies beispielsweise bei PKBDF2 der Fall ist. Weitere Informationen finden Sie unter http://security.blogoverflow.com/2013/09/about-secure-password-hashing/
17
codeling

Ein unmittelbares Problem, das ich bei diesem Ansatz sehe, ist die feste Schlüssellänge von AES. Bei Verwendung von AES-128 wäre das Kennwort auf 16 Byte beschränkt. Was ist mit längeren Passwörtern oder langen Passphrasen?

Um eine beliebige Kennwortlänge zu berücksichtigen, benötigen Sie eine Hash-Funktion, also zurück zum Anfangspunkt.

Beachten Sie, dass es gut untersuchte und sichere * Möglichkeiten gibt, eine Blockverschlüsselung in eine Hash-Funktion umzuwandeln, sogenannte PGV-Modi wie Davies-Meyer, Matyas-Meyer-Oseas oder Miyaguchi-Preneel.

(*) Für eine angemessene Definition von "sicher".

7
Krystian

Beachten Sie jedoch Folgendes:

Ich breche in Ihre Site ein und erhalte genügend Zugriff, um festzustellen, dass Sie AES-Schlüssel für Ihr System konfiguriert haben. Das einzige, was "verschlüsselt" aussieht, sind Ihre Passwörter ... raten Sie mal, was ich tun werde.

Ich würde sie gehasht halten, lässt viel weniger Raum für das einfache Scrapen Ihrer gesamten Passwortdatenbank.

Darüber hinaus möchte ich als Websitebesitzer NICHT die Möglichkeit haben, die Passwörter meiner Benutzer zu entschlüsseln, da sonst die Option zum "Wiederherstellen von Passwörtern" zu einer möglichen Funktion wird, die höhere Unternehmen und wir technisch verlangen können Dies ist möglich, da das zugrunde liegende System mithilfe eines Verschlüsselungssystems anstelle eines Hashing-Systems erstellt wird (ein lahmer Grund, aber Softwareentwickler bearbeiten Anfragen wie diese).

Hauptsächlich: Wenn es um Sicherheit geht, versuchen Sie nicht, etwas Verrücktes zu tun, und Sie werden sich wahrscheinlich eine große Sicherheitslücke schreiben, weil Sie nicht in der Lage sind, die Menge an Forschung in ein Team von Leuten zu stecken, die an einem Algorithmus arbeiten für einen bestimmten Zweck müsste.

5
StrangeWill

Die richtige Antwort lautet: Es spielt überhaupt keine Rolle.

Bei Passwörtern besteht der einzige praktische Angriff darin, eine Liste von Passwörtern auszuprobieren, bis Sie mit brutaler Gewalt das richtige finden. Niemand wird versuchen, SHA1 oder AES direkt anzugreifen, um dies zu tun. Selbst zum gegenwärtigen Zeitpunkt der Forschung wäre ein Angriff auf SHA1 zehntausendmal einfacher als ein AES, beide sind immer noch völlig unmöglich (zum Umkehren von Passwort-Hashes, da Kollisionen hier keine Rolle spielen). Und da ein Forscher einen anderen Weg findet, um den anderen Algorithmus anzugreifen, könnten sich die Chancen im nächsten Jahr umkehren.

Was wichtig sein könnte, ist, wie schnell Sie Ihren Hash ableiten/Ihr Passwort verschlüsseln. Aber wenn z.B. SHA1 ist schneller und Sie möchten, dass es langsamer ist (um Brute-Force-Angriffe abzuwehren). Sie können nur mehrmals hashen.

Was ein Hacker "erwartet", ist nicht so relevant. Etwas "Unerwartetes" zu machen, ist nur Dunkelheit. Es ist wie zu sagen "Ich kehre alle Passwortbuchstaben um, jetzt ist es sicherer". Es wird nicht sein. Wenn der Hacker auf Ihre Passwortdatenbank zugreifen kann, wie können Sie sicher sein, dass er keinen Zugriff auf Ihre Passwort-Hash-Ableitungsfunktion hat?

Ein Fehler beim "Verschlüsseln eines Passworts mit sich selbst": Die Länge des Chiffretextes kann dem Angreifer einen Hinweis auf die Länge des Passworts geben. Das ist schrecklich.

In jedem Fall sollten Sie das Passwort salzen, vorzugsweise mit etwas, das für den Benutzer einzigartig ist.

4
Kosta

Es gibt MACs (Message Authentication Codes), die aus Blockchiffren aufgebaut sind. Das bekannteste ist wahrscheinlich CBC-MAC . Es hat Probleme im Vergleich zu einem Hash-Mac, insbesondere:

Bei einer sicheren Blockverschlüsselung ist CBC-MAC für Nachrichten mit fester Länge sicher. An sich ist es jedoch nicht sicher für Nachrichten mit variabler Länge. Ein Angreifer, der die richtigen Nachrichten-Tag-Paare (d. H. CBC-MAC) (m, t) und (m ', t') kennt, kann eine dritte Nachricht m '' erzeugen, deren CBC-MAC ebenfalls t 'ist.

[...]

Dieses Problem kann nicht durch Hinzufügen eines Blocks mit Nachrichtengröße (z. B. mit Merkle-Damgård-Verstärkung) gelöst werden. Daher wird empfohlen, einen anderen Betriebsmodus zu verwenden, z. B. CMAC, um die Integrität von Nachrichten variabler Länge zu schützen.

Die kürzere Antwort: Die Sicherheit eines MAC, der aus einer Blockverschlüsselung erstellt wurde, hängt davon ab, wie Sie ihn erstellen. Eine naive Konstruktion wird mit ziemlicher Sicherheit erhebliche Mängel aufweisen.

4
Nick Johnson

Die Tatsache, dass Sie einen ungewöhnlichen Algorithmus entworfen haben, macht ihn nicht sicher. "selbstgemachte" Algorithmen sind gefährlich, weil niemand sie kryptografisch analysiert hat.

Wie @Thomas Pornin oben schrieb, war AES nicht kollisionssicher. Außerdem ist AES relativ schnell, was Angriffe vereinfacht.

SHA1 ist kollisionssicher, SHA1 ist jedoch auch sehr schnell, da es dazu dient, in kurzer Zeit Hashes mit großen Daten- oder Dateivolumina zu generieren. Ziel ist es nicht, Angriffe auf gehashte Passwörter zu verhindern.

Wenn Sie einen Kennwort-Hash generieren möchten, der gegen verschiedene Arten von Angriffen resistent ist, sollten Sie die Kennwortverlängerung in Betracht ziehen. Abhängig von Ihrem Technologie-Stack und den verfügbaren Bibliotheken berücksichtigen Sie bcrypt, scrypt, argon2.

1
mentallurg