C# AES Passwort-Verschlüsselung

[Delacroix]

Hallo an alle CBler,
hätte da nur eine kurze Frage.

Ich will ein Passwort in AES verschlüsseln und das verschlüsselte Password in ein Dokument speichern, damit man es später da wieder auslesen und benutzen kann.

Das Problem:
Speichere ich die verschlüsselten Bytes als String kommen da unlesbare Zeichen hervor

Speichere ich die einzelnen Bytes des Byte-Arrays muss ich iwie später unterscheiden können welche Zahl in das nächste Feld gehört (z.B. durch Space nach jedem ArrayFeld) => sieht nicht gut aus und nicht wirklich elegant...

Als Beispiel: abcd1234 => 62 161 56 233 34 207 142 155 241 4 243 212 118 160 202 118

Frage:
Gibt es eine andere Möglichkeit das VERSCHLÜSSELTE Passwort irgendwie in lesbaren Zeichen in die Datei zu speichern? Oder vielleicht eine andere Verschlüsselungsmethode?

Die Zeichenfolge sollte eben auch nicht ZU lang sein, weil es bestimmt öfter vorkommen wird, dass die Datei auch mal im Editor zur Einsicht geöffnet wird (da stehen abgesehen vom PW auch andere Informationen drin), da würde eine ewig lange Zeichenfolge natürlich die Lesbarkeit ungemein stören.

Bedanke mich schon mal für eure Hilfe

 

[Madman1209]

Hi,

darf man fragen wieso du ein Passwort verschlüsselt? Zum entschlüsseln musst du ja wieder ein Passwort eingeben, das führt das Ganze komplett ad absurdum. Oder geht es um eine ganze Liste an Passwörtern?

Erkläre mal genau was du vorhast und wie du es dir vorstellst.

VG,
Mad

 

[Keepers]

Unabhängig, dass ich nicht nachvollziehen kann wieso man das dann in ein Dokument reinkopieren will und so, folgende Dinge zu beachten:

AES als Blockchiffre braucht einen Block von 128 Bit länge und ne variable Keysize (128, 192, 256 bit).
Je nach Kodierung deiner PW Eingabe hast du also entweder Padding, einen Block oder noch ne Betriebsmodi wie CBC zu wählen.

Die Ausgabe des Ergebnisses ist doch am sinnvollsten im Hex-Format. So lässt sich auch aus einer Cmdline der Wert kopieren. Du musst lediglich dafür sorgen, dass das kopieren oder schreiben ins Dokument dann als String und umgekehrt mit der entsprechenden Hexvalue abläuft. Ob C# dafür Methoden bereitstellt weiß ich nicht, habe nie etwas mit C# gemacht.


Ich frage mich, warum du das Passwort nicht als Hash ablegen willst? Willst du es denn jederzeit rekonstruieren können? Dann wäre der Hash nicht die richtige Wahl. AES bildet 28 bit plain auf 128 bit cipher ab, Immer.

Wie wäre es mit einem Public-Key Verfahren, bei dem der Cipher gleich lang mit dem Plain ist?


Und ganz am Rande:
Wenn du nur eine sichere Aufbewahrungsmethode für Passwörter mit Recovery suchst: KeePass

 

[GrinderFX]

Vielleicht solltest du dich erst mal mit dem Speichern und Lesen von Dateien beschäftigen, bevor du mit komplexen Verschlüsselungstechnologien anfängst?

 

[Delacroix]

@GrinderFX:
Ich kann Dateien wunderbar lesen und speichern....

@Keepers:
Ja das Passwort muss rekonstruiert werden sobald es Verwendung findet. Da ist also leider nichts mit Hash

@Madman1209:
Der Key zur Verschlüsselung wird in der Software hinterlegt. Das zu verschlüsselnde (und in der Datei abzulegende) Passwort wird aber für etwas anderes verwendet z.B. Anmeldung an einem SMTP-Server. Soll aber eben in der Textdatei nicht im Klartext stehen, so dass es jeder dahergelaufene DAU lesen kann.

Die Lösung fü mein Problem:
Convert.ToBase64String(bytes) und Convert.FromBase64String(text)

 

[1668mib]

Also ich seh jetzt keinen wirklichen Sicherheitsgewinn beim Speichern des Passworts gegenüber der Speicherung in Klartext...

 

[grünel]

Dir ist aber hoffentlich klar, dass Base64 keine Verschlüsselung sondern lediglich eine Kodierung ist und jeder DAU das innerhalb von 10 Sekunden decoden kann.

 

[Madman1209]

