C# AES Passwort-Verschlüsselung

[1668mib]

Also das Passwort wird ja verschlüsselt, weil man den Benutzer nicht immer sein Passwort eingeben lassen will. Es ist also davon auszugehen, dass das Programm ohne zusätzliche Authentifikationsmechanismen auskommen soll.

Irgendeine Form der Authentifizierung sollte aber da sein, wenn es halbwegs sicher sein soll. Das mindeste, was man da verlangen kann, ist die Bindung an das Windows-Benutzerkonto. Allerdings stellt sich dann noch die Schlüsselfrage: Wie kann man dem Benutzer zuverlässig einen Schlüssel zuweisen, den jemand anders nicht erraten und auch nicht einfach kopieren und nutzen kann? Kein triviales Problem... wie sieht die sichere Stelle bei dir aus?

Das .NET-Framework bietet dafür allerdings schon eine API. Warum das Rad auch neu erfinden?

 

[holy]

@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?

Der Artikel sollte eher der allg. Begrisserklärung dienen. Es ist nunmal kein Passwort. Auch kein Passwortersatz.

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

Es ging darum, dass wenn du das benötigte Passwort mitlieferst (als String hard-codiert im Quelltext), kann Person X daherkommen und es einfach aus deinem Programm extrahieren. Von daher kann man sich das Tärä auch gleich sparen und gar nichts verschlüsseln. Ist genauso sicher.

 

[ascer]

@holy: Ja genau, aber würde dann nicht in der Tat irgend ein User-eindeutiger Key, ob nun zufallsgeneriert, der aktuelle Windows-Benutzer oder whatever, mit dem man das eigentlich Passwort verschlüsselt, diesen selbstgedrehten Strick umgehen?

Denn dann könnte das Programm mit dem aktuell eingeloggten User ja jeder Zeit das PW entschlüsseln, irgendjemand anders aber später nicht?!

 

[Fonce]

Was nützt den aber ein verschlüsseltes Passwort, wofür ich wiederum einen Schlüssel(z.B. Passwort) benötigte um es zu entschlüsseln?
Das ganze stellt einen unnötigen Mehraufwand dar, sowohl bei späteren der Rechenzeit, als auch Komplexität des Codes.
Das ist der Grund warum für Passwörter(im normalfall) Hashalgorithmen verwendet werden.
Wenn tatsächlich mit AES verschlüsselt werden soll stellt sich aber tatsächlich die Frage, wie gewährleistet werden soll das eine entsprechent hohe Entropie erreicht werden soll. Das ist ein nicht zu unterschätzender Faktor!

 

[1668mib]

Deshalb ja die .NET-API nutzen, da diese die Daten wenigstens an den Benutzer bindet...

 

[Erdmännchen]

Das ist der Grund warum für Passwörter(im normalfall) Hashalgorithmen verwendet werden.

Das trifft nur insovern zu, als wenn das Passwort später nicht mehr aus dem Hash rekonstruiert werden soll.
Gehasht wird auf dem Server erst beim Abgleich, nicht auf dem Client.

Dem TE ging es aber darum ein Passwort das seine Software für einen Zugang/API/Service/SSH etc. braucht, zu hinterlegen, damit der Nutzer der Software, der wohl schon authentifiziert ist, nicht jedes mal das Passwort eingeben muss.
Hier bringt eine gehashte Ablage natürlich nichts. Es muss ja das Passwort an den anderen Dienst übergeben werden und nicht der Hash.

Mit Zertifikaten find ich sowas übrigens einfacher...

 

[1668mib]

Deshalb wird bei dem Beispiel-Code mit ProtectedData auch ein an den Benutzer gebundenes Zertifikat verwendet...

(Ich gehe davon aus, du meinst zum Speichern der Zugangsdaten. Dass man die Art der Zugangsdaten eines fremden Dienstes ja nicht ändern kann, ist dir denke ich ja klar.)