Laden...

Authentifizierung bei Programmstart mit Kennwort

Erstellt von DerColaTrinker vor 9 Jahren Letzter Beitrag vor 9 Jahren 5.521 Views
D
DerColaTrinker Themenstarter:in
6 Beiträge seit 2014
vor 9 Jahren
Authentifizierung bei Programmstart mit Kennwort

Hallo zusammen,

ich arbeite an einem Programm das innerhalb meines Unternehmens an mehreren Standorten eingesetzt werden soll. Dieses Programm besitzt auch Zugriff auf eine SQL Datenbank. Da sich die Verbindungszeichenfolge ändern kann, habe ich mich entschieden die Zeichenfolge nicht in mein Programm einzubinden, sondern sie aus einer Konfigurationsdatei zu laden.

Nun suche ich nach einem Weg diese Datei unlesbar zu machen. Da die Verbindungszeichenfolge auch das Kennwort zu Datenbank enthalten wird.

Spontan fällt mir die Möglichkeit ein, die Datei mit einem Kennwort zu verschlüsseln. Dieses Kennwort stellt auch den Zugriff auf das Programm dar.

Die Konfigurationsdatei würde also mit einem initial Kennwort von einem Administrator ausgestellt und an den Benutzer weitergegeben ( via Mail oder persönlich ).

Dazu meine Fragen:

  1. Ist das eine durchaus übliche Methode?
  2. Welchen Verschlüsselung-Algo sollte ich dazu verwenden?

Vielen dank im voraus.

4.221 Beiträge seit 2005
vor 9 Jahren

Wieso verwendest Du nicht Windows-Authentifizierung ?

Auswählen eines Authentifizierungsmodus

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

D
DerColaTrinker Themenstarter:in
6 Beiträge seit 2014
vor 9 Jahren

Leider geizen die Kollegen Datenbank-Administratoren mit Logins. Eine Windows-Authentifizierung kommt nicht in frage.

Die allgemeine Handhabung in unseren Unternehmen ist, das jedes Tool ein Datenbankzugriff erhält, nicht jeder User. Was mich ja zu meinen oben aufgeführten Fragen führt.

F
10.010 Beiträge seit 2004
vor 9 Jahren
D
DerColaTrinker Themenstarter:in
6 Beiträge seit 2014
vor 9 Jahren

danke für den Link und der Antwort aber ich glaube das meine Fragen falsch verstanden wurden. Ich bin nicht auf der suche nach Code-Schnippseln oder wie ich zu machen habe, eher an Erfahrungsberichten oder einer Einschätzung ob dies eine gute Idee ist.

16.806 Beiträge seit 2008
vor 9 Jahren

Eigentlich bleibt Dir für eine _wirklich sichere _Variante - außer Logins direkt auf den SQL Server - eigentlich nur, dass Du einen Service dazwischen schaltest.

Sprich die Clients verbinden sich nicht mit der Datenbank, sondern einem zentral auf einem Server installierten Service (zB WCF).
Über den Service kannst Du dann die Windows-Authentifizierung auslesen und über ein eigenes Management kontrollieren und der Service kommuniziert dann auch mit der Datenbank.

Eine wirklich sichere, lokale Variante gibt es so nicht.
Spätestens wenn jemand die Anwendung von IL zurück auf .NET Code konvertiert und sich den Mechanismus anschaut ist die Hürde der "verschlüsselten Datei" geknackt.
Das dürfte übrigens auch in den Links von Fzelle stehen.

Und: sowas überlegt man sich eigentlich bereits in der Planungsphase.

D
DerColaTrinker Themenstarter:in
6 Beiträge seit 2014
vor 9 Jahren

Eigentlich bleibt Dir für eine _wirklich sichere _Variante - außer Logins direkt auf den SQL Server - eigentlich nur, dass Du einen Service dazwischen schaltest.

Okay, das klingt nach einer Sinnvollen alternative.

Eine wirklich sichere, lokale Variante gibt es so nicht.
Spätestens wenn jemand die Anwendung von IL zurück auf .NET Code konvertiert und sich den Mechanismus anschaut ist die Hürde der "verschlüsselten Datei" geknackt.

Auch wenn das Kennwort nicht bekannt ist?

Und: sowas überlegt man sich eigentlich bereits in der Planungsphase.

Nun gut, das Programm besteht bereits. So wie ist das verstehe, wurde das Programm wohl eher "inoffiziell" verwendet. Da es jetzt, wie oben beschrieben, an weiteren Standorten in betrieb gehen soll, nimmt es einen "offiziellen" Charakter an. Das ruft den Datenschutzbeauftragten auf den Plan und dem will ich jetzt eine gute Lösung bieten.

16.806 Beiträge seit 2008
vor 9 Jahren

Auch wenn das Kennwort nicht bekannt ist?

In der Theorie: natürlich. Kommt aber natürlich auch immer auf die Verschlüsselungsart, Sicherheit etc an.
Klar kannst Du das so verwenden, da es eine Hürde für die normalen Nutzer ist - aber halt auch keine Große.

