Moin moin, bisher hatte ich nur Programme, die völlig unkritisches öffentliches Zeug von Servern abgefragt hatte, oder reine In-House-Tools die nur von uns 3 Mitarbeitern genutzt wurden. Ich habe gesehen, wie leicht man .NET Code wieder komplett lesbar machen kann und frage mich nun: Wie kann ich denn ftp-Zugänge und Datenbank-Logins sicher in einer .NET-Anwendung hinterlegen? Da die Anwendung auch Daten generiert, kann ich nicht einfach alles auf "nur Leserechte" stellen. Würd mich freuen, wenn jemand was dazu sagen kann. Grüßle Jens
Jens P. schrieb: > Wie kann ich denn ftp-Zugänge und > Datenbank-Logins sicher in einer .NET-Anwendung hinterlegen? Gar nicht. Ist auch sowieso komplett sinnlos, weil FTP unverschlüsselt ist.
Dieter schrieb: > Ist auch sowieso komplett sinnlos, weil FTP unverschlüsselt ist. So dumm wird er nicht sein. Sicherlich läuft das Ganze über einen VPN-Tunnel.
Jens P. schrieb: > Ich habe gesehen, wie leicht man .NET Code wieder komplett lesbar machen > kann und frage mich nun: Wie kann ich denn ftp-Zugänge und > Datenbank-Logins sicher in einer .NET-Anwendung hinterlegen? Gar nicht. Die packt man in ein extra (Config-) File. Man erinnere sich: Admin darf auch den RAM einer Anwendung auslesen. "Strings" auf'm RAM kann schon der Process Explorer (aus Sysinternals).
Daten in einer Anwendung zu verstecken ist praktisch unmöglich. Das sieht man ja schon daran, wie selbst ausgefeilte Kopierschutz-Mechanismen kommerzieller Software ausgehebelt werden. Was ist das für ein Programm, das Zugangsdaten zu einem Server enthält, die der Nutzer nicht kennen darf? Du könntest jedem Nutzer seine eigenen Zugangsdaten zuteilen, die er dann in das Programm eingeben muss. Macht einer Unfug, sperrst du seinen Account.
Jim M. schrieb: > Gar nicht. Die packt man in ein extra (Config-) File. Und auch von da müssen sie ja früher oder später gelesen werden. Jim M. schrieb: > Man erinnere sich: Admin darf auch den RAM einer Anwendung auslesen. > "Strings" auf'm RAM kann schon der Process Explorer (aus Sysinternals). Nicht privilegierte Prozesse können sich unter Windows untereinander beliebig im RAM rumlesen und -schreiben. Weder ist das auf Strings beschränkt, noch hat das etwas mit irgendwelchen sysinterals Tools zu tun.
:
Bearbeitet durch User
Doctor What schrieb: > Sicherlich läuft das Ganze über einen VPN-Tunnel. Völlig egal, wenn man den lokalen Nutzer "aussperren" will. Für ihn ist es dennoch Plain Text, den er leicht sniffen kann. Schwerer zugänglich machen kann man die Daten mit Obfuscation (Bsp. .NET). Aber wenn jemand genug Geduld und Zeit hat, nutzt das auch nichts. Was vielleicht geht, wäre, einen Webservice im Neztwerk einzurichten, auf den man sich verbindet und der die Daten von den FTPs holt bzw. dort hin transferiert. Dann könnte man besser steuern, wer was darf.
D. Arwin schrieb: > Völlig egal, wenn man den lokalen Nutzer "aussperren" will. Für ihn ist > es dennoch Plain Text, den er leicht sniffen kann. Genau das gleiche gilt doch für deinen nächsten Vorschlag auch > Schwerer zugänglich machen kann man die Daten mit Obfuscation
Ich würde einfach den Windows integrierten Passwortmanager ansteuern. Google Stichwörter: "Windows Credential Management API" "CredWrite" "CredRead" Dafür gibts auch fertige Wrapper auf nuget, z.B.: https://github.com/AdysTech/CredentialManager
Felix U. schrieb: > Genau das gleiche gilt doch für deinen nächsten Vorschlag auch Das war kein Vorschlag, wie man unschwer am zitierten Satz und dem nächsten Satz sehen kann.
Die Anwendung direkt mit FTP-Server/Datenbank sprechen zu lassen und dazu einen hartcodierten Zugang (den man nur herausfinden muss, um auf dem Server beliebigen Unfug zu treiben) zu nutzen, klingt ein wenig wie PC-Wahl https://ccc.de/system/uploads/230/original/PC-Wahl_Bericht_CCC.pdf
Ich glaube selbst PC-Wahl hat Configfiles verwendet, wenn ich den Vortrag richtig in Erinnerung hab.
und den hier bereits vorgeschlagenen ‚trick‘ mit dem webservice im hintergrund hat beim beA auch super funktioniert. findet man ebenfalls als vortrag beim ccc
Dr. Sommer schrieb: > Was > ist das für ein Programm, das Zugangsdaten zu einem Server enthält, die > der Nutzer nicht kennen darf? Klingt nach PC-Wahl
Jens P. schrieb: > Ich habe gesehen, wie leicht man .NET Code wieder komplett lesbar machen > kann und frage mich nun: Wie kann ich denn ftp-Zugänge und > Datenbank-Logins sicher in einer .NET-Anwendung hinterlegen? Garnicht, völlig unmöglich. Das hat allerdings nix mit .Net im Allgemeinen und der Tatsache der einfachen "Dekompilierbarkeit" im Besonderen zu tun, sondern schlicht und einfach mit den Grundlagen der Kryptographie. Denn die sagen: wenn das Geheimnis (in diesem Fall also die Zugangsdaten für irgendeinen Kram) lokal verfügbar ist, dann kann es auch jeder auslesen, der die gleichen Rechte hat wie der Benutzer, der darüber verfügen soll. Einziger Ausweg (theoretisch und praktisch): Das Geheimnis darf eben nicht lokal aufbewahrt sein. Ende der Ansage. Das allerdings ist auch noch lange nicht das Ende der Fahnenstange...
Hi an alle und vielen dank für die vielen Beiträge! Im konkreten Fall lässt es sich noch realisieren, dass die Clients die wirklich in fremde Hände gelangen mit Readonly-Accounts klar kommen, da ist das nicht schlimm. Die Daten sind auch nicht sonders sensibel. Die Terminals, welche die Daten generieren, sind schon physikalisch vom Zugriff her eingeschränkt und haben nur ein reduziertes grafisches Interface. Da kann ich also praktisch ausschliessen dass vor Ort an der Maschine solch Unfug getrieben wird. Wegen der FTP-Sicherheit: Es wird FTPS vewendet. Mich hat das auch einfach allgemein interessiert. Sollte ich mal etwas programmieren, wo es um sensible Daten geht oder man wirklich was kaputt machen kann, wäre dann folgendes eine Alternative: Man lässt den Benutzer lokal einen Login eingeben. Das Passwort wird gehasht und mit dem gehashten gespeicherten in der DB veglichen. Bei Erfolg gibt die Datenbank dann die weiteren Logindaten an den Client raus. Wäre das eine gangbare Lösung? Ich rede hier jetzt mal von "normalen" Anwendungen, nichts hoch sensibles.
> Man lässt den Benutzer lokal einen Login eingeben. Das Passwort wird gehasht und mit dem gehashten gespeicherten in der DB veglichen. > Bei Erfolg gibt die Datenbank dann die weiteren Logindaten an den Client raus. Wäre das eine gangbare Lösung? Na ja, falls du mit "weiteren Logindaten" einen Token meinst, der anderen Diensten zeitlich beschraenkt sagt, dass du dich gegenueber der zentralen Rechtevergabe fuer die Session authentifiziert hast und dich fuer bestimmte Rollen authorisiert. Das Problem wurde vor ein paar Jahrzehnten geloest; laeuft unter dem Namen Kerberos: https://web.mit.edu/kerberos/dialogue.html Mich wuerde auch interessieren, wie die Leute das hier bei normalen Anwendungen im RealLife handhaben.
securestring wird nicht im Ram gehalten. Der Fehler des Programmierers ist meist, das String in Securestring gewandelt wird und umgekehrt. Dann bringt der ganze securestring nichts.
Warum nicht einen Service auf dem Server anbieten, der nicht einen ganzen Datenbank- und FTP-Zugriff anbietet, sondern nur die Operationen, die der Client braucht? Dann kann man mit den aus dem Client herausoperierten Zugangsdaten zu dem Service nur das tun, was man mit dem Client sowieso tun könnte.
Klar, das wäre ne Möglichkeit, und wenn es wirklich auf Sicherheit ankommt wohl auch so ziemlich die Beste. Wollte halt nicht für jeden Kleinkram noch einen Serverteil entwickeln und n extra Dienst betreiben. Werde das aber auf jeden Fall als Lösungsansatz im Hinterkopf behalten.
Bitte 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.