Passwortabfrage bei Verschlüsselung

[Kutter111]

Ohhhhhh Mann!

Na klar, Ihr habt recht. Das ist es. Es ist wirklich zu einfach. Es geht darum die Daten selber nicht anzutasten sondern eine Kopie, diese mit dem eingegebenen Passwort zu entschlüsseln und das Passwort zu vergleichen. Damit wäre die Sicherheit der Daten gewährleistet, auch wenn das Passwort falsch wäre. Jetzt verstehe ich auch Dax Vorschlag. Manchmal hilft eben nur der Hammer!

Danke für die Hilfe, das sind genau die Dinge, die manchmal zum Erfolg führen, obwohl sie nicht ganz offensichtlich für einen sind.

Gruß Kutter111

[mashutu]

Zitat von DAX:

Indem du deinen anstatt der reinen Datei den Stream (Passwort + Datei) verschlüsselst. Wenn du jetzt wieder entschlüsselst und sich eingegebenes und entschlüsseltes Passwort decken, ist das Passwort richtig.

Ich frage mich allerdings, ob damit die Sicherheit nicht deutlich eingeschraenkt wird???
Wenn ein Cracker weiss, dass er beim ausprobieren von Pwds oder bei einem Brute-Force-Attack als Result in den ertsen 'n' Zeichen wieder das 'n'-Zeichen lange Pwd findet macht man es ihm schon leicht.

Ich kenne jetzt das dcpcrypt2 nicht, aber IMHO hast Du entweder einen Denkfehler oder ein Designproblem.

[Hador]

Zitat von mashutu:

Ich frage mich allerdings, ob damit die Sicherheit nicht deutlich eingeschraenkt wird???

Ganz klar: Ja wird sie.

Das Passwort mit zu verschlüsseln ist Quatsch.

Das Sinnvollste was du machen kannst ist entweder vom Passwort ein Hash zu erstellen und damit das Passwort zu prüfen oder alternativ einen Hash der entschlüsselten Datei anzulegen und die Datei nach dem entschlüsseln prüfen.

Empfehlen würde ich dabei die erstere Methode.

Zum Thema Hash-Verfahren kannst du die bspw. mal md5 angucken

[SirThornberry]

ich würde keine der Varianten nehmen. Denn sobald ein festes Muster beim entschlüsseln vorhanden ist kann per Automatisierung geprüft werden ob das probierte Passwort korrekt ist. Das sichere ist eben, das nur derjenige der die Daten in unverschlüsseltem Zustand kennt, weiß ob die Daten verwertbar sind oder nicht.
Wenn also jemand das richtige Passwort zufällig verwendet aber trotzdem nicht erkennen kann ob das Passwort richtig war oder nicht, dann ist das ganze sicherer als wenn derjenige sofort eine algorythmiche Prüfung hernehmen kann welche die Richtigkeit überprüft.

[Reinhard Kern]

Zitat von SirThornberry:

ich würde keine der Varianten nehmen. Denn sobald ein festes Muster beim entschlüsseln vorhanden ist kann per Automatisierung geprüft werden ob das probierte Passwort korrekt ist. Das sichere ist eben, das nur derjenige der die Daten in unverschlüsseltem Zustand kennt, weiß ob die Daten verwertbar sind oder nicht.
Wenn also jemand das richtige Passwort zufällig verwendet aber trotzdem nicht erkennen kann ob das Passwort richtig war oder nicht, dann ist das ganze sicherer als wenn derjenige sofort eine algorythmiche Prüfung hernehmen kann welche die Richtigkeit überprüft.

Hello Sir,

wenn du damit recht hättest, würde weder das Internet noch sonst etwas auf dem Computer funktionieren: natürlich muss man feststellen können, ob ein Passwort korrekt ist, ohne eine komplette Datei unbekannter Grösse zu entschlüsseln und zu interpretieren. Zutreffend ist allerdings, dass man ein Passwort nie im Klartext speichern sollte, deswegen ist das Standardverfahren, einen Hash des PW zu speichern, mir dem man die Gültigkeit prüfen kann, der aber keine Rekonstruktion des PW erlaubt.

