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.
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
und den hier bereits vorgeschlagenen ‚trick‘ mit dem webservice im
hintergrund hat beim beA auch super funktioniert. findet man ebenfalls
als vortrag beim ccc
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.
