Hi, ich habe mir ein kleines, kompaktes C#-Programm geschrieben, was eine Verbindung zu einem Server aufbaut und Daten austauscht. Das ganze läuft bis jetzt alles in Main() ab. Andere Klassen gibt es nicht. In der Main() sind auch die Zugangsdaten als String hinterlegt. Angenommen, ich gebe nur die *.exe weiter, und auf dem PC wird ein Programmfehler ausgelöst, sodass VisualStudio debuggen "möchte", besteht dann die Gefahr, dass man die Zugangsdaten zu Gesicht bekommt? Wie verstaue ich die Zugangsdaten (Stringzuweisungen) am besten in eine eigene Sourcecodedatei, dass man bei normaler Programmbearbeitung die Daten nicht sieht, dass man aber auch durch Manipulation der *.exe nicht dran kommt?
Du solltest die Zugangsdaten verschlüsselt ablegen und erst zur Laufzeit decodieren. Strings werden ja in dem Exe-File abgelegt. Wenn die die EXE mit einem Editor aufmachst, dann wirst du die Zugangsdaten jetzt schon sehen. Nicht erst, wenn du debuggst. VG Thomas
Thomas schrieb: > Wenn die die EXE mit einem > Editor aufmachst, dann wirst du die Zugangsdaten jetzt schon sehen. > Nicht erst, wenn du debuggst. Oh, vielen Dank für den Hinweis!! Das ist ja wirklich so. Auch wenn mit Leerzeichen zwischen jedem Zeichen, aber ich kann die Daten klar lesen. Das darf natürlich nicht sein. Hilft das verschlüsselte Ablegen auch, wenn das Programm debuggt wird? Wenn ich die *.exe weitergebe, muss ich sicher sein, dass man nicht an die Daten kommt. Womit/wie würdest du denn verschlüsseln?
"Securing Connection Strings" http://msdn.microsoft.com/en-us/library/89211k9b(VS.80).aspx > Hilft das verschlüsselte Ablegen auch, wenn das Programm debuggt wird? Nein, unabhängig davon, ob das eine natives Programm in C/C++ oder ob das managed in C#, Java, sonst was ist, wenn die (Zugangs-)Daten auch nur an einer Stelle unverschlüsselt verarbeitet werden, können sie dort auch mitgelesen werden.
Arc Net schrieb: > "Securing Connection Strings" > http://msdn.microsoft.com/en-us/library/89211k9b(VS.80).aspx Da habe ich jetzt mal bisschen "rumgeblättert" und mir einiges angeschaut, aber wirklich weiterhelfen tut mir das leider nicht. Meintest Du mit Arc Net schrieb: > Nein, unabhängig davon, ob das eine natives Programm in C/C++ oder ob > das managed in C#, Java, sonst was ist, wenn die (Zugangs-)Daten auch > nur an einer Stelle unverschlüsselt verarbeitet werden, können sie dort > auch mitgelesen werden. auch, dass jede Verschlüsselung durch das debuggen wieder entschlüsselt werden kann?
*GAST* schrieb: > Arc Net schrieb: >> "Securing Connection Strings" >> http://msdn.microsoft.com/en-us/library/89211k9b(VS.80).aspx > > Da habe ich jetzt mal bisschen "rumgeblättert" und mir einiges > angeschaut, aber wirklich weiterhelfen tut mir das leider nicht. Wenn es nur um einzelne Strings geht, kann man z.B. auch so was machen http://weblogs.asp.net/jgalloway/archive/2008/04/13/encrypting-passwords-in-a-net-app-config-file.aspx > auch, dass jede Verschlüsselung durch das debuggen wieder entschlüsselt > werden kann? Nein, "wenn die (Zugangs-)Daten auch nur an einer Stelle unverschlüsselt verarbeitet werden, können sie dort auch mitgelesen werden.". Werden sie nirgends entschlüsselt, können sie auch nicht (zumindest wenn es richtig gemacht wurde) in annehmbarer Zeit entschlüsselt werden.
Leider bin ich noch nicht richtig weitergekommen. Ich möchte das ganze jetzt anhand eines kurzem Mailprogramms testen, welches System.Net.Mail nutzt. Dort gebe ich auch die Benutzerdaten ein, und diese sollen möglichst sicher sein. Wegen dem Debugging habe ich herausgefunden, dass ich scheinbar nur die Konfiguration auf Release stellen muss, und schon lässt es sich im Fehlerfalle nicht mehr debuggen, sodass man an sensible Daten kommt. Die mir bekannte, unsicherste Stelle ist dann, wie hier freundlicherweise beschrieben, das Öffnen der *.exe mit dem Editor. Das möchte ich primär beheben. Danach möchte ich noch sicher gehen, dass während der Ausführung kein anderes Programm an die Daten kommt.
*GAST* schrieb: > Leider bin ich noch nicht richtig weitergekommen. Ich möchte das ganze > jetzt anhand eines kurzem Mailprogramms testen, welches System.Net.Mail > nutzt. Dort gebe ich auch die Benutzerdaten ein, und diese sollen > möglichst sicher sein. Wenn der Server kein SSL und TLS unterstützt wandern die Daten unverschlüsselt durchs Netz... > Wegen dem Debugging habe ich herausgefunden, dass ich scheinbar nur die > Konfiguration auf Release stellen muss, und schon lässt es sich im > Fehlerfalle nicht mehr debuggen, sodass man an sensible Daten kommt. DbgClr, WinDbg und andere können das problemlos. > Die > mir bekannte, unsicherste Stelle ist dann, wie hier freundlicherweise > beschrieben, das Öffnen der *.exe mit dem Editor. > Das möchte ich primär beheben. Wie das u.a. möglich ist steht hier schon an verschiedenen Stellen. > Danach möchte ich noch sicher gehen, dass während der Ausführung kein > anderes Programm an die Daten kommt. Das ist nur dann weitestgehends möglich, wenn das Programm auf einem entsprechend geschützten und konstruierten Mikrocontroller läuft. Auf allen "normalen" Betriebssystemen (*nix, BSD, OSX, Windows, etc.) ist es möglich das Programm zu debuggen und somit an die Daten zu kommen (wenn diese irgendwann entschlüsselt vorliegen).
Such mal nach einem Decompiler für C#, dann weißt du was da wirklich geht. Aber generell kann man sagen, dass alles was du in ein Programm schreibst, irgendwann jeder lesen kann irgendwann in einer annehmbarer Zeit). Durch denke da lieber mal dein Sicherheitskonzept. Bzw beschreibe was du vor hast
raketenfred schrieb: > Durch denke da lieber mal dein Sicherheitskonzept. > > Bzw beschreibe was du vor hast Ein großes Steuerprogramm läuft auf einem PC und soll bei bestimmten Ereignissen mein C#-Programm aufrufen, welches eine E-Mail versendet. Absender, Empfänger, Zugangsdaten etc. sind immer gleich. Es ist also eine kleine *.exe, die bei Aufruf eine Mail absendet. Diese *.exe liegt ungeschützt auf dem Steuer-PC, so dass jeder Anwender sie auch manuell öffnen kann, was auch nicht stört. Aber das ganze soll schon so sicher sein, das man nicht an die Zugangsdaten kommt.
*GAST* schrieb: > raketenfred schrieb: >> Durch denke da lieber mal dein Sicherheitskonzept. >> >> Bzw beschreibe was du vor hast > > Ein großes Steuerprogramm läuft auf einem PC und soll bei bestimmten > Ereignissen mein C#-Programm aufrufen, welches eine E-Mail versendet. > Absender, Empfänger, Zugangsdaten etc. sind immer gleich. > Es ist also eine kleine *.exe, die bei Aufruf eine Mail absendet. > > Diese *.exe liegt ungeschützt auf dem Steuer-PC, so dass jeder Anwender > sie auch manuell öffnen kann, was auch nicht stört. Aber das ganze soll > schon so sicher sein, das man nicht an die Zugangsdaten kommt. Die Zugangsdaten für was genau? Den Mailserver? Sind die überhaupt schutzwürdig, sprich kann man damit irgendwas böses anstellen was man nicht auch so schon anstellen könnte? Ansonsten: es ist nicht möglich - prinzipiell nicht - einem Programm Daten zur Verfügung zu stellen die ein Nutzer mit entsprechenden Rechten und genug Zeit nicht aus dem Programm extrahieren könnte. Nicht ohne die jetzt benutzten Rechnerarchitekturen komplett über den Haufen zu schmeissen.
Jasch schrieb: > Die Zugangsdaten für was genau? Den Mailserver? Sind die überhaupt > schutzwürdig, sprich kann man damit irgendwas böses anstellen was man > nicht auch so schon anstellen könnte? Ja, für den Mailserver. Also da steht der Google-smtpserver drin, meine Mailadresse, Port und Passwort. Jeder der das bekommt, kann sich damit einloggen und alles machen. Jasch schrieb: > Ansonsten: es ist nicht möglich - prinzipiell nicht - einem Programm > Daten zur Verfügung zu stellen die ein Nutzer mit entsprechenden Rechten > und genug Zeit nicht aus dem Programm extrahieren könnte. Nicht ohne die > jetzt benutzten Rechnerarchitekturen komplett über den Haufen zu > schmeissen. Dann würde ich Euch als Programmierer mit mehr Erfahrung doch mal fragen, wie ihr so ein kleines Programm aufbauen würdet. Das alles seine Sicherheitslücken hat, ist mir schon klar, ich benutze ja auch Outlook bzw. Thunderbird. Da kommt man sicherlich auch irgendwie an die Daten. Mir ist nur wichtig, das ich keine Lösung wähle, die offensichtlich für die Tonne und unsicher ist. Ich will kein schlechtes Gewissen haben, wenn ich das Programm auf den Rechner lege. Die meisten Endnutzer werden das auch höchstens mal anklicken, oder verursachen ein Ereignis, welches dieses Programm aufruft. Wenn aber doch mal jemand mit zu viel Zeit auf dumme Gedanken kommt, sollte er es nicht zu leicht haben. Ich kenne mich zu wenig aus, um beurteilen zu können, wie aufwändig die Daten mit Thunderbird gespeichert werden, aber so eine Sicherheit reicht auf jeden Fall....
*GAST* schrieb: > Ja, für den Mailserver. Also da steht der Google-smtpserver drin, meine > Mailadresse, Port und Passwort. Jeder der das bekommt, kann sich damit > einloggen und alles machen. Wenn du nur an deine google adresse schicken willst, dann geht das auch ohne Password.
*GAST* schrieb: > Jasch schrieb: >> Die Zugangsdaten für was genau? Den Mailserver? Sind die überhaupt >> schutzwürdig, sprich kann man damit irgendwas böses anstellen was man >> nicht auch so schon anstellen könnte? > > Ja, für den Mailserver. Also da steht der Google-smtpserver drin, meine > Mailadresse, Port und Passwort. Jeder der das bekommt, kann sich damit > einloggen und alles machen. Das ein unbedarfter Anwender einen entsprechenden Debugger zur Hand hat, ist schon relativ unwahrscheinlich. Wenn er allerdings einen Wireshark zur Hand hat sieht die Sache für dich gleich noch viel unangenehmer aus: Denn irgendwann muss die Mail raus. Per TCP/IP. Und Wireshark liest das mit. > Dann würde ich Euch als Programmierer mit mehr Erfahrung doch mal > fragen, wie ihr so ein kleines Programm aufbauen würdet. Gar nicht. Den String soweit unkenntlich machen, dass er nicht gleich bei einem Speicherdump auffällt. zb alle Bytes mit 0xAA ver-xodern. Bei deinem Mail Provider einen extra Account nur dafür einrichten. Wenn den jemand hackt, ist nicht viel kaputt. > dieses Programm aufruft. Wenn aber doch mal jemand mit zu viel Zeit auf > dumme Gedanken kommt, sollte er es nicht zu leicht haben. Für Otto Normalverbraucher reicht das auch. und wenns jemand wirklich wissen will, hast du sowieso keine Chance.
*GAST* schrieb: > Jasch schrieb: >> Die Zugangsdaten für was genau? Den Mailserver? Sind die überhaupt >> schutzwürdig, sprich kann man damit irgendwas böses anstellen was man >> nicht auch so schon anstellen könnte? > > Ja, für den Mailserver. Also da steht der Google-smtpserver drin, meine > Mailadresse, Port und Passwort. Jeder der das bekommt, kann sich damit > einloggen und alles machen. Wieso in aller Welt nimmst Du denn für sowas Deinen persönlichen Account? Gruselige Idee... > Jasch schrieb: >> Ansonsten: es ist nicht möglich - prinzipiell nicht - einem Programm >> Daten zur Verfügung zu stellen die ein Nutzer mit entsprechenden Rechten >> und genug Zeit nicht aus dem Programm extrahieren könnte. Nicht ohne die >> jetzt benutzten Rechnerarchitekturen komplett über den Haufen zu >> schmeissen. > > Dann würde ich Euch als Programmierer mit mehr Erfahrung doch mal > fragen, wie ihr so ein kleines Programm aufbauen würdet. Konzept ändern. Z.B. (privaten?) SMTP-Server benutzen der keine Authentifizierung verlangt, dann brauchst Du keine Zugangsdaten schützen. Verloren hast Du auch nichts, denn (gefakte) Mails verschicken kann sowieso jeder schon auf tausend verschiedene Arten. > Das alles seine > Sicherheitslücken hat, ist mir schon klar, ich benutze ja auch Outlook > bzw. Thunderbird. Da kommt man sicherlich auch irgendwie an die Daten. Wir reden hier nicht von Lücken, sondern von prinzipbedingten Unmöglichkeiten. Thunderbird oder Ausspuck können ja einfach das Passwort abfragen - kein Problem an der Stelle, das ist einfach nirgendwo gespeichert wo man es jederzeit abgreifen könnte. > Mir ist nur wichtig, das ich keine Lösung wähle, die offensichtlich für > die Tonne und unsicher ist. Ich will kein schlechtes Gewissen haben, > wenn ich das Programm auf den Rechner lege. Die meisten Endnutzer werden > das auch höchstens mal anklicken, oder verursachen ein Ereignis, welches > dieses Programm aufruft. Wenn aber doch mal jemand mit zu viel Zeit auf > dumme Gedanken kommt, sollte er es nicht zu leicht haben. ;-) Da fehlt eine Bedrohungsanalyse. Kommt heraus dass es realistisch keine genügend interessierten Angreifer gibt, hast Du auch kein Problem. Gefährliche Sache wenn man sich damit geirrt hat. > Ich kenne mich zu wenig aus, um beurteilen zu können, wie aufwändig die > Daten mit Thunderbird gespeichert werden, aber so eine Sicherheit reicht > auf jeden Fall.... Der speichert das Passwort garnicht - das ist gerade der Trick, jedenfalls wenn man das Ding korrekt benutzt. Schützt natürlich nicht gegen einen Angreifer der den Rechner infiltriert hat.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.