Dieser Hash muss also in jedem Fall irgendwo gespeichert werden, ob ich da noch eine zu verschlüsselende Datei gleich mit dranhänge, ändert an der Sicherheit NICHTS! Für das angeprochene Problem ist es also die beste Lösung, das PW zu hashen wie z.B. in Linux üblich (dort landet es ja auch in der PW-Datei, und der Hash kann ohne weiteres gelesen werden, ohne dass dadurch die Sicherheit gefährdet ist), und diesen Hash mit in die verschlüsselte Datei zu packen.

Schliesslich muss man ja noch was mit den Daten anfangen können. Du hast aber sicher recht mit deiner Grenzwertbetrachtung, dass Daten dann am sichersten sind, wenn man sie überhaupt nicht mehr entschlüsseln kann; das ist bloss für die Praxis wenig hilfreich.

Gruss Reinhard

[himitsu]

Zitat:

natürlich muss man feststellen können, ob ein Passwort korrekt ist, ohne eine komplette Datei unbekannter Grösse zu entschlüsseln und zu interpretieren.

ich sag's mal so ... zip, 7zip, rar und Co. entschlüsseln die Dateie(n) und erkennen dann ob die Datei korrekt entschlüsselt wurde.
> Hash der gepackten Datei

[Hador]

Letztendlich muss man zwischen Benutzerfreundlichkeit und Sicherheit abwägen.

Das sicherste ist definitiv die Lösung, die SirThornberry vorgeschlagen hat: Die Datei wird entschlüsselt und _nicht_ überprüft. Der Anwender selber muss dann entscheiden, ob die so entstandenen Daten lkorrekt sind. So hat man es selbst mit einem BruteForce Angriff schwer, da man nicht weiß, welche entschlüsselung korrekt ist.

Die zweite Möglichkeit, die entschlüsselte datei anhand eines Hashes zu verifizieren macht den BruteForce-Angriff lichter, da so der Erfolgsfall bestimmt werden kann. Jedoch muss jedesmal erst das Entschlüsselungsverfahren mit jedem Key angewandt werden, was recht lange dauert.

Die für den benutzer am angenehmste Methode ist das Erstellen eines Hash vom Passwort, da bei einer Falscheingabe des Passworts sofort zurückgegeben wird, dass das Passwort falsch ist und man nicht erst auf den Entschlüsselungsversuch warten muss. Dafür hilft sowas auch einem möglichen BruteForce-Angriff, der logischerweise so ebenfalls schneller ausgeführt wird.

--

Welche dieser Methoden man wählt ist Situationsabhängig.

[negaH]

Vieles wurde ja schon beantwortet, also nur par Hints von mir.

1.) Das Passwort wird in einen pseudozufälligen und sicheren Sessionkey umgewandelt. Dazu benutzt man sogenannte KDFs -> Key Derivation Functions -> Schlüsselableitungsfunktionen. Diese benutzen das Passwort + einen > = 128Bit Zufallswert im Zusammenhang mit einer Hashfunktion um aus dem immer gleichen Passwort einen sicheren, nicht rückrechenbaren und immer anderen, pseudozufälligen, Sessionkey zu erzeugen. Mit diesem Sessionkey wird der Cipher initialisiert und die Daten verschlüsselt.

2.) Mit einer MGF = Mask Generation Function, wird aus dem Passwort und einem Zufallswert = Salt, eine "Prüfsumme" erzeugt. Diese Prüfsumme + dem Zufallssalt, beides >= 128 Bit groß, wird noch vor der Verschlüsselung an den Anfang der Daten gehängt.

also

Salt_1 = RandomBinary(16);
Salt_2 = RandomBinary(16);
SessonKey = KDF(Salt_1, Passwort);
Checksum = MGF(Salt_2, SessionKey);
CipherText = ENCYPT(SessionKey, Salt_2 + Checksum + PlainText);
FinalData = Salt_1 + CipherText;

und entschlüsselt dann so:

