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.