Hi,

zusätzlich zu grünels absolut korrektem Hinweis:

Es ist auch absolut kein Sicherheitsgewinn, wie 1668mib schon vollkommen richtig erkennt! Hände weg von solchen Lösungen! Jeder der Google nutzen kann hat das Passwort in 15 Minuten aus dem Programm extrahiert wenn er ein wenig Ahnung hat.

Vor allem verstehe ich immer noch nicht, wieso es in einer Textdatei gespeichert wird. Warum nicht direkt im Programm? Wenn du das Passwort zum entschlüsseln im Programm hinterlegst hast du kein nennenswertes Mehr an Sicherheit!

VG,
Mad

 

[holy]

Wieso sagt ihm nicht einfach jemand die Lösung anstatt mit besserwisserischen Hinweisen das ganze noch zu verschlimmbessern?

Hier ist ein Code-Schnippsel, den ich für solche Fälle verwende. Hier wird die DPAPI verwendet. Die entsprechende Zeilen (ProtectData...) musst du durch deine Encryptor/Decryptor ersetzen.

private string Decrypt( string data )
{
    string[] parts = data.Split( '-' );
    byte[] bytes = new byte[parts.Length];
    for ( int i = 0; i < parts.Length; ++i ) 
        bytes[i] = Convert.ToByte( parts[i], 16 );

    byte[] decrypted = ProtectedData.Unprotect( bytes, _entropy );
    return Encoding.UTF8.GetString( decrypted, 0, decrypted.Length );
}

private string Encrypt( string data )
{
    byte[] bytes = Encoding.UTF8.GetBytes( data );
    byte[] encrypted = ProtectedData.Protect( bytes, _entropy );
    return BitConverter.ToString( encrypted );
}

 

[Madman1209]

Hi,

@holy

Codeschnipsel hin oder her, das Passwort zum Verschlüsseln in die EXE zu schreiben bietet keine Sicherheit! Da kann er gleich das Passwort selber in die EXE schreiben, da hätte er den gleichen Effekt.

VG,
Mad

 

[holy]

Hi,

@holy

Codeschnipsel hin oder her, das Passwort zum Verschlüsseln in die EXE zu schreiben bietet keine Sicherheit! Da kann er gleich das Passwort selber in die EXE schreiben, da hätte er den gleichen Effekt.

VG,
Mad

Na da hab ich ja Glück, dass der Schnippsel die DPAPI verwendet und es gar nicht nötig ist, ein Passwort zu speichern

Edit.
Ausserdem will er wissen, wie er die Unicode Zeichen lesbar speichern kann. Wenn er meint das entsprechende Passwort in der Binary speichern zu müssen, ist das sein Problem

 

[Delacroix]

@Madman:
Mir ist bewusst, dass Base64String lediglich zur kodierung dient und nicht zur Verschlüsselung, aber genau darum gings mir ja...

Ich habe einen verschlüsselten String als Byte-Array und will das Byte-Array als String in eine Datei speichern (in lesbaren Zeichen). An dieser Stelle tritt Convert.ToBase64String() in Aktion... mehr wollte ich ja nicht.

@holy: Danke dir, aber hab bereits meine Lösung


PS: Bei diesem Thread stand die Verschlüsselung im Hintergrund, ver- und entschlüsseln kann ich auch selber und weis auch worauf ich achten muss (tut mir leid, wenns falsch rüber kam, aber der Key zur Verschlüsselung wird natürlich nicht im Quelltext hinterlegt, das war jetzt nur Testweise bis ich die Kodierung endlich hinbekommen habe so. ).... um die Kodierung gings hier!

Auf jeden Fall ist das Problem nun gelöst, danke für eure Hilfe und eure Ratschläge

 

[Madman1209]

Hi,

@holy

und wie wird bei der DPAPI die Sicherheit erzielt? Natürlich hast auch du eine Art Kennwort, oder was genau meinst du ist deine "entropy" Variable?

Und zum Thema "sein Problem": Klar, man kann ihn voll rein laufen lassen. Aber ein Hinweis wird ja wohl noch erlaubt sein.

@TE

Gut, wir wollten dir nur helfen, damit du damit nicht ganz gehörig auf Probleme stößt, die dir vielleicht nicht klar waren. Wenn dir alles andere klar ist kannst du es natürlich ignorieren

VG,
Mad

 

[Delacroix]

Nein ich bedanke mich natürlich für die Ratschläge. Finde auch euer Fachwissen echt super (da reicht meins noch nicht ran )

