hallo,

hätte mal eine verständnisfrage in sachen Webprogrammierung.

angenommen ich hätte irgendein script (Perl, PHP,...) auf meinem Webserver.
dieses script führt eine bestimmte aktion aus, aber nur wenn es über POST ein passwort zugeschickt bekommt, dass gültig ist.

also ungefähr so (mal auf die schnelle in PHP):


jetzt könnte man natürlich im quelltext das passwort einsehen, wenn man sich den quelltext angucken könnte.

jetzt kommt meine frage:
könnte ein vermeintlicher hacker iwie auf meine seite kommen sich dieses script iwie herunterladen oder angucken und so das passwort herauskriegen? oder ist das unmöglich (außer über den FTP-zugang)?

ich weiß zwar das der quelltext des scriptes selbst nicht angezeigt wird, aber ist das sicher? was verwendet ihr denn, wenn ihr so eine passwortabfrage machen müsst? speichert ihr das passwort auch einfach im quelltext?

bin dankbar für die aufklärung, auch wenn das bestimmt zum grundwissen in der webprogrammierung gehört....

Hi,

Klartextpasswörter sind immer eine schlechte Idee.

Speicher einen aus dem Passwort mit crypt() erstellten String in einem String im Skript.

Wenn das Passwort als Parameter übergeben wurde, wendest Du nochmal crypt() an und vergleichst das Ergebnis mit dem gespeicherten String.

http://www.php.net/manual/en/function.crypt.php

Solange dein Webserver richtig konfiguriert ist, keine Bugs hat und du sicher programmiert hast, ist es nicht möglich das Script im Quelltext einzusehen. Gute Konfiguration ist aber schwierig und Bugfreie Webserver gibt es nicht. Daher währe es ratsam, wenn du das Passwort mit einem one-way-Hash verschlüsselst (z.b. Digest::SHA2).

Linuxer+2008-01-23 15:58:41--

[...]
Klartextpasswörter sind immer eine schlechte Idee.

Speicher einen aus dem Passwort mit crypt() erstellten String in einem String im Skript.

Wenn das Passwort als Parameter übergeben wurde, wendest Du nochmal crypt() an und vergleichst das Ergebnis mit dem gespeicherten String.
[...]

Die Übertragung des Passwortes im Klartext vom Client zum Server ist aber auch keine gute Idee, es sei denn die Verbindung ist bereits authentifiziert und verschlüsselt, zum Beispiel mit SSL.

Für ungesicherte Verbindungen wäre ein Frage-Antwort-Protokoll besser: Der Server schickt einen Schlüssel an den Client, welcher damit das Passwort verschlüsselt und an den Server zurückschickt. Das ist natürlich bei Webanwendungen etwas umständlich zu bewerkstelligen, aber es hilft gegen Replayattacken.

murphy+2008-01-23 16:14:26--

Linuxer+2008-01-23 15:58:41--

[...]
Klartextpasswörter sind immer eine schlechte Idee.

Speicher einen aus dem Passwort mit crypt() erstellten String in einem String im Skript.

Wenn das Passwort als Parameter übergeben wurde, wendest Du nochmal crypt() an und vergleichst das Ergebnis mit dem gespeicherten String.
[...]

Die Übertragung des Passwortes im Klartext vom Client zum Server ist aber auch keine gute Idee, es sei denn die Verbindung ist bereits authentifiziert und verschlüsselt, zum Beispiel mit SSL.

Für ungesicherte Verbindungen wäre ein Frage-Antwort-Protokoll besser: Der Server schickt einen Schlüssel an den Client, welcher damit das Passwort verschlüsselt und an den Server zurückschickt. Das ist natürlich bei Webanwendungen etwas umständlich zu bewerkstelligen, aber es hilft gegen Replayattacken.

edit: vorab: mag sein, dass ich das geschriebene Wort hier falsch (über)interpretiere... :/edit
Habe ich eine Klartextkommunikation zwischen Server und Client empfohlen oder warum zitierst Du meine Antwort für Deine Antwort?
Afaik: Auch wenn die Verbindung SSL-verschlüsselt ist, kommen die Parameter doch unverschlüsselt im Skript an, oder irre ich da?

Linuxer+2008-01-23 18:41:24--

Afaik: Auch wenn die Verbindung SSL-verschlüsselt ist, kommen die Parameter doch unverschlüsselt im Skript an, oder irre ich da?

Bei GET bin ich mir nicht sicher, aber POST Variablen werden defenitiv mit verschlüsselt.

Also bei https läuft das komplette HTTP, inklusiver aller Header, über einen verschlüsselten Layer.
Damit sind auch GET-Parameter verschlüsselt, wenn du so willst.

Im Normalfall sieht man bei HTTPS nur den CONNECT-Befehl, durch den die SSL-Verbindung aufgebaut wird. Alles andere, auch die angesurften URLs sind dann in der SSL-Verbindung verschlüsselt.

Taulmarill+2008-01-23 18:52:15--

Linuxer+2008-01-23 18:41:24--

Afaik: Auch wenn die Verbindung SSL-verschlüsselt ist, kommen die Parameter doch unverschlüsselt im Skript an, oder irre ich da?

Bei GET bin ich mir nicht sicher, aber POST Variablen werden defenitiv mit verschlüsselt.

Erwarten würde ich, dass beide Übertragungsarten verschlüsselt werden (siehe nepos' Beitrag).

Mein "Afaik" bezog sich nun direkt auf das Skript: Egal ob die Daten via POST oder GET (und egal ob die Daten verschlüsselt oder unverschlüsselt) geschickt worden, im Skript greift man mit einem simplem param('parameter') darauf zu, ohne sich um die eventuelle Verschlüsselung kümmern zu müssen.

murphy+2008-01-23 16:14:26--

Für ungesicherte Verbindungen wäre ein Frage-Antwort-Protokoll besser: Der Server schickt einen Schlüssel an den Client, welcher damit das Passwort verschlüsselt und an den Server zurückschickt. Das ist natürlich bei Webanwendungen etwas umständlich zu bewerkstelligen, aber es hilft gegen Replayattacken.

Interessanter Ansatz. Dann müsste die Verschlüsselung auf dem Client/im Browser mit JavaScript realisiert werden. ... oder gibt es noch eine andere (bessere) Möglichkeit? Für alle die JS deaktiviert haben, wäre das dann aber ein Hindernis.