Laden...

Wie schütze ich einen symmetrischen Schlüssel in meiner Anwendung?

Erstellt von sugar76 vor 5 Jahren Letzter Beitrag vor 5 Jahren 2.024 Views
S
sugar76 Themenstarter:in
69 Beiträge seit 2017
vor 5 Jahren
Wie schütze ich einen symmetrischen Schlüssel in meiner Anwendung?

Hallo,

ich speichere in einer Desktop-Anwendung Passwörter, die von der Anwendung ohne Zutun des Users lesbar sein müssen. Anwendungsfall: die Anwendung ruft im Hintergrund regelmäßig neue E-Mails des Users ab und benötigt Zugriff auf seinen E-Mail-Account. Es gibt noch weitere Anwendungsfälle, betrifft nicht nur E-Mail.

Die Anwendung läuft im Intranet (plus Remote Desktop über VPN), besteht aus mehreren Clients und einem Server. Auf letzterem läuft die Datenbank.

Jetzt überlege ich, wie ich das Ganze am besten realisiere.

Mein Ansatz ist folgender: Ich verwende einen symmetrischen Schlüssel, um die Passwörter zu ver- und entschlüsseln. Den Schlüssel lege ich in der App.config ab und schütze den entsprechenden Teil mit aspnet_regiis. Der symmetrische Schlüssel befindet sich dann auf jedem Client-Rechner, geschützt durch den Mechanismus von aspnet_regiis.

Problemstellung ist also: die User speichern Passwörter Ihrer Web-Accounts (E-Mail, etc.). Die Anwendung muss diese Passwörter 1) sicher in der Datenbank speichern und 2) diese entschlüsseln können, um selbstständig auf die Accounts zugreifen zu können.

Wie würdet ihr das realisieren bzw. habt ihr so etwas schon mal umgesetzt?

Gruß

709 Beiträge seit 2008
vor 5 Jahren

Man könnte das auch wie bei Passwortmanagern machen.
Die Anwendung speichert die verschiedenen Zugangsdaten und der Schlüssel für alles ist ein gemeinsames Passwort.
Dadurch müsste sich der Benutzer zwar immer noch ein Passwort merken, allerdings nur ein einziges.

S
sugar76 Themenstarter:in
69 Beiträge seit 2017
vor 5 Jahren

Man könnte das auch wie bei Passwortmanagern machen.
Die Anwendung speichert die verschiedenen Zugangsdaten und der Schlüssel für alles ist ein gemeinsames Passwort.
Dadurch müsste sich der Benutzer zwar immer noch ein Passwort merken, allerdings nur ein einziges.

Wenn die diversen Zugangsdaten mit einem Benutzerpasswort verschlüsselt werden, muss die Anwendung dieses Master-Passwort "kennen". Damit sie ohne User-Interaktion die Zugangsdaten entschlüsseln kann. Damit wären wir beim Ausgangspunkt meiner Frage: wie sichere ich das Master-Passwort?

709 Beiträge seit 2008
vor 5 Jahren

Das müsste dann halt einmalig pro Sitzung eingegeben werden.

16.806 Beiträge seit 2008
vor 5 Jahren

Es gibt keine Möglichkeit ein solches Master Password (man nennt es i.d.R. Secret) nicht zu hinterlegen.
Man braucht schließlich irgendwo den ersten Domino-Stein.

Selbst bei einem Key Storage (zB Azure Key Vault) braucht man ein solches Secret, um auf den Vault zugreifen zu können.
Es wäre jedoch möglich eine Identitätsverwaltung - wie bei Key Vault - aufzubauen, sodass Vaults jeweiligen Identitäten zuweisbar sind.
Damit ist eine Nutzung der Passwörter möglich; jedoch benötigt dies - aufgrund der Identitätsverwaltung - kein Secret des Vaults.

Dies ist aber ein spezielles Konstrukt von Azure, was es in der Form On-Prem nicht gibt.
Azure übernimmt hierbei das Setzen des ersten Steins.

3.003 Beiträge seit 2006
vor 5 Jahren

Für sowas gibt's eigentlich asymmetrische Verschlüsselungen.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

S
sugar76 Themenstarter:in
69 Beiträge seit 2017
vor 5 Jahren

Für sowas gibt's eigentlich asymmetrische Verschlüsselungen.

Kannst Du das etwas näher erläutern? Wo liegt der Vorteil gegenüber symmetrischer Verschlüsselung, bezogen auf das von mir beschriebene Setting?

P
441 Beiträge seit 2014
vor 5 Jahren

