Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Session wird blockiert

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] Session wird blockiert

    Hallo liebe PHPler,

    ich bin zwar ein relativ erfahrener Nutzer von PHP (Autodidakt), aber im Moment stehe ich vor einem kleinen Rätsel. Vielleicht fällt euch ja etwas dazu ein.

    Ich programmiere ein Login-Script mit allem drum und dran. Soweit nichts besonderes. Jetzt habe ich aber das Problem, dass nach fehlerhaften Eingaben die Session (die Datei der Session) einfach blockiert ist. Auch geht dann ein Zugriff auf den Login-Bereich bzw. das Loginscript über den Browser nicht mehr. Ich kann mir das Verhalten nicht erklären.

    Nun habe ich ein wenig mit dem Script experimentiert, und festgestellt, dass es möglicherweise an meiner Funktion zur Passwortverschlüsselung liegen könnte. Wenn ich dass Passwort nur mit md5 hashe, dann gibt es keinerlei Probleme. Wenn ich aber die folgende Funktion zum Verschlüsseln des Passwortes nutze, dann kommt es zu dem eben beschriebenen Verhalten.

    Habe ich damit eventuell einen Bock geschossen?

    PHP-Code:
    function encrypt_psswrd($psswrd)
    {
        
    $psswrd_rot13 str_rot13($psswrd);
        
    $salt crypt($psswrd$psswrd);
        
    $crypt crypt($psswrd_rot13$salt);
        return 
    md5($crypt);

    Ich weiß nicht wo ich da noch ansetzen könnte.

    Ein Passwort nur zu hashen reicht mir nicht, darum die Funktion.

    Vielen Dank schon mal für das Lesen und euer Kopfzerbrechen.


  • #2
    Hallo, willkommen im Forum

    Kann mir nicht vorstellen, dass das dein Problem ist, aber wenn dir ein einfaches MD5 nicht reicht, benutz doch einen SALT, ist sowieso anzuraten:

    define("MY_SALT", ")(/&%$§=)UIJNRD");
    md5(MYSALT . $password);

    Wenn jemand an deinen SALT rankommt ist der Server vermutlich sowieso geknackt. Insofern sollte das ausreichen. Security by Obscurity ist selten langfristig hilfreich.
    "Mein Name ist Lohse, ich kaufe hier ein."

    Kommentar


    • #3
      Selbst wenn er den Salt hat. Er müsste trotzdem erst eine Rainbowtable anlegen, von daher kann er immer noch keine Passwörter schnell knacken.

      Kommentar


      • #4
        @Chriz: Ein Salz legt man aber nicht konstant in einer PHP Datei fest, sondern nutzt ein zufälliges und variables Salz für jeden Benutzer. Die Kombination beider Salze ist jedoch sinnvoll, aber nur in der PHP Datei ist zu viel Security by Obscurity!

        Kommentar


        • #5
          ist zu viel Security by Obscurity!
          Naja, da finde ich andere Techniken (Username als Salt o.ä.) wesentlich problematischer. Aber klar, man kann natürlich für jeden User noch einen SALT in seinem DB-Datensatz hinterlegen.
          --

          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
          Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


          --

          Kommentar


          • #6
            Zitat von nikosch Beitrag anzeigen
            Naja, da finde ich andere Techniken (Username als Salt o.ä.) wesentlich problematischer. Aber klar, man kann natürlich für jeden User noch einen SALT in seinem DB-Datensatz hinterlegen.
            Jain, man benötigt zwingend ein variables Salz, was durch einen Benutzernamen bereits erreichen werden würde, auch wenn ich es auf jeden Fall problematisch finde!
            Ein konstantes Salz hätte zwei Nachteile: (1) jedes gleiche Passwort unterschiedlicher Benutzer würde gleich abgespeichert werden und man könnte zwei Fliegen mit einer Klappe schlagen und (2) ein Angreifer der an eine große Menge mit Hashes gelangt, kann eine einzige Rainbowtable für ALLE Passwörter erstellen, anstatt bei einem variablen Salz für jeden Hash eine eigene Tabelle anlegen zu müssen!

            Kommentar


            • #7
              Ein konstantes Salz hätte auch den Nachteil, dass bei einer Änderung des Salzwertes jeder Benutzer ein neues Passwort benötigt. Man kann aber keine Passwörter umschreiben in der DB, weil sie ja nicht wiederherstellbar verschlüsselt sind.

              Im Prinzip ist meine Funktion aber auch nicht so genial, wenn ich es mir recht anschaue. Das selbe Passwort würde auch denselben Hashwert ergeben.

              Nun frage ich mich aber immer noch, warum die Session bei mir blockiert wird. Hättet ihr da eine Vermutung, einen Tipp, was ich mal prüfen sollte?

              Eine Endlosschleife habe ich nicht. Das war mein erster Gedanke.

              Kommentar


              • #8
                @Sirke: War nur ein Beispiel, trotzdem ist ein md5(database_id) als Hash zu einfach. Gleiches mit CREATED-Datum. Alles andere ist relativ variabel und auf anderen Servern möglicherweise nicht reproduzierbar.

                Nun frage ich mich aber immer noch, warum die Session bei mir blockiert wird. Hättet ihr da eine Vermutung, einen Tipp, was ich mal prüfen sollte?
                Aus diesem Code nicht ersichtlich.
                "Mein Name ist Lohse, ich kaufe hier ein."

                Kommentar


                • #9
                  Session wird blockiert
                  Was soll das bedeuten? Wie äußert sich das?
                  --

                  „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                  Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                  --

                  Kommentar


                  • #10
                    Es handelt sich um ein altes Windows System mit installiertem Apache, PHP und MySQL (Entwicklungsumgebung). Da ist ein Eingabeformular für die Logindaten. Das funktioniert "eigentlich" wunderbar, genau wie es soll.

                    Nach einer fehlerhaften Eingabe in dieses Formular werden Fehlermeldungen ausgegeben. Danach ist dann jedoch kein Zugriff auf die session mehr möglich, obwohl (meiner Meinung nach) gar nicht darauf geschrieben wurde.

                    Das äußert sich so, dass die Session-Datei einfach blockiert ist. Sobald eine Seite diese Session aufgreifen will, geht nichts mehr. Er loaded, und loaded ...

                    Die Session-Datei, in der die Daten abgelegt werden, ist dann zugriffsgeschützt, also sie lässt sich zum Beispiel nicht löschen. Als ob sie noch von einem Programm verwendet wird. Nach Beenden des Apache ist die Datei wieder freigegegeben.

                    Jedes Script, das z.B. session_start() einsetzt, um die bestehende Session aufzugreifen, ist damit blockiert.

                    Merkwürdigerweise kommt es zu diesem Verhalten nur, wenn ich die oben genannte Funktion einsetze zur Passwortverschlüsselung. Wenn ich das Passwort einfach nur hashe tritt dieses Verhalten nicht auf. Soweit konnte ich es bis jetzt eingrenzen.

                    Ich würde gerne einmal abklären, ob soetwas am Programm liegen kann (dann müsste ich das Ganze nochmal genau in allen Einzelheiten kontrollieren), oder eher am System liegt. Denn wenn das Script bereits in der Entwicklungsumgebung rumzickt, würde ich es ungerne so in Live-Betrieb setzen. Darum frage ich hier nach.

                    Kommentar


                    • #11
                      Zitat von xnic Beitrag anzeigen
                      Nach einer fehlerhaften Eingabe in dieses Formular werden Fehlermeldungen ausgegeben.
                      Diese könnten das Problem ja beschreiben, also her damit... Außerdem ist in einem PHP Forum der Code auch sehr interessant, um ein Problem zu lösen...

                      Kommentar


                      • #12
                        Zitat von xnic Beitrag anzeigen
                        Merkwürdigerweise kommt es zu diesem Verhalten nur, wenn ich die oben genannte Funktion einsetze zur Passwortverschlüsselung.
                        Na dann untersuche diese eine Funktion in einem separaten Script mal genauer.

                        error_reporting auf E_ALL und display_errors auf on (wenn nicht schon geschehen), Testausgaben vor und nach dem Aufruf der Funktion, nach jeder Testausgabe flush-en - und damit mal schauen, ob das Script ordnungsgemäß beendet wird oder nicht.

                        Kommentar


                        • #13
                          Alles schon geschehen.

                          Vielen Dank für eure Mühe. Hatte gehofft aus Erfahrungswerten eventuell Hinweise zu erhalten wo es haken könnte. Aber anscheinend kennt keiner von euch dieses Phänomen.

                          Ich denke das "Problem" kann schwer über ein Forum gelöst werden. Da ich keine Fehlermeldungen erhalte, weder am Bildschirm noch in Logdateien, kann ich schwer dahinter kommen, was das Problem ist. Darum habe ich mich lieber an ein Refactoring gesetzt, das bislang problemlos läuft.

                          Kommentar

                          Lädt...
                          X