Passwort in MySQL-Connector verschlüsseln

[XspYroX]

Hi.

Ich habe ein Tool geschrieben (C#), welches eine MySQL-Verbindung herstellt.

Jetzt habe ich herausgefunden, dass man mit verschiedenen Methoden das Passwort, welches im Klartext im Code steckt, auslesen kann:

- die strings.exe von Microsoft TechNet

- Reverse-engineering aller Art

Natürlich könnte ich ersteres (strings.exe) verhindern, indem ich das Passwort durch verschiedene variablen zerstückle.

Aber das hilft beim reverse-engineering ja nicht wirklich.

Meine Frage ist jetzt: Wie kann ich verhindern, dass jemand das passwort für die DB ausliest?

Das Tool agiert automatisch, das Passwort muss also hinterlegt sein (es wird also keine Userabfrage gemacht).

Irgendwelche Ideen? :/

LG XspYroX

[flashpixx]

ein Passwort sollte sicher nicht "hardcoded" im Programm stehen. Du brauchst das Passwort nur beim Connect, d.h. die Variable in der das Passwort steht, muss nur ein einziges Mal vorhanden sein, nämlich beim Connect, danach kann die Variable out-of-scope gehen und damit ist das Passwort nicht mehr vorhanden.

Passwörter bzw Logindaten in einer Datei zu speichern ist nicht unbedingt besser, denn diese kann man auslesen. Natürlich kann man die Daten in die Registry (HCU) speichern, denn dieser Teil der Registry ist benutzerabhängig, aber das Passwort muss dort dann auch im Klartext stehen. Der Vorteil der Registry ist, dass man die Berechtigungen entsprechend definieren kann.

Je nach Datenbank kann man auch den Login via Zertifikate / SSH Schlüsseln machen, was durchaus mehr Schutz bietet.

Ansonsten bleibt noch die Möglichkeit den Benutzer das Passwort eingeben zu lassen. Generell gilt aber, dass das Speichern von Logindaten ein Sicherheitsrisiko ist.

[mcn]

Soweit Du die DB-Verbindung z.B. mit dem integrierten Assistenten konfiguriert hast sind die Daten des Connection-String ja in den Anwendungseinstellungen gespeichert. Somit könnest Du den Connection-String verschlüsseln (ist dann in verschlüsselter Form in der Anwendungs-Einstellungen-Datei ==> app.config? hinterlegt).

Der benötigte Namensraum wäre System.Configuration

Hoffe es hilft.

greetz

[Guybrush Threepwood]

und dann? Das Programm muss das Passwort dann ja auch wieder entschlüsseln um es verwenden zu können also muss der Schlüssel dafür auch hinterlegt sein wodurch es auch jemand anderes entschlüsseln kann.

[mcn]

Und dann ist es Verschlüsselt und muss, um verwendet werden, wieder entschlüsselt werden. Hast Du gut erkannt!

Wie bei allem was verschlüsselt ist kann es - so man denn den Schlüssel zum Entschlüsseln hat - auch entschlüsselt werden.

Mir scheint aber, mit Verlaub, Du bist mit der Materie bzw. dem Verfahren (verschlüsseln des Connection-String unter .NET) nicht (wirklich) vertraut - ich bin da auch kein Meister, soviel nur an dieser Stelle. Ich empfehle Dir aber an dieser Stelle Dich in die Thematik einzulesen (MSDN ist hier eine gute Anlaufstelle).

So Du denn dann konkrete Einwände zum verwendeten Verfahren hast, können wir gern darüber diskutieren (soweit ich der Materie mächtig bin).

greetz

Bearbeitet 12. März 2013 von mcn

[flashpixx]

Verschlüsseln von Konfigurationsinformationen mithilfe der geschützten Konfiguration

Egal ob der ConnectionString ver- oder entschlüsselt vorliegt, ist ein Zugriff möglich. Eine Verschlüsselung erhöht nur die Schwierigkeit an die Daten heran zu kommen. Eine Authentifizierung des Users an einer zentralen Instanz und dann die entsprechenden Token z.B. per Kerberos zu verteilen, ist ein in meinen Augen sinnvollerer Weg. Alternativ über entsprechende Zertifikate & Schlüssel, die man bei Bedarf zentral sperren kann. Es wird niemals 100%ige Sicherheit geben, nur halte ich das Erzeugen von Passwörtern durch den Benutzer und dann das lokale Speichern für ein potentielles Sicherheitsrisiko.

Bei Zertifikaten kann ich einmal diese zentral ausstellen und wenn es Probleme gibt, dann kann ich einzelne Zertifikate bzw. Instanzen auf dem Server sperren. Im LAN wäre in Mechanismus wie Kerberos sinnvoll, denn die Authentifizierung wird durch einen zentralen Server geregelt und alle anderen Dienste erhalten darüber dann die Information ob der User entsprechend an welchem System eingeloggt ist.

Bearbeitet 12. März 2013 von flashpixx

[Guybrush Threepwood]

ich bin da auch kein Meister, soviel nur an dieser Stelle.

Dann solltest du keine vagen Vermutungen darüber anstellen.

Im Prinzip ist es ganz einfach. Wenn du ein Programm an einen Benutzer auslieferst welches ein Passwort enthält das es verwendet um sich irgendwo ohne zutun des Benutzers zu authentifizieren hast du keine Möglichkeit zu verhindern das der Benutzer das rausbekommt.

[pr0gg3r]

Normalerweise benötigt ein Programm keinen direkten Zugriff auf eine Datenbank sondern kommuniziert mit einem Serverprogramm, das mit der DB verbunden ist:

Client <---> Serverprogramm <---> DB-Server

[flashpixx]

Normalerweise benötigt ein Programm keinen direkten Zugriff auf eine Datenbank sondern kommuniziert mit einem Serverprogramm, das mit der DB verbunden ist

Also das wäre mir neu. Es gibt zwar mehrschichtige Architekturen, aber an irgendeiner Steller muss nun mal ein Connect zur Datenbank statt finden und dafür müssen in irgendeiner Form Authentifizierungsdaten hinterlegt sein.

In Deinem Beispiel wäre dies dann das "Serverprogramm". Deine Aussage ist somit falsch.

[pr0gg3r]

Also das wäre mir neu. Es gibt zwar mehrschichtige Architekturen, aber an irgendeiner Steller muss nun mal ein Connect zur Datenbank statt finden und dafür müssen in irgendeiner Form Authentifizierungsdaten hinterlegt sein.

In Deinem Beispiel wäre dies dann das "Serverprogramm". Deine Aussage ist somit falsch.

Nicht jedes Programm muss das so machen. Sobald ich als Benutzer eine Datenbank angeben kann, kann man mit der Datenbank direkt verbinden. Sobald der Benutzer aber nichts von der Datenbankverbindung "wissen" soll, braucht man ein extra Programm dazwischen. Alles andere ist unsicher.

Nehmen wir als einfaches Beispiel mal WoW: Dort verbindest du dich nicht direkt mit der Spieldatenbank. Wäre auch schlecht, dann könntest du auf viel zu viel zugreifen. Du verbindest dich mit einem Server, kommunizierst mit ihm über TCP oder UDP und dieser dann mit der DB. Der eigentliche Client greift in diesem Fall aber niemals auf die DB direkt zu.

Die Frage ist ja, um was für ein Programm es sich handelt. Kann ich als Benutzer selber eine Datenbank einstellen? Gibt es für das Programm nur eine einzelne Datenbank auf die alle Clients mit den selben Rechten zugreifen sollen? Dann kann man direkt mit der DB verbinden und das Passwort irgendwie verstecken, wobei man auch dabei an das Passwort rankommt, wenn man den Arbeitsspeicher ausliest o.ä.

Soll aber Sicherheit im Vordergrund stehen, verschiedene Benutzer mit verschiedenen Rechten verhanden sein, dann führt kein sicherer Weg um eine eigene Serverapplication vorbei.

[XspYroX]

Also der Grund, weshalb die Passworteingabe nicht durch den User erfolgen kann, ist folgender:

Das Tool ist ein Dienst, der unter Windows im Hintergrund läuft.

Dieser Dienst stellt direkt die DB-Verbindung her, verbindet sich also mit keinem Server-Dienst.

Der Rechner, auf dem dieser Dienst läuft, wird bei Bedarf an dritte (Kunden) ausgeliehen.

Daher haben diese dritten, wenn Sie es drauf anlegen, auch Adminrechte auf dem System (gibt ja genügend wege wie z.B. ne Boot-cd u.s.w.) und können auf den Dienst zugreifen, also auf die Datei.

Dadürch könnten Sie, WENN sie es drauf anlegen, auch das Programm Reverse-Entwickeln und versuchen an das DB-PS zu kommen.

Wir (ich und ein Kollege) wollen das Problem jetzt folgendermaßen angehen, dass im Vorfeld in der DB für jeden PC ein eigener DB-User angelegt wird. Dieser bekommt als user-id die mac-adresse des LAN-Adapters des Rechners. Das Passwort wird ein md5 aus der macadresse und einem salt-zusatz.

Damit steht das passwort nicht im code, sondern kann nur durch genaues reversen herausgefunden werden (indem man die methode herausbekommt, die die MAC ausliest und dann den Salt).

Selbst, wenn dann das pw herausgefunden wird, so können wir diesen einen zugang sperren, ohne die anderen ausgeliehenen rechenr auszusperren.

Außerdem könnte man im programm/dienst einbauen, das bei jeder DB-verbindung ein ganz bestimmtes flag gesetzt wird.

Wenn dann eine DB-Verbindung aufgebaut wird, OHNE dass dieses flag gesetzt wird, so kann man sich das anzeigen lassen.

Soweit die Theorie. Der Kollege und ich sind dran das auszuarbeiten.

edit: Hab grad erst den letzten Eintrag gelesen. Das Tool greift per INSERT, UPDATE und DELETE auf die DB zu. Es schreibt, sozusagen, eine Art Log, was der User mit dem PC macht bzw. läft eventuell automatisch dinge herunter, wenn etwas bestimmtes auf dem rechner passiert u.s.w.

Gibt es bzgl. dieser Theorie noch Vorschläge?

Viele Grüße schonmal

XspYroX

Bearbeitet 12. März 2013 von XspYroX

[flashpixx]

Das Passwort wird ein md5 aus der macadresse und einem salt-zusatz.

Damit steht das passwort nicht im code, sondern kann nur durch genaues reversen herausgefunden werden (indem man die methode herausbekommt, die die MAC ausliest und dann den Salt).

Das ist im Grunde nicht schwer, wenn der Code nicht explizit geschützt ist. Außerdem ist ein Hash nicht umkehrbar (siehe dazu die mathematischen Zusammenhänge), d.h. das Passwort kannst Du aus einem Hash nicht zurück rechnen.

Selbst, wenn dann das pw herausgefunden wird, so können wir diesen einen zugang sperren, ohne die anderen ausgeliehenen rechenr auszusperren.

Warum nutzt Du für so etwas keine Zertifikate? Sperre über eine Revoke Liste die Zertifikate im Server, d.h. nur gültige Zertifikate können sich anmelden und Du hast sogar ein Ablaufdatum drin.

edit: Hab grad erst den letzten Eintrag gelesen. Das Tool greift per INSERT, UPDATE und DELETE auf die DB zu. Es schreibt, sozusagen, eine Art Log, was der User mit dem PC macht bzw. läft eventuell automatisch dinge herunter, wenn etwas bestimmtes auf dem rechner passiert u.s.w.

Warum soll der Dienst direkt auf die Datenbank zugreifen und nicht einen Webservice nutzen. Damit können auch nur durch den WS definierte Funktionen ausgeführt werden und ein direkter Zugriff per SQL Statements ist unterbunden. Den WS per SSL und Authentifizierung per Zertifikate absichern, dann ist kein Passwort o.ä. nötig und bei Bedarf kann das Zertifikat einfach auf dem Server, der den Webservice stellt deaktiviert werden. Damit kann der Rechner dann nicht mehr auf den WS zugreifen.

Nur der Webservice hat dann Zugriff auf die Datenbank(en) und generiert die SQL Statements.

Dein Vorschlag klingt etwas nach Fummelei, mach eine ordentliche Architektur und dann darauf aufbauend eine passende Authentifizierung und Verschlüsselung.

[mcn]

Verschlüsseln von Konfigurationsinformationen mithilfe der geschützten Konfiguration

[...] Alternativ über entsprechende Zertifikate & Schlüssel, [...]

Das von mir vorgeschlagene System arbeitet (so man es dementsprechend macht) mit Zertifikaten (siehe MSDN zu diesem Thema ==> http://msdn.microsoft.com/de-de/library/dtkwfdky%28v=vs.80%29.aspx)

Dann solltest du keine vagen Vermutungen darüber anstellen. [...]

Ich habe lang überlegen müssen, ob ich auf diese Aussage noch etwas schreibe. Will es mir aber nicht nehmen lassen, ganz einfach weil ich mich bissl angepieselt fühle...

Sorry an dieser Stelle, wenn's bissl offtopic ist!

Die Tatsache auf einem Gebiet kein Meister, Fachmann etc. zu sein schliesst nicht die Tatsache aus diesbezüglich Vermutungen zu diesem anzustellen! Auch habe keine "vagen Vermutungen" angestellt. Weiterhin schrieb ich dass ich in diesem Thema kein Meister bin - worauf sich das konkret bezog habe ich an dieser Stelle offen gelassen. Aber um Dir den Spielraum zu nehmen: Ich bin kein Meister was die Thematik Zertifikatspeicher angeht - das ist nämlich imho ein Admin-Thema. Und ich bin nunmal kein Admin, sondern habe Entwickler gelernt. Und dieses Admin-Thema, Zertifikatspeicher, wird im Rahmen dieses Verfahrens durchaus berührt. Ob und wie der von mir unterbreitete Lösungsweg für das gestelle Problem praktikabel ist, das ist wohl - letztendlich - eine Entscheidung, die der TS bzw. der Entwickler beantworten muss/sollte.

Und im Gegensatz zu Dir hab ich auch nicht irgendeinen Stuss gepostet, nur um was geschrieben zu haben! Wenn Du Dich, nach meiner Aufforderung/Bitte/wie auch immer, nur ein ganz wenig (z.B. in der MSDN) schlau gelesen hättest, dann wäre Dir, ich unterstelle Dir mal so viel Intelligenz, die Abwegigkeit Deiner Aussage(n) bzgl. dieser Thematik ganz sicher aufgefallen.

Nur zur Erinnerung: Der TS hat um Vorschläge gebeten, wie seine Problematik gelöst werden kann. Und der von mir vorgeschlagene Weg tut das durchaus! Deine Aussage in Post #4 tut das Allerdings nicht. Er ist, genau genommen, in keinster Weise konstruktiv. Bemängelt er doch "nur" eine grundsätzliche Schwachstelle bzgl. Verschlüsselung (wenn das Passwort - in welcher Form auch immer - bekannt ist, dann...), weist aber keinen Lösungsweg auf.

Und ja: Mit entsprechender wie auch immer gearteter Energie kann der Benutzer das Passwort dann sicher auch herausbekommen. So wie auch Dein, hoffentlich vergebenens, Passwort zur Anmeldung ans von Dir genutzte Computersystem, bei Aufwand der entsprechenden Energie, "geknackt", "gehackt", "geklaut" (oder wie auch immer) werden kann! Oder das Passwort, mit dem Deine Email-Box gesichert ist. Selbst die PIN deiner Kontokarte lässt sich "knacken". Wenn ich genug Glück habe, dann ist schon die erste zufällig eingegebene Kombination, die ich einfach mal versuche, die Richtige!

Sorry die direkten Worte. Aber es nervt mich einfach, wenn wer irgendwelchen Müll schreibt, ohne sich vorher des Themas auch nur in irgendeiner Weise zu nähern. Und dann noch, trotz Aufforderung sich der Thematik zu bemächtigen, weiter Stuss hinterher schreibt. Und Dein Beitrag (#4) lässt für mich einfach nur diesen Schluss zu. Warum? Das können wir gern in einem gesonderten Thread diskutieren.

[...] Das Tool ist ein Dienst, der unter Windows im Hintergrund läuft.

XspYroX

Ist doch super! Genau dafür eignet sich das von mir vorgeschlagene Verfahren! Das Passwort wird mittels eines Zertifikat verschlüsselt. Was spricht dagegen?

Eure jetzige Planung da was mit MAC-ID etc. zu erstellen hat für mich eine Schwachstelle: Es wird in dem Moment obsolet, in dem die Netzwerkkarte (aus welchen Gründen auch immer) durch eine andere getauscht wird und somit eine neue MAC-ID hat. Das heisst dann nacharbeiten, nachadministrieren etc.

Bearbeitet 13. März 2013 von mcn

[Guybrush Threepwood]

ganz einfach weil ich mich bissl angepieselt fühle...

Das du beleidigt bist wenn dir jemand wiederspricht solltest du mal überdenken.

Ob und wie der von mir unterbreitete Lösungsweg für das gestelle Problem praktikabel ist, das ist wohl - letztendlich - eine Entscheidung, die der TS bzw. der Entwickler beantworten muss/sollte.

Der TE fragte wie er verhindern kann das jemand an ein Passwort das in einer Anwendung steckt die er jemand anderem gibt herankommt und das geht nicht solange die Anwendung das auch noch verwenden können soll.

Er kann nur versuchen das etwas schwieriger bzw. weniger offensichtlich zu machen, jemand mit ein bisschen Fachkenntnis kommt da aber trotzdem schnell dran. Natürlich ist es seine Entscheidung wie er es am Ende macht.

Und ja: Mit entsprechender wie auch immer gearteter Energie kann der Benutzer das Passwort dann sicher auch herausbekommen.

Ja, mit sehr viel weniger als du dir allerdings vorstellst. Im Notfall muss er das Programm einfach nur debuggen und sieht es dann.

Die Verfahren an die du wahrscheinlich denkst (wie das automatische verschlüsseln der web.config) machen das Ganze nur dadurch sicherer das das Ganze auf einem Server läuft auf dem die Berechtigungen gesetzt sind das nur vertrauenswürdige Leute auf entsprechende Resourcen zugreifen können.

Bei einem System das an einen potentiellen Angreifer ausgeliefert wird ist das aber nicht der Fall, bzw. falls doch kann er es einfach umstellen und hat dann alles zur verfügung was er braucht.

Wenn Du Dich, nach meiner Aufforderung/Bitte/wie auch immer, nur ein ganz wenig (z.B. in der MSDN) schlau gelesen hättest, dann wäre Dir, ich unterstelle Dir mal so viel Intelligenz, die Abwegigkeit Deiner Aussage(n) bzgl. dieser Thematik ganz sicher aufgefallen.

Wenn du nach meiner Aussage auch nur ein bisschen darüber nachgedacht hättest dann wäre dir aufgefallen das das nicht funktionieren kann.

So wen bringen solche Aussagen jetzt weiter?

Außerdem solltest du es vermeiden andere Aussagen als Müll, Stuss oder ähnliches zu bezeichnen.

Warum soll der Dienst direkt auf die Datenbank zugreifen und nicht einen Webservice nutzen. Damit können auch nur durch den WS definierte Funktionen ausgeführt werden und ein direkter Zugriff per SQL Statements ist unterbunden. Den WS per SSL und Authentifizierung per Zertifikate absichern, dann ist kein Passwort o.ä. nötig und bei Bedarf kann das Zertifikat einfach auf dem Server, der den Webservice stellt deaktiviert werden. Damit kann der Rechner dann nicht mehr auf den WS zugreifen.

Nur der Webservice hat dann Zugriff auf die Datenbank(en) und generiert die SQL Statements.

Ich denke auch das das der Beste Weg sein wird. Dadurch stellst du zumindest schonmal sicher das niemand was auf der DB macht das du nicht über den Webservice gestattest (sofern du keine Lücke für SQL Injection oder sowas hast ) und kannst einfach bestimmte Clients sperren.

Bearbeitet 13. März 2013 von Guybrush Threepwood

[mcn]

Das du beleidigt bist wenn dir jemand wiederspricht solltest du mal überdenken.

1. Angepieselt != Beleidigt.

2. WENN Du denn mal widersprochen hättest, was Du ja nicht hast!

Den Rest werd ich mit Dir nicht weiter diskutieren, denn mir scheint Du bist lernresistent.

Arbeitsreichen Tag wünsch ich noch.

Bearbeitet 13. März 2013 von mcn

[flashpixx]

@mcn: Dein Vorschlag hat einen entscheidenden Designfehler, nämlich, dass jeder Client direkt auf die Datenbank zugreift. Diesen Fehler beseitigst Du nicht durch eine Verschlüsselung - egal welcher Art - auf des Connectionstrings.

Bei einem Zertifikat speichere ich lediglich dieses auf dem Client und zeige dieses dann vor, um zu authentifizieren.

Zusätzlich ist der Zugriff auf die DB durch einen Rechner (bzw. Rechnerpool) definiert, denn nur der / die Rechner, die den WS stellen, müssen auf die Datenbank zugreifen und ggf auch nur mit einem Useraccount.

Weiterhin habe ich mit einem WS die Möglichkeit eine unabhängige Verwaltung der Accounts, die ihn nutzen zu schaffen, so dass dieser keine physisch angelegten User benötigt.

Den Rest werd ich mit Dir nicht weiter diskutieren, denn mir scheint Du bist lernresistent.

Warum hast Du nicht den Vorschlag mit einem WS und/oder mit Zertifikaten gemacht? Du hast Dich auf die Lösung einer Verschlüsselung eingeschossen, das ist in meinen Augen lernresistent, denn damit bekommst Du das Problem nicht gelöst. Die Lösung liegt nicht darin eine Verschlüsselung zu verwenden, d.h. das was in der MSDN steht, sondern die Architektur des Systems so zu verändern, dass man eben den Connectionstring gar nicht mehr braucht.

Dein Vorschlag das Passwort mittels Zertifikat zu verschlüsseln, wobei ich mich frage wie das geschehen soll, ist im Grunde nicht besser, denn ich muss den Connectionstring vor der Verwendung wieder entschlüsseln, d.h. es ist die gleiche Problematik, wenn ich ein Passwort verwende.

Du hast ebenso wenig verstanden, dass das Problem nicht in der Verschlüsselung eines Datenblock geht, sondern es geht hier eigentlich um die Authentifizierung eines Clients, d.h. lediglich zu prüfen, ob der Client berechtigt ist Daten zu senden und wer dieser Client ist.

[XspYroX]

Kinder, jetzt kriegt euch mal wieder ein

Wir sitzen alle im selben Boot

Wir sind Programmierer / Entwickler / Interessiert, die sich untereinander austauschen wollen.

Ich habe die Vorschläge gelesen und werde mir dazu Gedanken machen

Die Anstöße waren echt gut, jetzt hab ichen Überblick der Möglichkeiten und kann mir daraus die für mich beste Lösung basteln

Vielen Lieben Dank an euch alle =)

LG XspYroX