Salt_1 = EXTRACT(FinalData, 1, 16);
SessionKey = KDF(Salt_1, Passwort);
Temp = DECRYPT(SessonKey, EXTRACT(FinalData, 16, MaxInt));
Salt_2 = EXTRACT(Temp, 1, 16);
Checksum = EXTRACT(Temp, 16, 16);
if Checksum <> MGF(Salt_2, SessionKey) then ShowMessage('Falsches Passwort');
PlainText := EXTRACT(Temp, 32, MaxInt);


Wir erzeugen also aus 128 Bit Zufall + Passwort einen Sessionkey. Aus diesem erzeugen wir mit 128 Bit Zufall eine Prüfsumme. Beide Werte sind geschützt mit einer Hashfunktion und pseudozufällig. Diese beiden Salts stehen dem Angreifer zwar indirekt zur Verfügung aber denoch kann er nicht, bzw. nur mit einem vorrausberechenbaren Aufwand, daraus Nutzen ziehen. Die Schranke dieses Aufwandes liegt bei 2^128 Kombinationen, eben weil wir beide Salt 16 Bytes groß gemacht haben. Bei einem gutem 128 Bit Password ist also im Sessionkey und Prüfsumme 128 Bit Zufall gemischt mit 128 Bit Passwort. Defakto musst du dir das so vorstellen als ob du ein Passwort benutzt das aus 128 Bit festem Teil und 128 Bit zufälligem Teil besteht und bei dem diese beiden Teile mit einander verknüpft worden sind, so das sie nicht durch den Angreifer getrennt werden können.
Da unsere Prüfsumme über den pseudozufälligen Sessionkey gleich zweimal von 2 Zufallssalts abhängig ist kann der Angreifer keine Informationen rausziehen. Den Salt_1 kann er zwar extrahieren muß dann aber 2^128 Passwörter durchprobieren. Hat er eines probiert muß er den Anfang der Daten damit entschlüsseln und den 2. Salt extrahieren. Hat er falsch gewählt so würde der 2. Salt, der ja auch verschlüsselt wurde, eben falsch entschlüsselt. Die Wahrscheinlichkeit das er mit diesem falschen 2. Salt und der falsch entschlüsselten Prüfsumme zum falschen Sessionkey eine denoch gültige Prüfsumme vor sich hat ist dann exakt so groß wie die Wahrscheinlichkeit das er alle Werte korrekt gewählt hat. Und das ist die Essenz des Verfahrens. Somit gewinnt er keinerlei Informationen im Vergleich falsch zu richtig entschlüsselt, und muß immer eine komplette Brute Force Attacke fahren. Bei diesem "Informationsgewinn" geht es primär nur darum ob er seinen Angriff beschleunigen kann, nicht darum ob er eine korrekte Entschlüsselung identifizieren kann.
Zusätzlich schützt diese Methode das Passwort und damit den Benutzer vor optimierten Brute Force Attacken wie zb. Wörterbuchangriffen -> Rainbow Tables.

Gruß Hagen

Ja Mann, Respekt

[Kutter111]

Wow...,
ich dachte nicht das ich noch so viele Tips bekommen würde nach dem ich das eigentliche Problem bewältigt habe.
Und doch sehe ich wieder viele offene Fragen über den Sinn oder Unsinn des Passwortes und dessen Überprüfung. Es ist vielleicht ganz gut zu wissen, daß die Möglichkeit der Abfrage besteht. Ob man sie jetzt nutzt oder nicht bleibt jedem selber überlassen. Was auch ganz interessant ist ist Hagens Antwort (für soviel Wissen muß man doch einen Kopf wie ein Pferd haben, hast Du?), in der man sieht wie sehr man sich bemüht, Angriffen Widerstand entgegenzubringen und wichtige Daten zu schützen. Mit dieser Antwort werde ich mich wohl auf die nächste Ebene der Verschlüsselung begeben müssen. Noch ganz kurz eine Frage an Hagen: Geht das, was Du geschrieben hast mit Deiner DEC so?

Gruß Kutter111

[negaH]

Ja sicher.

DEC hat einen sicheren Zufallsgenerator, die Hash Klassen unterstützen direkt verschiedene KDFs und MGFs und die Verschlüsselungen sind auch integriert. Hier im Forum sollte man sogar einiges an fertigen Source fürs DEC finden.

Gruß Hagen