Mein Loginscript so sicher?

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

  • #16
    Wo siehst du sicherheitstechnische Bedenken?
    In diesem Fall eher datenschutztechnische Bedenken. Solange der Cookie auf der Platte liegt, lässt das evtl. Rückschlüsse zu. Es geht um folgendes: Wenn ich die Session-Funktionen verwende, will ich auch genau wissen, was alles im Hintergrund abläuft und ggf. darauf Einfluss nehmen. Also wenn ich die Session komplett vernichten will, muss ich auch wissen, dass der Cookie eben noch vorhanden ist.

    Kommentar


    • #17
      Übertreibst du da nicht ein wenig? Was soll an einem Session Cookie gefährlich sein? Man kann daran nur erkennen, dass ich auf der entsprechenden Domain war. Das sieht man aber auch in der History.
      Wichtig ist nur, dass die Applikation nicht irgendwelche Daten preisgibt, nur weil eine SID da ist. Sie muss halt wirklich den Loginzustand prüfen.

      Kommentar


      • #18
        Zitat von Benni16 Beitrag anzeigen
        danke für die antwort.

        habe jetzt von md5 auf sha1 gewechselt..
        ... und welches Plus an Sicherheit erwartest du dir von dieser Umstellung?

        Rainbowtables gibts sicher auch für SHA-1 ...

        You're Probably Storing Passwords Incorrectly
        Suche nach dem Satz "Add a long, unique random salt to each password you store".
        Zuletzt geändert von fireweasel; 11.05.2009, 12:47.
        Klingon function calls do not have “parameters”‒they have “arguments”‒and they always win them!

        Kommentar


        • #19
          Zitat von onemorenerd Beitrag anzeigen
          Übertreibst du da nicht ein wenig? Was soll an einem Session Cookie gefährlich sein? Man kann daran nur erkennen, dass ich auf der entsprechenden Domain war. Das sieht man aber auch in der History.
          Wichtig ist nur, dass die Applikation nicht irgendwelche Daten preisgibt, nur weil eine SID da ist. Sie muss halt wirklich den Loginzustand prüfen.
          Nein, ich übertreibe nicht. Es geht hier wie gesagt um Datenschutz und weniger um Sicherheit. Die Browser-History kann man löschen und die Cookies übersehen. Warum soll man sich auf den Zufall verlassen? Wenn ich doch weiß, dass ich den Cookie nicht mehr benötige, wird er einfach entfernt

          Kommentar


          • #20
            Darf ich dich aber auch mal fragen was dir hier an den Antworten nicht gepasst hat? Hier in dem Forum ein anderer Nickname aber der Quelcode doch sehr gleich, nur etwas den Ratschlägen angepasst. Ich denke wenn man dich einmal auf Crosspostings hinweist, ist es nciht zuviel verlangt sich zu informieren was das ist und sich dann daran zu halten.

            Loginsystem so sicher? - php.de
            LoginSystem so sicher? - Forum: phpforum.de

            Gruß litter
            Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
            http://www.lit-web.de

            Kommentar


            • #21
              Zitat von Cheadle Beitrag anzeigen
              Nein, ich übertreibe nicht. Es geht hier wie gesagt um Datenschutz und weniger um Sicherheit. Die Browser-History kann man löschen und die Cookies übersehen. Warum soll man sich auf den Zufall verlassen? Wenn ich doch weiß, dass ich den Cookie nicht mehr benötige, wird er einfach entfernt
              Und wie willst du das vom Server aus anstellen? Ob und wie der Client die Cookie-Date(ie)n von der Festplatte putzt, entscheidet der ganz alleine. Diesen Vorgang kannst du auf der Serverseite allenfalls anstoßen, durchgeführt wird er vom Browser, nach dessen Regeln. Der FF bspw. nutzt neuerdings eine SQLite-Datenbank dafür. Wenn man darin Datensätze löscht, bleiben die trotzdem lesbar. Erst nach Überschreiben oder nach einer Defragmentierung kann man sicher sein, dass die Daten wirklich weg sind.
              Klingon function calls do not have “parameters”‒they have “arguments”‒and they always win them!

              Kommentar


              • #22
                Das bestreitet niemand. Die Daten sind aber nicht mehr über 3 Klicks für den Normal-User erreichbar. Es geht darum, das zu tun, was innerhalb meiner Möglichkeiten liegt. Da ich mit der einen Extrazeile Code die Privatsphäre ein wenig verbessern kann, verstehe ich die Einwände nicht.

                Kommentar


                • #23
                  crosspostings

                  Ich habe mich über Crosspostings informiert. Nur die Themen wurden ja gleich geschlossen. Soll ich dann wiederrum ein neues Thema in diesem Forum erstellen? eher nicht. Ich habe mein Acc bei phpforum.de gelöscht, werde mich jetzt nur noch auf dieses Forum hier beziehen und auch keine Crosspostings mehr tätigen.

                  Zitat von litterauspirna Beitrag anzeigen
                  Darf ich dich aber auch mal fragen was dir hier an den Antworten nicht gepasst hat?
                  Welche Antwort hat mir denn nicht gepasst?

                  Kommentar


                  • #24
                    @Cheadle: Welche "Rückschlüsse" kannst du aus dem Vorhandensein eines Session Cookie ziehen?

                    Kommentar


                    • #25
                      Wurde schon geschrieben: (Im Normalfall) wo und wann jemand gewesen ist.

                      Kommentar


                      • #26
                        Ein letztes Mal zum absurden Vorhaben: "SessionCookie löschen"

                        1. Wie kommst du überhaupt auf die aberwitzige Idee, dass jemand deinen LogoutButton drückt?
                        2. Nach dem Logout gibts bei dir eine Weiterleitung zu formular.php. Und schwups, hasste ein neues SessionCookie! Was ist an dem neuen Cookie Datenschutztechnisch weniger bedenklich?
                        Wir werden alle sterben

                        Kommentar


                        • #27
                          Zitat von combie Beitrag anzeigen
                          Ein letztes Mal zum absurden Vorhaben: "SessionCookie löschen"

                          1. Wie kommst du überhaupt auf die aberwitzige Idee, dass jemand deinen LogoutButton drückt?
                          2. Nach dem Logout gibts bei dir eine Weiterleitung zu formular.php. Und schwups, hasste ein neues SessionCookie! Was ist an dem neuen Cookie Datenschutztechnisch weniger bedenklich?
                          Leute...

                          1. Das ist kein Argument. Es gibt mehr als genug Beispiele, wo die User sehr bewusst auf Logout klicken. Also tue ich ihnen den Gefallen und entferne auch gleich meine Cookies.
                          2. Cheadle != Threadersteller. Bei mir gäbe es diese Weiterleitung nicht.

                          Kommentar


                          • #28
                            Wie löschst du denn den Session Cookie? Du teilst dem Browser mit, er wäre abgelaufen. Der Browser wird ihn also irgendwann abräumen. Damit hast du alles getan, was in deiner Macht steht. Das ist auch gut so, ehrlich.

                            Aber sag mal, wie prüfst du denn, ob ein User eingeloggt ist? Du machst session_start() und dann schaust du in $_SESSION nach, richtig? Das machst du bestimmt auch auf der Startseite so. Und zack, hat jeder der deine Site betritt einen Session Cookie, auch ohne sich ein- oder auszuloggen.

                            Um konsequent zu sein, musst du also für alle anonymen User bei jedem Request, bei dem ein session_start() stattfindet gleich wieder mit setcookie() hinterrennen. Hand aufs Herz, machst du das wirklich?

                            Kommentar


                            • #29
                              Zitat von onemorenerd Beitrag anzeigen
                              Aber sag mal, wie prüfst du denn, ob ein User eingeloggt ist? Du machst session_start() und dann schaust du in $_SESSION nach, richtig? Das machst du bestimmt auch auf der Startseite so. Und zack, hat jeder der deine Site betritt einen Session Cookie, auch ohne sich ein- oder auszuloggen.

                              Um konsequent zu sein, musst du also für alle anonymen User bei jedem Request, bei dem ein session_start() stattfindet gleich wieder mit setcookie() hinterrennen. Hand aufs Herz, machst du das wirklich?
                              Nein, aber ich verwende auch nur selten die PHP-Funktionen...

                              Falls doch, wird der User zu einer Seite weitergeleitet, auf der der Logout bestätigt wird. Hier wird kein Cookie mehr gesetzt. Alles weitere bleibt dem User überlassen.

                              Kommentar


                              • #30
                                Zitat von asp2php Beitrag anzeigen
                                ... mysql_escape_string hier anzuwenden ist überflüssig, die md5 Funktion verändert den Inputstring dermaßen schon, dass eine Gefahr nicht mehr besteht.
                                SELFHTML Forumsarchiv / 2009 / Mai / mysql_real_escape_string und md5 (PHP)
                                I don't believe in rebirth. Actually, I never did in my whole lives.

                                Kommentar

                                Lädt...
                                X