Wenn er ja eh schon das Passwort hat muss er nur noch rausfinden, wie verschlüsselt wird.
Das kann er Kinderleicht mit DeKompilierung.

Zum Thema Encryption von Config-Files findest Du hunderte Treffer bei Google, zB Encrypting the app.config File for Windows Forms Applications
Is app.config file a secure place to store passwords?

N
135 Beiträge seit 2006
vor 9 Jahren

Wenn der Endanwender das Passwort zum starten der Anwendung hat, hat er auch alles was er braucht. Die nötige Methode zum entschlüsseln hast Du doch dann direkt in Deiner Anwendung 😉
Evtl sogar noch Public 👅

D
DerColaTrinker Themenstarter:in
6 Beiträge seit 2014
vor 9 Jahren

Wenn der Endanwender das Passwort zum starten der Anwendung hat, hat er auch alles was er braucht. Die nötige Methode zum entschlüsseln hast Du doch dann direkt in Deiner Anwendung 😉
Evtl sogar noch Public 👅

Da muss ich zustimmen. Also ist die beste Möglichkeit ein Web Service, der alle Funktionen bereit stellt.

49.485 Beiträge seit 2005
vor 9 Jahren

Hallo DerColaTrinker,

zu der Frage, ob man bezüglich der Sicherung der Zugangsdaten etwas gewinnt, wenn man statt eines direkten Zugriff auf die Datenbank noch einen Webservice dazwischenschaltet:

Also ist die beste Möglichkeit ein Web Service, der alle Funktionen bereit stellt.

Das beschränkt den Zugriff aber "nur" auf die erlaubten Operationen, nämlich die, die der Webservice bereitstellt und vielleicht noch auf die erlaubten Parameter, die der Webservice verifizieren kann.

Beim Schutz des Zugriffs auf den Webservice hat man wieder das gleiche Grundproblem wie beim Schutz des Zugriffs auf eine Datenbank, nämlich dass die Zugriffsdaten ausgelesen werden können, wenn sie in der lokalen Anwendung oder einer Config-Datei enthalten sind, selbst wenn die Zugriffsdaten verschlüsselt oder verschleiert gespeichert sind.

Das bedeutet insbesondere, dass auch ein zwischengeschalteter ein Webservice per se nicht das Problem löst, den Zugriff auf bestimmte Personen bzw. bestimmte Programme zu beschränken.

Der einzige Weg, den Zugriff auf bestimmte Personen zu beschränken, ist, nur den berechtigen Personen die Zugriffsdaten für den Dienst (egal ob Datenbank oder Webservice) zur Verfügung zu stellen und diese Zugangsdaten nicht in der lokalen Anwendung zu hinterlegen.

Betrachten wir noch den Fall, dass man den berechtigten Personen nicht direkt die Zugriffsdaten für den Dienst bekannt geben möchte, sondern diese in der lokalen Anwendung mit einem extra Passwort stark verschlüsselt speichert, wobei dieses Passwort nur den berechtigten Personen bekannt gegeben wird und sie dieses jedes Mal nach dem Start der Anwendung und vor dem ersten Zugriff eingeben müssen. Dann können zwar fremde Angreifer, die nur die Anwendung (bzw. deren Config-Datei) besitzen, die Zugangsdaten nicht mehr ermitteln(*), aber den berechtigten Personen ist weiterhin möglich, die Zugangsdaten des Dienstes zu ermitteln, da sie die Verschlüsselung in Kenntnis des Passwortes und des in der lokalen Anwendung notwendigerweise enthalten Entschlüsselungsalgorithmus rückgängig machen können.

Wie man es auch dreht, wenn die Zugangsdaten in der lokalen Anwendung enthalten sind, können diese mit den nötigen Kenntnissen und dem nötigen Aufwand prinzipiell ausgelesen werden. Durch das Zwischenschalten eines Webservices verschiebt man das Problem also im Wesentlichen nur von der Sicherung des Zugriffs auf die Datenbank zur Sicherung des Zugriffs auf den Webservice, ohne etwas prinzipiell zu ändern.

Anders sieht es aus, wenn die Berechtigung für den Zugriff auf den Dienst (wieder egal ob Datenbank oder Webservice) z.B. über die Windows Authentifizierung realisiert werden kann. Klar, wenn du aufgrund der Gegebenheiten in deiner Firma die Windows Authentifizierung zwar nicht für Datenbanken, aber für einen Webservice verwenden kannst, dann (und nur dann) hat ein Webservice für dich einen echten Vorteil. Vielen Dank für diesen Hinweis von Abt.

herbivore

(*) Es sei denn es gelingt ihnen die starke Verschlüsselung zu brechen, was bei starken Passworten bzw. -phrasen üblicherweise sehr viel Aufwand an Zeit und Geld erfordert, sofern es überhaupt gelingt.

Suchhilfe: 1000 Worte