Wenn dein Client ausschließlich auf Windows läuft - was spräche dagegen den initialen "Dominostein" von Windows sichern zu lassen?
Windows bietet dazu eine API, in der auch z.B. IE die Zugangsdaten für Webseiten speichert (ob es bei Edge noch genau so ist weiß ich allerdings nicht) und diese wären mit den Benutzerkonto* abgesichert.

* Allerdings dem lokalen Benutzerkonto, nicht mit dem Active Directory Konto. Bei einem Rechnerwechsel müsste also irgendwie einmalig dieser Schlüssel wieder eingegeben werden.

286 Beiträge seit 2011
vor 5 Jahren

Wo liegt der Vorteil gegenüber symmetrischer Verschlüsselung, bezogen auf das von mir beschriebene Setting?

Am besten mal symmetrische Verschlüsselung und asymmetrische Verschlüsselung durchlesen.

Kurz zusammengefasst:
Asymmetrische Verschlüsselung hat der symmetrischen einen signifikanten Vorteil: Du hast zwei verschiedene Schlüssel (darum asymmetrisch) einen "kürzeren" publicKey und einen "längeren" privateKey. Du kannst mit dem publicKey etwas ver- aber nicht wieder entschlüsseln, dies geht nur mit dem privateKey. Das hat den Vorteil, dass du den publicKey nicht geheim halten musst, ihn also über eine ungesicherte Verbindung übertragen kannst (und alle Verbindungen sind zu Beginn unsicher).
Der Nachteil der asymmetrischen Verschlüsselung ist, dass die Länge der Daten die du mit einem asymmetrischen Schlüssel verschlüsseln kannst von der Länge des Schlüssels abhängt also ist die asymmetrische Verschlüsselung von Haus aus nur für kurze Daten geeignet. Die Generierung dieser Schlüssel ist zudem "relativ" rechenintensiv.

Daher verwendet man meistens die asymmetrische und symmetrische Verschlüsselung gemeinsam:
Alice und Bob erstellen jeweils ein asymmetrisches Schlüsselpaar und teilen sich gegenseitig den publicKey mit. Nun legen sie einen Key für symmetrische Verschlüsselung fest, verschlüsseln diesen asymmetrisch und senden ihn sich (sicher) zu. Schon haben wir eine gesicherte Verbindung.

Wichtig ist: Dies ist nur ein kurzer Abriss und gilt dem groben Verständnis. Am Ende des Tages gilt immer noch der Grundsatz "never build your own crypto", da man da sehr viel Mist bauen kann. Es gibt im Netz zigtausend Tutorials und fertige System, die man 1:1 in sein Projekt implementieren kann.

Das von dir angesprochene aspnet_regiis macht afaik auch nix andres als eine asymmetrische RSA-Verschlüsselung.

Wenn du Passwörter so ablegen willst, dass sie wieder in den Klartext übertragen werden können ist vor allem das hardening wichtig. Da solche Passwörter niemals zu 100% sicher sein können ist es wichtig den Zugriff darauf mit möglichst großen Hürden zu versehen. Also z.B. die Passwörter in eine eigene Datenbank packen auf die nur eine API-Zugriff hat deren einzige Aufgabe es ist diese Passwörter abzulegen und bereitzustellen.

2+2=5( (für extrem große Werte von 2)

S
sugar76 Themenstarter:in
69 Beiträge seit 2017
vor 5 Jahren

Also z.B. die Passwörter in eine eigene Datenbank packen auf die nur eine API-Zugriff hat deren einzige Aufgabe es ist diese Passwörter abzulegen und bereitzustellen.

Hier muss eine Authentifizierung gegenüber der API stattfinden. Es wird somit auch hier ein Token auf jedem Client-Rechner benötigt, der auch wieder gesichert werden muss ...

Es gibt im Netz zigtausend Tutorials und fertige System, die man 1:1 in sein Projekt implementieren kann.

Ich habe da leider nichts fertiges gefunden. Daher der Ansatz mit symmetrischer Verschlüsselung + aspnet_regiis.. Aber Du hast ja Recht, ich bin ja nicht der erste mit diesem Problem. Da muss es doch Lösungen geben.

S
sugar76 Themenstarter:in
69 Beiträge seit 2017
vor 5 Jahren

Wenn dein Client ausschließlich auf Windows läuft - was spräche dagegen den initialen "Dominostein" von Windows sichern zu lassen?

Hatte ich auch schon überlegt. Man könnte sogar die Dateiverschlüsselung von Windows verwenden, um den Schlüssel zu sichern. Die Anwendung läuft ja mit den User-Rechten und kann den Schlüssel lesen. Oder aber man verwendet die Data Protection API.