Forum: PC-Programmierung Sicheres Hinterlegen von Logindaten in .NET-Application


von Jens P. (Gast)


Lesenswert?

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

von Dieter (Gast)


Lesenswert?

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.

von Doctor What (Gast)


Lesenswert?

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.

von Jim M. (turboj)


Lesenswert?

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).

von Dr. Sommer (Gast)


Lesenswert?

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.

von Felix U. (ubfx)


Lesenswert?

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
von D. Arwin (Gast)


Lesenswert?

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.

von Felix U. (ubfx)


Lesenswert?

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

von bluppdidupp (Gast)


Lesenswert?

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

von D. Arwin (Gast)


Lesenswert?

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.

von Tom (Gast)


Lesenswert?

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

von Vn N. (wefwef_s)


Lesenswert?

Ich glaube selbst PC-Wahl hat Configfiles verwendet, wenn ich den 
Vortrag richtig in Erinnerung hab.

von digitaldex (Gast)


Lesenswert?

und den hier bereits vorgeschlagenen ‚trick‘ mit dem webservice im 
hintergrund hat beim beA auch super funktioniert. findet man ebenfalls 
als vortrag beim ccc

von Hans (Gast)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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...

von Jens P. (Gast)


Lesenswert?

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.

von D.M. (Gast)


Lesenswert?

> 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.

von Fred R. (Firma: www.ramser-elektro.at/shop) (fred_ram)


Lesenswert?

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.

von Tom (Gast)


Lesenswert?

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.

von Jens P. (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.