Kurze Antwort: schlechte Idee, tu es nicht.

Längere Antwort: Der Sinn der Übung besteht darin, Speichern Sie etwas, mit dem der Server ein bestimmtes Kennwort überprüfen , das Kennwort jedoch nicht neu erstellen erstellen kann. 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 a konvertiert Passwort in den Bestätigungswert gegeben. Die Transformation muss:

• konfigurierbar langsam sein, um Wörterbuchangriffe zu vereiteln;
• für jede Instanz unterschiedlich, um parallele Wörterbuchangriffe, einschließlich vorberechneter Tabellen, zu verhindern (das ist es, was salzt sind ungefähr).

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 etwas vorzuziehen sein sollte).

Allerdings MD5 und SHA-1 machen mindestens eines richtig: Sie wurden so konzipiert, dass sie nur in eine Richtung funktionieren. Das ist schwer zu machen; Es ist nicht einmal theoretisch bewiesen, dass Einwegfunktionen überhaupt existieren können. Kryptografen auf der ganzen Welt nehmen derzeit an einem Wettbewerb teil, um eine neue, bessere Einweg-Hash-Funktion zu entwickeln.

Ihr Professor scheint also zu empfehlen, eine Funktion für Einbahnstraßen 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 in Bezug auf Angriffe mit verwandten Schlüsseln relativ schwach ist - dies ist kein Problem, solange AES für das verwendet wird, wofür es gedacht war, dh für die 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 umfangreiche Nacharbeiten (siehe z. B. Whirlpool und ECHO).

Verwenden Sie daher kein hausgemachtes AES-basiertes Passwort-Hashing-Schema. Verwenden Sie im Übrigen 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 einzelner Kryptograf wird dies nicht riskieren.

Verwenden Sie stattdessen bcrypt. PBKDF2 ist auch nicht schlecht.

Die meisten Websites verwendeten md5 oder sha1 (richtig?). Dies ist also 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 erfolgen, dass es dort normalerweise nicht verwendet wird. Machen Sie es nicht sicherer - das ist 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 sagen, dass Sie es sind Verwendung.

Im Moment kann ich mir die folgenden möglichen Nachteile bei der Verwendung von AES oder einem anderen Verschlüsselungsalgorithmus wie diesem vorstellen:

1. Verschlüsselungsalgorithmen sind normalerweise nicht zum Vermeiden gedacht Kollisionen: 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 weitaus einfacher durchzuführen sind, wenn man weiß, dass Klartext und Kennwort vorhanden sind tatsächlich ein und dasselbe (sollte die Tatsache über den Algorithmus, den Sie verwenden, irgendwie lecken, was nicht so unwahrscheinlich ist, da es zB hier diskutiert wird).
3. Verschlüsselungsalgorithmen erzeugen Daten, die in vielen Fällen mit dem variieren Länge des Klartextes. 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 wurde (was bedeutet, dass es Zeit dafür hatte) (
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/

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 Passwortlänge zu berücksichtigen, benötigen Sie eine Hash-Funktion, also zurück zum Anfangspunkt.

Beachten Sie, dass es gute Passwörter gibt. untersuchte und sichere * Möglichkeiten, 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".

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 als Websitebesitzer Ich möchte nicht die Möglichkeit haben, die Passwörter meines Benutzers zu entschlüsseln. Andernfalls wird die Option zum "Wiederherstellen von Passwörtern" zu einer möglichen Funktion, nach der höhere Unternehmen fragen können, und technisch können wir dies tun, weil das zugrunde liegende System aufgebaut ist Verwenden eines Verschlüsselungssystems anstelle eines Hashing-Systems (ein lahmer Grund, aber Softwareentwickler bearbeiten Anfragen wie diese).

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

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, was etwas "Unerwartetes" macht. 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 Kennwortdatenbank zugreifen kann, wie können Sie sicher sein, dass er keinen Zugriff auf Ihre Kennwort-Hash-Ableitungsfunktion hat?

Ein Fehler beim "Verschlüsseln eines Kennworts mit sich selbst": Die Länge des Chiffretextes könnte 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.

Es gibt MACs (Message Authentication Codes), die aus Blockchiffren aufgebaut sind. Das bekannteste ist wahrscheinlich CBC-MAC. Im Vergleich zu einem Hash-Mac treten Probleme auf, 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 (dh CBC-MAC) (m, t) und (m ', t') kennt, kann eine dritte Nachricht m '' generieren, 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, eine andere Betriebsart zu verwenden, z Beispiel: CMAC zum Schutz der Integrität von Nachrichten mit variabler Länge.

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.

Die Tatsache, dass Sie einen ungewöhnlichen Algorithmus entworfen haben, macht ihn nicht sicher. "Selbstgemachte" Algorithmen sind gefährlich, da niemand eine kryptografische Analyse durchgeführt 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, Hashes mit großen Daten- oder Dateivolumina zu generieren eine kurze Zeit. Der Zweck besteht nicht darin, Angriffe auf gehashte Kennwö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 sollten Sie bcrypt, scrypt, argon2 .