Quellcode verschlüsseln?

[Cyf]

Zitat:

Zitat von Apollonius

Zitat:

Zitat von Cyf

Zitat:

Zitat von Matze

oder du gehst über ein PHP-Skript, das deine Benutzerdaten enthält, die FTP-Verbindung aufbaut und die Datei zurückgibt

Natürlich musst du die Daten dann auch - wo immer auch du sie hinsendest (PHP, CGI auf einem Server) - verschlüsselt senden und sie müssen beim Ziel entsprechend verschlüsselt vorliegen. Man kann sowas z.B. mit MD5 machen, was aber bei kurzen Passwörtern mittlerweile sehr anfällig für Rainbowtables ist, aber das ist ein anderes Thema.

Der Trick ist, über PHP eine eingeschränkte Schnittstelle zur Verfügung zu stellen. An das PHP-Script wird gar nichts übertragen, es enthält selbst die Login-Daten und liegt friedlich auf einem globalen Server.
Und wie man Hashes einsätzen soll, kann ich an dieser Stelle auch nicht sehen.

Hab mit der Hash Sache grade am Thema vorbei gedacht, war in letzter Zeit zu oft Verschlüsselung :wink:
Die könnten, um den Beitrag zumindest ein wenig Sinn zu geben, Verwendung finden, wenn man sie an eine CGI auf einem http-Server überträgt.
Back to topic: Die Schwachstelle bei dem ganzen Verfahrung liegt wesentlich mehr bei der Übertragung der Daten, als bei ihrer Speicherung.

[Matze]

Zitat:

Zitat von Cyf

Die Schwachstelle bei dem ganzen Verfahrung liegt wesentlich mehr bei der Übertragung der Daten, als bei ihrer Speicherung.

Ich glaube, du hast noch nicht ganz verstanden, was einige hier meinen. ;)
Die Zugangsdaten müssen nicht zwischen Anwendung und Server übertragen werden, wenn man ein PHP-Skript verwendet:

Code:

<?php

$user = 'user';
$pass = 'password';
$host = 'ftp.example.com';

$conn_id = ftp_connect($host);
$login_result = ftp_login($conn_id, $user, $pass); 

?>

Die Daten enthält einzig alleine das PHP-Skript und dort bleiben sie auch. Das Skript baut die Verbindung auf und wieder ab.

Grüße

[Cyf]

Ich meinte, dass diese deswegen verhindert werden muss. :wink:
Wenn ich so drüber les, vielleicht doch ein bisschen unklar.

Was (je nach Anwendungsfall) die ganzen Lösungen gemeinsam hatten, war ja die Tatsache, dass die Zugangsdaten auf dem Server liegen, weil eben grade die Übertragung verhindert werden soll.

Eine solche Methode ist eigentlich die einzige vernünftige, wenn die Datei nicht einfach algemein zugänglich sein darf (http, anonymer FTP-Zugang <-> nur über den Client bzw. das PHP-Skript hier).

Damit entfällt dann auch gleich die Speicherung, aber falls man es doch speichern wollte, wäre die Übertragung die Schwachstelle.
Allerdings wird in dieser Variante wiederum, die Adresse des PHP-Skriptes, gespeichert werden müssen, dass ja jedem die Datei auf Anfrage schickt, wenn man dafür keine Überprüfung einbaut, oder? (hier könnte ich mich jetzt irren).

[Matze]

Zitat:

Zitat von Cyf

Allerdings wird in dieser Variante wiederum, die Adresse des PHP-Skriptes, gespeichert werden müssen, dass ja jedem die Datei auf Anfrage schickt, wenn man dafür keine Überprüfung einbaut, oder? (hier könnte ich mich jetzt irren).

Ja, man könnte dann herausfinden, was ans Skript gesendet wird und dies selbst senden. Ich denke etwas hundertprozentig sicheres gibt es nicht. Wichtig ist jedoch, dass die Zugangsdaten sicher bleiben.

Man kann sicher noch irgendwelche Prüfdaten versenden, doch was da sinnvoll ist, weiß ich auch nicht.
Evtl. eine Art Mini-Dialog, dass das Programm dem Skript mitteilt, dass gleich Daten angefordert werden. Das Skript sendet daraufhin etwas an das Programm und dieses antwortet darauf.Hat das Skript die Antwort als korrekt erkannt, werden die Daten übertragen.

Aber das ist auch nur eine Idee, von der ich nicht weiß, ob sie sinnvoll ist. ;)

[DGL-luke]

klar, über ein challenge-response-verfahren mit sicherem key-"austausch" zum beispiel mit diffie-hellman kann man eine beweisbar sichere authentifizierte verbindung aufbauen...

das in PHP asynchron zu implementieren, wäre dann die herausforderung.