Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   "Passwortsicherheit" von Komponenten (https://www.delphipraxis.net/160713-passwortsicherheit-von-komponenten.html)

Berni68 27. Mai 2011 09:48

"Passwortsicherheit" von Komponenten
 
Hallo zusammen,

mir fällt leider kein geeigneter Titel ein, deshalb beschreibe ich einfach mal mein Problem:

Wenn man z.B. die Komponente TIdFTP nutzt, Host, Username
und Passwort im Objektinspektor hinterlegt, wie einfach/schwer ist es, aus der .exe (wie auch immer) diese Infos wieder rauszuholen und damit den FTP-Zugang zu knacken?

Hab in diesem Bereich keine Ahnung und wäre für ein paar
Infos/Hinweise auch weiterführende Links dankbar.

nachti1505 27. Mai 2011 09:51

AW: "Passwortsicherheit" von Komponenten
 
Sehr einfach... wird dann in der Regel im Klartext in deiner exe gespeichert!

Phoenix 27. Mai 2011 09:51

AW: "Passwortsicherheit" von Komponenten
 
Zitat:

Zitat von Berni68 (Beitrag 1103241)
Wenn man z.B. die Komponente TIdFTP nutzt

Ganz ehrlich: Vergiss es.

Wireshark anschmeissen und den Netzwerktraffic beim FTP-Connect auslesen.
Da kannst Du innerhalb der .exe so viel Aufwand treiben wie Du willst um das Passwort zu schützen - aber bei FTP geht das letzendlich immer unverschlüsselt über die Leitung und da ist es am einfachsten Abzufangen.

Bernhard Geyer 27. Mai 2011 09:52

AW: "Passwortsicherheit" von Komponenten
 
Zitat:

Zitat von Berni68 (Beitrag 1103241)
Wenn man z.B. die Komponente TIdFTP nutzt, Host, Username
und Passwort im Objektinspektor hinterlegt, wie einfach/schwer ist es, aus der .exe (wie auch immer) diese Infos wieder rauszuholen und damit den FTP-Zugang zu knacken?

Solang kein DAU am werk ist, hat man diese Infos in weniger als 1 Minute. Diese Infos liegen im Klartext vor.

Berni68 27. Mai 2011 10:01

AW: "Passwortsicherheit" von Komponenten
 
Und wie ist es wenn man bei TIdFTP TLS verwendet?

Was gibt es für Alternativen?

himitsu 27. Mai 2011 10:03

AW: "Passwortsicherheit" von Komponenten
 
Lösung: Wenn schon FTP (oder sonstwas), dann nur über einen eingeschränkten FTP-Benutzer, damit nix Schlimmes passieren kann.

jaenicke 27. Mai 2011 10:30

AW: "Passwortsicherheit" von Komponenten
 
Warum muss es denn FTP statt einer normalen Lösung via HTTP sein?

Berni68 27. Mai 2011 10:48

AW: "Passwortsicherheit" von Komponenten
 
Habe mal Wireshake runtergeladen und installiert:
Im unverschlüsselten Modus von TIdFTP war es wirklich deprimierend einfach Host User und Pass zu erhalten.
Bei TIdFTP mit TSL geht das Passwort nicht zumindest nicht unverschlüsselt über die Bühne. Kann man es trotzdem noch knacken?

@jaenicke es muss nicht FTP sein.
Habe mal den Ansatz gewählt weil es einfach erschien.

Meine Absicht:
Ich stelle Nutzern die Daten sammeln müssen ein Programm zur Verfügung,
das die Daten auf einem WebServer ablegt (Idee/Ansatz->FTP),

Ist das mit HTTP so auch möglich? Da ist doch ein Problem mit dem Webspace Provider und dem zurückschreiben oder?

Phoenix 27. Mai 2011 11:01

AW: "Passwortsicherheit" von Komponenten
 
Zitat:

Zitat von Berni68 (Beitrag 1103269)
Habe mal Wireshake runtergeladen und installiert:
Im unverschlüsselten Modus von TIdFTP war es wirklich deprimierend einfach Host User und Pass zu erhalten.
Bei TIdFTP mit TSL geht das Passwort nicht zumindest nicht unverschlüsselt über die Bühne. Kann man es trotzdem noch knacken?

Im Prinzip ja, denn Client-Software und Server müssen sich ja über den Schlüssel einig werden. Hier kannst Du weiter lesen, das ist aber tatsächlich schon um einiges aufwändiger als mit reinem FTP.

Satty67 27. Mai 2011 11:28

AW: "Passwortsicherheit" von Komponenten
 
Wie sieht es mit asymetrischer Verschlüsselung aus.

Die Daten mit dem öffentlichen Schlüssel encrypten und an den Server senden. Dort erst mit dem privaten Schlüssel decrypten.

rollstuhlfahrer 27. Mai 2011 11:46

AW: "Passwortsicherheit" von Komponenten
 
Zitat:

Zitat von Satty67 (Beitrag 1103275)
Die Daten mit dem öffentlichen Schlüssel encrypten und an den Server senden. Dort erst mit dem privaten Schlüssel decrypten.

Sollten SSL und TLS das nicht schon sein? - Das hindert Wireshark trotzdem nicht daran, das Passwort anzuzeigen. Spätestens, wenn man mit einem Man-in-the-Middle-Angriff an die ganze Sache ran geht und das Programm gerade zufällig nicht das Zertifikat überprüft, ist die ganze Sache eh hinfällig, weil dann die komplette Kommunikation im Klartext vorliegt.


Zitat:

Zitat von Berni68 (Beitrag 1103269)
Meine Absicht:
Ich stelle Nutzern die Daten sammeln müssen ein Programm zur Verfügung,
das die Daten auf einem WebServer ablegt (Idee/Ansatz->FTP),

Ist das mit HTTP so auch möglich? Da ist doch ein Problem mit dem Webspace Provider und dem zurückschreiben oder?

Ein HTML-Formular, in das die Daten im Browser eingegeben werden und dann serverseitig in eine DB geschoben werden sollte doch vollkommen ausreichen. Dann braucht man noch nicht einmal ein Client-Programm. Und wenn das gesichert ablaufen soll, dann lädt man das eben per HTTPS.

Bernhard

jaenicke 27. Mai 2011 13:05

AW: "Passwortsicherheit" von Komponenten
 
Abgesehen davon muss das Passwort an die FTP-Komponente so oder so unverschlüsselt übergeben werden. Das heißt selbst wenn man das Passwort in der Exe verschlüsselt ablegt muss es zur Laufzeit dennoch unverschlüsselt im Speicher stehen. Das ist dann zwar nicht mehr ganz so einfach, aber dennoch relativ einfach zu finden.

Satty67 27. Mai 2011 13:12

AW: "Passwortsicherheit" von Komponenten
 
Zitat:

Zitat von rollstuhlfahrer (Beitrag 1103282)
Sollten SSL und TLS das nicht schon sein?

Ja, aber da lässt sich ja scheinbar dazwischenfunken.

Bei einem eigenen System im Programm wir das schwerer und der öffentliche Schlüssel kann ja gefahrlos im Klartext vorliegen.


Alle Zeitangaben in WEZ +1. Es ist jetzt 12:51 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz