Frage

Ich schreibe eine kleine Desktop-App, die in der Lage sein soll, eine Datendatei zu verschlüsseln und mit einem Passwort zu schützen (z. B.Zum Entschlüsseln muss das richtige Passwort eingegeben werden.Ich möchte, dass die verschlüsselte Datendatei eigenständig und portierbar ist, daher muss die Authentifizierung in die Datei eingebettet werden (so nehme ich an).

Ich habe eine Strategie, die praktikabel und logisch erscheint, basierend auf dem, was ich weiß (was wahrscheinlich gerade genug ist, um gefährlich zu sein), aber ich habe keine Ahnung, ob es sich tatsächlich um ein gutes Design handelt oder nicht.Also sag es mir:ist das verrückt?Gibt es einen besseren/besten Weg, dies zu tun?

  • Schritt 1:Der Benutzer gibt ein Klartext-Passwort ein, z. B.„MyDifficultPassword“
  • Schritt 2:Die App hasht das Benutzerkennwort und verwendet diesen Wert als symmetrischen Schlüssel zum Verschlüsseln/Entschlüsseln der Datendatei.z.B.„MyDifficultPassword“ -> „HashedUserPwdAndKey“.
  • Schritt 3:Die App hasht den gehashten Wert aus Schritt 2 und speichert den neuen Wert im Header der Datendatei (d. h.der unverschlüsselte Teil der Datendatei) und verwendet diesen Wert, um das Passwort des Benutzers zu validieren.z.B.„HashedUserPwdAndKey“ -> „HashedValueForAuthentication“

Im Grunde gehe ich von der üblichen Methode zur Implementierung von Website-Passwörtern aus (wenn Sie nicht OpenID verwenden), die darin besteht, den (gesalzenen) Hash des Benutzerpassworts in Ihrer Datenbank zu speichern und niemals das eigentliche Passwort zu speichern .Da ich aber das gehashte Benutzerkennwort für den symmetrischen Verschlüsselungsschlüssel verwende, kann ich nicht denselben Wert für die Authentifizierung verwenden.Also hashe ich es erneut, behandle es im Grunde wie ein anderes Passwort und speichere den doppelt gehashten Wert in der Datendatei.Auf diese Weise kann ich die Datei auf einen anderen PC übertragen und durch einfache Eingabe meines Passworts entschlüsseln.

Ist dieses Design also einigermaßen sicher oder hoffnungslos naiv oder irgendwo dazwischen?Danke!

BEARBEITEN:Klarstellung und Folgefrage zu:Salz.
Ich dachte, das Salz müsse geheim gehalten werden, um nützlich zu sein, aber Ihre Antworten und Links deuten darauf hin, dass dies nicht der Fall ist.Zum Beispiel, diese Spezifikation verlinkt von Erickson (unten) sagt:

Somit ist die hier definierte passwortbasierte Schlüsselableitung eine Funktion eines Passworts, eines Salts und einer Iterationszahl, wobei die beiden letztgenannten Größen nicht geheim gehalten werden müssen.

Bedeutet das, dass ich den Salt-Wert am selben Ort/in derselben Datei wie den Hash-Schlüssel speichern und trotzdem sicherer sein könnte, als wenn ich beim Hashing überhaupt kein Salt verwenden würde?Wie soll das gehen?

Etwas mehr Kontext:Die verschlüsselte Datei ist nicht dazu gedacht, mit anderen geteilt oder von diesen entschlüsselt zu werden, es handelt sich tatsächlich um Einzelbenutzerdaten.Aber ich möchte es in einer gemeinsamen Umgebung auf Computern bereitstellen, die ich nicht vollständig kontrolliere (z. B.bei der Arbeit) und die Möglichkeit haben, die Daten durch einfaches Kopieren der Datei zu migrieren/verschieben (damit ich sie zu Hause, auf verschiedenen Workstations usw. verwenden kann).

War es hilfreich?

Lösung

Key Generation

Ich würde empfehlen, einen anerkannten Algorithmus wie PBKDF2 definiert in PKCS # 5 Version 2.0 einen Schlüssel aus Ihrem Passwort zu generieren. Es ist ähnlich wie der Algorithmus umreißen Sie, sondern ist in der Lage mehr symmetrischen Schlüssel für die Verwendung mit AES zu erzeugen. Sie sollten eine Open-Source-Bibliothek finden Lage sein, die PBE Schlüsselgeneratoren für verschiedene Algorithmen implementiert.

Dateiformat

Sie könnten auch erwägen die Verwendung von Cryptographic Message Syntax als Format für die Datei . Dies wird einige Studie über Ihre Seite, aber auch hier gibt es vorhandene Bibliotheken zu verwenden, und es eröffnet die Möglichkeit, zwischen Betrieb mehr reibungslos mit anderen Software-up, wie S / MIME-fähigen Mail-Clients.

Kennwortüberprüfung

In Bezug auf Ihren Wunsch, einen Hash des Passworts zu speichern, wenn Sie PBKDF2 verwenden, um die Schlüssel zu generieren, könnten Sie einen Standard-Passwort-Hashing-Algorithmus (großes Salz, tausend Runden von Hashing) verwenden für die, und unterschiedliche Werte erhalten.

Alternativ können Sie einen MAC auf dem Inhalt berechnen. Eine Hash-Kollision auf einem Kennwort ist eher für einen Angreifer, nützlich zu sein; eine Hash-Kollision auf den Inhalt ist wahrscheinlich wertlos. Aber es würde dazu dienen, ein legitimer Empfänger weiß, dass das falsche Passwort für die Entschlüsselung verwendet wurde.

Cryptographic Salz

Salz hilft vorausberechnete Wörterbuchangriffe zu vereiteln.

Angenommen ein Angreifer eine Liste möglicher Passwörter hat. Er kann jede Hash und vergleichen Sie es mit dem Hash seines Opfers Passwort, und sehen, ob es passt. Wenn die Liste groß ist, könnte dies eine lange Zeit in Anspruch nehmen. Er will nicht, dass viel Zeit auf seinem nächsten Ziel verbringen, damit er zeichnet das Ergebnis in einem „Wörterbuch“, wo ein Hash-Punkte zu seinem entsprechenden Eingang. Wenn die Liste der Passwörter ist sehr, sehr lange, kann er Techniken verwenden, wie ein Rainbow Table , um Platz zu sparen.

Sie jedoch an sein nächstes Ziel sein Passwort gesalzen. Selbst wenn der Angreifer weiß, was das Salz ist, seine vorberechneten Tabelle ist wertlos -der Salz ändert den Hash von jedem Passwort führt. Er hat erneut Hash alle Kennwörter in seiner Liste, das Ziel des Salzes mit dem Eingang zu befestigen. Jedes andere Salz erfordert ein anderes Wörterbuch, und wenn genügend Salze verwendet werden, wird der Angreifer nicht Raum Wörterbücher zu speichern haben für sie alle. Handel Raum, Zeit zu sparen ist nicht länger eine Option; Der Angreifer muss jedes Passwort-Hashing für jedes Ziel in seiner Liste zurückgreifen er angreifen will.

Also, es ist nicht notwendig, das Salz geheim zu halten. Sicherstellen, dass der Angreifer keinen vorausberechneten Wörterbuch muss dieses bestimmte Salz entspricht, ist ausreichend.

Andere Tipps

Wie Niyaz sagte, der Ansatz klingt vernünftig, wenn Sie eine hochwertige Umsetzung von starken Algorithmen verwenden, wie SHA- 265 und AES für Hashing und Verschlüsselung. Außerdem würde ich empfehlen, ein Salz mit der Möglichkeit zu verringern, einen Wörterbuch aller zu erstellen Passwort-Hashes.

Natürlich Lesen Bruce Schneier 's Applied Cryptography ist entweder nie falsch.

Wenn Sie einen starken Hash-Algorithmus verwenden (SHA-2) und einen starker Verschlüsselungsalgorithmus (AES), werden Sie mit diesem Ansatz in Ordnung tun.

Warum nicht eine Kompressions-Bibliothek verwenden, die kennwortgeschützte Dateien unterstützt? Ich habe eine kennwortgeschützte ZIP-Datei mit XML-Inhalten in der Vergangenheit verwendet:}

Gibt es wirklich braucht, das Hash-Passwort in die Datei zu speichern. Kannst du nicht einfach das Passwort (oder Hash-Passwort) mit etwas Salz und verschlüsseln Sie die Datei mit. Wenn nur zu entschlüsseln versuchen, die Datei mit dem Kennwort + Salz zu entschlüsseln. Wenn der Benutzer ein falsches Kennwort gibt die entschlüsselte Datei ist nicht korrekt.

Nur Nachteile ich denken kann, ist, wenn der Benutzer versehentlich ein falsches Passwort eingibt und die Entschlüsselung ist langsam, er noch einmal zu versuchen, zu warten hat. Und natürlich, wenn Passwort vergisst es gibt keine Möglichkeit, die Datei zu entschlüsseln.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top