Programmcode soll für Anwender nicht lesbar sein

Wie wäre es, den Benutzer einen eigenen Login generieren zu lassen, den er sich zu merken oder sonstwie
sicher zu verwahren hat? Sehe keine richtigen Nachteile dieser Variante. Vor Allem hätte dann jeder Nutzer
einen eigenen Login und man kann nach ihnen differenzieren. So hat nicht jeder Zugriff auf die Daten aller
Anderen.
 
Reden wir hier über ganz normale User oder über potentielle Hacker, die auch mal mit Hex-Editoren oder Disassemblern rangehen würden, um das Paßwort in Erfahrung zu bringen?

Wenn ersteres, dann sollte das Hineincompilieren in eine EXE-Datei locker reichen. Wenn letzteres... dann hast du ein Problem :D
 
@asdfman
das ist zu aufwendig. Der Nutzer hatte mit dieser Sache noch direkt etwas zu tun und das soll auch so bleiben.
 
Ich hab so das Gefühl, du rückst nicht mit genug Informationen raus, damit ich eine sinnvolle Empfehlung geben kann.
So, wie du es jetzt machst, ist es nicht viel besser, als eine anonyme Verbindung zum FTP-Server zu nutzen.
 
Was willst du denn noch wissen?
Hatte in #18 schon kurz erklärt um was es geht. Der Nutzer liest ein MDE Gerät aus und direkt im Anschluss wird automatisiert der FTP Transfer initiiert um die Daten an ein fernes System zur Weiterverarbeitung zu senden. Das war es im Prinzip schon. Der Nutzer muss an keiner Stelle eingreifen. Auch nicht um Passwörter einzugeben. Das soll auch so bleiben.
Wie gesagt, wir haben keine Hacker als Kunden ;), aber unschön ist diese Lücke dennoch. Es ist nun mal ein bisschen sehr einfach an das PW heran zu kommen.
 
Dann stell dem User ein Zertifikat aus, mit dem er sich anmelden soll. Musst nur dafür sorgen, dass er das nicht
rumgibt. Am besten sagen "Diese Datei ist wichtig. Nicht rumgeben!"

Wenn er es doch rumgibt, kannst du das Zertifikat dann ablehnen.
 
Jetzt kommen wieder meine bescheidenen Programmierkenntnisse zum tragen...

Kannst du bitte näher erläutern wie du das meinst?
 
@asdfman: War vielleicht ein Missverständnis meinerseits. Ich war nur ungehalten über den wirklich agressiven Ton und hab dann auch die Kritik von dir auf das bezogen, was ich unmittelbar vorher geschrieben hatte. Wie du dir vorstellen kannst, las ich deinen Kommentar und dachte "Autsch - das war ein Tritt in meine Körperregionen, wo es wirklich weh tut ..." Ok, war selber etwas angefressen, weil ich mich immer noch mit dem Installieren und Einrichten der Entwicklungsumgebung für PenOS rumschlage. Aber sei es drum, gehört nicht hier her und nun zurück zum Thema:

@aggitron:
Wie authentifiziert sich der User im System, falls es ein System gibt?
Wieviele Anwender gibt es ungefähr? (Keine exakte Zahl notwendig, sondern eine einfache Schätzung reicht)
Stehen im System weitere Datenquellen zur Verfügung, z.B. Datenbanken?
Wo steht der Server auf den die Dateien landen sollen, im Internet, im Intranet?
Von wo aus soll der Zugriff erfolgen, nur Intranet, nur Internet oder beides?
Hätten externe Anwender Zugriff auf das System, die nicht dem Unternehmen angehören oder anders rechtlich belangt werden könnten?
Und nun meine Lieblingsfrage: Vor wen willst du es abschotten: Anwender, Scriptkiddie, Semiprofessionel oder die Elite?

Das wären so ein paar Fragen, die ich mir stellen würde. Sicher läßt sich dann etwas drauf zu schneiden.
 
Zuletzt bearbeitet:
Es handelt sich um ein VPN Netz räumlich getrennter Orte. Anwender ca. 200.
Es handelt sich um ein IBM System (OS400, DB2). Der Server steht in einem Rechenzentrum. Externe Anwender haben keinen Zugriff. Hauptsächlich will ich vor neugierigen Anwender schützen.
 
Die Sniffer-Fraktion kannst du mit dem FTP-Protokoll an sich nicht aussperren, da wie hier hinlänglich beschrieben alle Kommandos einschl. Username und Passwort im Klartext über die Leitungen rauschen. Also wäre eine Verschlüsselung der Übertragung notwendig. Entweder SFTP oder FTP over SSL. Letzteres läßt sich in C# für den Client relativ leicht realisieren, in dem der FtpRequest die Eigenschaft EnableSsl auf True gesetzt bekommt. Der Server muss jedoch diese spezielle Erweiterung des FTP Protokolls unterstützen.

Nun bleibt noch das geheime Passwort für die Übertragung, das nicht im Klartext fest in die Exe kompiliert wird oder auf dem Client abgelegt ist:

Anwender gibt ein Passwort beim Versand der Datei ein
oder
Passwort für Login ins System (OS400, DB2) wird ebenfalls für die Übertragung verwendet
oder
Passwort für die Übertragung wird mit dem Passwort fürs Login verschlüsselt in einer Datenbank abgelegt, vor dem Versand abgefragt und Clientseitig wieder ausgepackt. Verschlüsselung deswegen weil die SQLAbfrage inkl. Antwort von der Datenbank auch wieder per Sniffer mitgeschnitten werden könnte. Zusätzliches "Salzen" wäre auch sinnvoll, sodaß bei 2 Anwendern, die zufällig das gleiche Passwort haben, nicht der gleiche chiffrierte Text in der DB landet. Das Salz kann ruhig unverschlüsselt in der DB abgelegt sein, das macht es dennoch schwerer per Wörterbuch o.ä. das Passwort für die Verschlüsselung des Transferpassworts zu knacken.

Sicher hat jede der Varianten Vor- und Nachteile. Aber zumindest wird es für einen neugierigen User etwas schwieriger. Natürlich beruhen die genannten Möglichkeiten auf "Security by Obscurity". Was nicht für den Masseneinsatz empfehlenswert wäre und auch nicht wirklich eine Hürde für die Semipros und Pros darstellt.

Viel Erfolg
Rossibaer
 

Ähnliche Themen

Zurück
Oben