Sind Passwörter im PHP-Script sicher?



  • Ich speichere Passwörter meistens in einen mit .htaccess-geschützten Ordner in *.inc Dateien, die bei vielen Hostern in der webserver-config gesperrt sind und somit nicht downloadbar sind.



  • Ok, danke an alle.

    Ich hab das schon geahnt, dass ein falsch laufender PHP-Parser ein Problem darstellen könnte, obwohl das sicherlich selten vorkommen sollte.
    Hauptsache, ein Betrachter kann bei richtig laufenden Webserver nichts manipulieren.

    Das mit den .htaccess Includes klingt schon ganz vertrauenswürdig.
    Obwohl natürlich dann auch hier der Server falsch konfiguriert sein könnte und .htacess nicht auswertet 😉

    Aber ist das richtig, das die Übertragung durch "post" nicht sicher ist?
    Ich denke, die läuft über StdIO, also Serverintern 😕



  • Ohne SSL werden die Daten eben unverschlüsselt vom Client zum Server übertragen (egal, ob GET oder POST - bei POST sieht man sie nur nicht in der URL) 😉



  • SeppSchrot schrieb:

    Ok, danke an alle.

    Aber ist das richtig, das die Übertragung durch "post" nicht sicher ist?
    Ich denke, die läuft über StdIO, also Serverintern 😕

    Nein, der Computer des Betrachters schickt per POST die Daten an den Webserver, also die Daten gehen dann durchs Netz, das ist die Gefahr, jemand stellt sich zwischen dir und dem Server und empfängt die Daten, bevor die Server sie bekommen hab.

    Standardmässig ist die Methode GET voreingestellt. Es ist sinvoller POST zu benutzen, denn wenn man man ohne method oder mit GET ein Formular ausstattet, dann werden die Daten an der URL angehängt und das kann unter Umständen sehr lästig werden (für den Programmier). Man kann nicht in 5 Sätzen den Unterschied zwischen POST und GET erklären, mehr zu diesem Thema findet man unter http://www.cs.tut.fi/~jkorpela/forms/methods.html

    Ohne POST werden die Daten per GET geschickt und an der URL angehängt.

    SSL (Secure Socket Layer) ist dann die Lösung, weil der Server und der Benutzer tauschen Daten verschlüsselt, also ein dritter kann sie nicht verstehen, obwohl sie vor dem Server bekommen hat. Deshalb rate ich immer https zu benutzen, wenn dein Host Server das unterstützt und Passwörter geschickt werden müssen 🙂



  • Der Unterschied zw. POST und GET ist.

    Der Client öffnet einen Socket auf Port 80 und sendet bei POST vereinfacht

    www.c-plusplus.net/forum

    POST /forum HTTP/1.0\nHost: www.c-plusplus.net:80\n\nMYPASSWORD=passwort\n\n

    Bei GET wenn in URL www.c-plusplus.net/forum?MYPASSWORD=passwort

    GET /forum?MYPASSWORD=passwort HTTP/1.0\nHost: www.c-plusplus.net:80\n\n

    Das ist der einzige Unterschied.
    Beides geht aber immer vom Client zum Server da HTTP ein Verbindungsloses Protokoll ist sollange die Verbindung nicht aufrechtz erhalten wird mit speziellen HTML-Commandos.

    Client senden an Server und server Antwortet auf der selben Socketverbindung. Dann wird der Socket geschlossen.



  • also passwörter usw. in .php dateien sind schon relativ sicher (hat schon einer gesagt hier) es muss schon ein übler bug im webserver sein, wenn er die .php-dateien unverändert ausliefert. selbst wenn die php-engine kaputt ist sieht man nix. bestenfalls stürzt der webserver ab. an die php-sources im klartext kommt man nur, wenn man nicht über den webserver geht (z.b. über ftp etc.)



  • supertux schrieb:

    @Sepp:
    wenn PHP nicht läuft, wirst du 100% einen Fehler vom Webserver bekommen. Ich hab das noch nie gehabt, ich hab noch nie gesehen, dass "php" down ist und der apache Server (bei Windows Server weiß man nie) mir den PHP Code schreibt.

    Ich schon, dummerweise sogar von meiner Seite :o
    Was dann hilft ist Passwörter in einer Datei speichern die includet wird und diese eventuell noch da speichern wo niemand mit dem Browser hinkommt.



  • hallo

    kleine nebengeschichte:
    schön ist es, wenn auf einem server eine umstellung erfolgte, und (so habe ich es mal beim surfen erlebt und mir den fall nachrecherchiert) php4 auf php umgestellt wurde in der apache.conf.

    dann kann man ohne probleme alle .php4 skripte runterholen, denn: der apache nimmt dann nur das suffix php, und alles andere wird als txt interpretiert, und je nach browsereinstellung zum download angeboten, oder geöffnet.
    herrlich. vor allem, wenn dann keine indexe in den ordnern liegen, da liegt einem dann die welt offen ...
    bekommt man solche umstellungen zu spät mit, hat man pech. klar, kein richtiger webadmin würde php und php4 nicht beide eingestellt lassen. aber wie gesagt, schon erlebt.
    was macht man in einem solchen fall? den betroffenen 'snell' mal eine email schreiben. (auch wenn man sie nicht kennt)



  • net schrieb:

    also passwörter usw. in .php dateien sind schon relativ sicher (hat schon einer gesagt hier) es muss schon ein übler bug im webserver sein, wenn er die .php-dateien unverändert ausliefert. selbst wenn die php-engine kaputt ist sieht man nix. bestenfalls stürzt der webserver ab. an die php-sources im klartext kommt man nur, wenn man nicht über den webserver geht (z.b. über ftp etc.)

    das ist eine falsche aussage.

    es muss kein Bug sein. schon wenn der Provider ein Update einspielt kann es dazu kommen das PHP-Dateien nicht als das interpretiert werden waqs sie sind sondern als Text-File ausgegeben werden.
    Eine Teilsicherheit bekommt mann/frau nur wenn man es so macht wie ich oben beschrieben habe.



  • Anstelle zu diskutieren, wie ihr möglichst riskant irgend wo Passwörter rumfliegen lasst, benutzt doch einfach Hashes und ihr seid schon mal viel sicherer, PHP hat doch AFAIK sogar Funktionen für SHA1 und MD5 integriert. Tut euch den gefallen, dann habt ihr auch nicht so einfach ein blaues Auge (oder gar einen total Schaden) wenn irgend wo ein kleiner Fehler ist und auf einmal jemand per SQL-Injection oä. an die Passwörter kommt, gerade wenn es nicht nur um eure Passwörter geht.

    Man muss ja nicht immer versuchen mit minimaler Sicherheit durchzukommen, vorallem wenn ein höherer Sicherheitsstandard ohne große Mehrkosten zu erreichen ist.

    @volkard
    *fg*
    aber warum trennst du Entwicklung und Anwendung nicht? Integrierst du auch Änderungen sofort in den aktiven Code?



  • @kingruedi: Ich glaube es geht um die Passwörter des (R)DBMS. Die kann man IMHO leider nicht hashen, ansonsten natürlich ACK!

    Die beste Lösung wurde doch schon von volkard und Unix-Tom gesagt: Legt die Passwörter nicht im Document-Root/htdocs ab. Dann kann man auch ruhig schlafen, wenn mal der PHP-Parser ausfällt. 😉

    Gruss



  • und was mach ich, wenn ich einen anbieter habe (sql und php) aber nur auf die root kann, und von da an aufwärts. wo soll ich in so einem fall meine datei mit den passwörtern ablegen?



  • StudentJojo schrieb:

    und was mach ich, wenn ich einen anbieter habe (sql und php) aber nur auf die root kann, und von da an aufwärts. wo soll ich in so einem fall meine datei mit den passwörtern ablegen?

    Wenn du die Datei .htaccess anlegen kannst (die natürlich auch funktioniert), dann dort die .php Dateien mit den Passwörtern anlegen.



  • nehmen wir mal an, /root/ wäre mein verzeichnis.
    soll ich dann einfach /root/.htaccess anlegen?! und wie seh ich, ob die funktioniert?



  • StudentJojo schrieb:

    nehmen wir mal an, /root/ wäre mein verzeichnis.
    soll ich dann einfach /root/.htaccess anlegen?! und wie seh ich, ob die funktioniert?

    nicht da. Zb. ein Verzeichnis passwd erstellen (/root/passwd) und unter /root/passwd die .htaccess anlegen und die php Sources dort anlegen, die die Passwörter haben.




Anmelden zum Antworten