Aber wie gesagt in erster Linie gings mir um die Kodierung, dass ich es Lesbar abspeichern kann
Wie ich das mit dem Initialisierungsvektor und dem Key handhabe ist natürlich eine andere Sache.
Wird auf jedenfalls nicht im Quelltext verankert sein das Ganze

 

[holy]

@holy

und wie wird bei der DPAPI die Sicherheit erzielt? Natürlich hast auch du eine Art Kennwort, oder was genau meinst du ist deine "entropy" Variable?

Und zum Thema "sein Problem": Klar, man kann ihn voll rein laufen lassen. Aber ein Hinweis wird ja wohl noch erlaubt sein.

Ich hoffe dir ist klar, dass du da grade ziemlichen Müll schreibst. Entropy ist nichtmals ansatzweise ein Kennwort (auch wenn man es dazu missbrauchen kann).

 

[1668mib]

Und wieso schreibst du nicht einfach, wie es ist?
Hier übrigens die Doku dazu...

http://msdn.microsoft.com/de-de/library/system.security.cryptography.protecteddata.protect.aspx

Also wichtig: Es ist wirklich eine Protection und keine "Verschlüsselung", zumindest verstehe ich es so. Also es ist nicht dazu gedacht, um die geschützten Daten von A nach B zu übertragen, sondern sie im selben System wieder auszulesen... zumindest ist das meine Vermutung.

Worauf dort die Sicherheit basiert, dass niemand unbefugtes die Daten entschlüsseln kann, kann ich nicht sagen, hab mich zu wenig eingelesen. Weiß jemand, wie das intern arbeitet? Vielleicht hab ich vorher ja auch Stuss geredet?

 

[Backslash]

http://blogs.msdn.com/b/shawnfa/archive/2004/05/05/126825.aspx

DPAPI works by generating a key from the current user's credentials (generally their password, although a smart card will provide a different credential). It then generates a master key, and encrypts this with the key generated by the user's credentials. A random session key is created for each call to CryptProtectData. This key is derived from the master key, some random data, and some optional entropy passed in by the user. The session key is then used to do the actual encryption. Rather than storing the session key, the random data used in key creation is stored in the encrypted output.

Ob das jetzt so ideal ist, darüber lässt sich wohl streiten aber insgesamt scheint das Konzept relativ vernünftig für manche Anwendungen.

Und im allgemeinen sind Hinweise auf mögliche Sicherheitslücken lediglich dazu gedacht, unerfahrenere Anwender vor beträchtlichen Schäden zu bewahren (besonders wenn das betreffende Programm geschäftlich genutzt wird).

 

[holy]

Es ist tatsächlich eine Verschlüsselung auf AES-Basis. Das Kennwort leitet sich dabei von den Windows-Credentials ab.
Und ja, es taugt nicht dazu um Daten sicher von A nach B zu bekommen, sondern eher um z.B. sowas wie Anmeldedaten, die ein User in ein Programm eingibt auf dem System vor Blicken anderer zu schützen. Seit Win8, Server12 ist das etwas anderes. Da arbeitet die API auch domain-weit inkl. Gruppenberechtigungen usw... anderes Thema.

Wie auch immer. Es ging überhaupt nicht um die DPAPI. Den Schnippsel habe ich eben aus einem meiner WP8-Projekte kopiert mit dem Hinweis, dass die beiden Zeilen mit ProtectData zu ersetzen sind Die (optionale) Entropie dient dabei um die Komplexität zu erhöhen. Wenn du nicht genau wissen willst, was es in diesem Zusammenhang bedeutet, betrachte es als Salt. Ansonsten hilft dir Wikipedia gerne weiter (klick).

 

[1668mib]

Also auf jeden Fall sinnvoller, einen Mechanismus zu verwenden, der den Benutzer-Account als "Schlüssel" nimmt (also einen Benuter-Account-abhängigen Schlüssel), als den Schlüssel in die Anwendung zu integrieren.

@holy: Den Entropie-Wiki-Artikel kannst dir sparen, weil dort sicher nicht steht, warum es die Komplexität erhöht ... insofern kann man sich das durchlesen, hat aber mit dem Thema nichts zu tun. Oder übersehe ich was?

 

[ascer]

Mag vielleicht nochmal jemand erläutern, warum genau jetzt nun das verschlüsseln des Passworts nicht sicherer als die Klartextlösung ist?

Ich mein, man könnte doch jedem User einen Key zuteilen, mit dem sein Passwort ver- und entschlüsselt wird?!

Der Key müsste natürlich an eine sichere Stelle^^