Windowspasswort sicher speichern und laden

Hallo zusammen

Ich habe folgendes Problem: Der Benutzer soll in einem Programm verschiedene Windows-Anmeldeinformationen eingeben können (Domäne, Benutzer, PW). Ein „Bruderprogramm“ läuft dann als Dienst und lädt die Infos wieder und führt dann vordefinierte Prozesse damit aus.

Eigentlich läuft bereits alles; das einzige Problem: die Anmeldeinformationen liegen zwar mit TDES verschlüsselt in einer Datei, aber mit einem .NET-Reflection Tool kann jeder sofort erkennen, wie das Programm die Daten verschlüsselt und kann sie dann natürlich sofort wieder entschlüsseln.

Ich bräuchte ein Passwort oder Initialisierungsvektor den nur meine Programme kennen und der nicht über dekompilation herausgefunden werden kann (z.B. mit Lutz Röders .NET-Reflector).

Bietet Windows etwas solches an? Oder gibt es eine Möglichkeit über das Assembly einen solchen Wert zu erhalten? Er müsste allderings immer gleich sein, sonst gibt’s bei der Decheffrierung Stussdaten …

Ein vom Benutzer gegebenes Passwort scheidet aus, weil das Dienstprogramm die Daten autonom laden muss (auch nach einem Windowsneustart). Falls ich das vom Benutzer gegebene Passwort speichern möchte, habe ich wieder dasselbe Problem wie mit den Anmeldedaten …

Ich habe lange darüber nachgedacht, aber meine Gedanken drehen sich nun irgendwie im Kreis :smile:

Wenn jemand eine gute Idee hat; her damit!

Besten Dank für eure Hilfe
Patrick

Hallo zusammen

Ich habe folgendes Problem: Der Benutzer soll in einem
Programm verschiedene Windows-Anmeldeinformationen eingeben
können (Domäne, Benutzer, PW). Ein „Bruderprogramm“ läuft dann
als Dienst und lädt die Infos wieder und führt dann
vordefinierte Prozesse damit aus.
[…]
Wenn jemand eine gute Idee hat; her damit!

Besten Dank für eure Hilfe
Patrick

Servus!

Hast Du mal in den Namespace System.IO.IsolatedStorage geschaut? Da könntest Du etwas finden, was Deinen Anforderungen entspricht…

Gruß,
Martin

System.IO.IsolatedStorage
Hallo Martin

Ich habe das Konzept der isolierten Ablage mal studiert. Es scheint sich um eine Technik zu handeln, die vorallem verhindern will, dass sich verschiedene Programme mit ihren Datenablagen nicht ständig gegenseitig auf die Füsse treten (wenn man das mal so salopp ausdrücken darf … man erhält dann sozusagen einen „isolierten Watschelpfad“ :smile:

Allerdings scheint dieser Speicher nicht wirklich sicher; Die Beziehungs-Kennung zwischen dem isolierten Speicher und der Anwendung besteht aus publiken Informationen. Das .NET-Framework stellt diverse Werkzeuge zur Verfügung, mit deren Hilfe diese Speicher wieder ausgelesen werden können.

Aber Besten Dank für deine Idee.

Gruss
Patrick

Ganz zu 100% sicher wirst Du es vermutlich nie hinbekommen, aber nach dem, was ich über die verschiedenen Stores gelesen habe, müsste man z.B. im ApplicationStore schon etwas so ablegen können, dass es nur für eine Anwendung mit einer bestimmten Identität sichtbar ist.
D.h. Du verpasst Deiner Anwendung einen Strong Name und nur diese Anwendung kann auf den Store zugreifen - zumindest hatte ich den ApplicationStore so verstanden.

Gruß,
Martin

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Merci für den weiteren Tip. Ich habe aber inzwischen folgendes rausgefunden, selbst wenn nur mein Assembly (im meinen Fall ein DLL) an die Daten rankommt, kann jeder ‚Böse‘ mein Assembly referenzieren und das Codesegment direkt aufrufen; es muss ja publik sein, sonst können meine zwei anderen Assemblies (die EXE-Files) ja auch nicht zugreifen.

Ich glaub ich such konzeptionell mal nach einer anderen Lösung, mit welcher ich die Windwos-Accounts nicht benötige …

Aber auf jeden Fall noch mal herzlichen Dank!

Gruss
Patrick

Hi Patrick,

mal eine Frage: Wenn das „Bruderprogramm“ zum entschlüsseln ein Dienst ist, so kann dies ja auch eine Datei sein, auf die nur das System Zugriffsrechte besitzt. Wie sollte also ein User den Reflector herausfinden, wie es die Daten entschlüsselt?
Natürlich, mit Admin-Rechten. Aber wenn Du diese vorraussetzt, dann wirst Du nichts verbergen können, denn mit Adminrechten kann man so ziemlich alles aushebeln.