Idee für Login System

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

  • Idee für Login System

    Hallo !
    Ich hab da eine Idee für ein Loginsystem und würde gerne eure Meinung hören:
    Ich mach nach einem erfolgreichen Login einen Hash aus Browser und Session ID. Den schreib ich in die DB und bei jedem Aufruf der Seite wird ein neuer Has generiert, der ja mit dem alten übereinstimmen sollte. Wenn nicht, fliegt der User raus.
    Na, was sagt ihr ?

  • #2
    Hi,
    oder du überlässt das hashgenerieren einfach php. Php muss es
    ohnehin machen wenn eine session beginnt bzw. fortgeführt wird.
    Und dann sparst du dir das ganze generieren und prüfst nur ob ein wert in der session
    gesetz ist. Dieser wert kann ne id oder ein bool flag oder ein userobjekt
    oder was auch immer sein.
    (((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")

    Kommentar


    • #3
      Original geschrieben von closure
      Hi,
      oder du überlässt das hashgenerieren einfach php. Php muss es
      ohnehin machen wenn eine session beginnt bzw. fortgeführt wird.
      Und dann sparst du dir das ganze generieren und prüfst nur ob ein wert in der session
      gesetz ist. Dieser wert kann ne id oder ein bool flag oder ein userobjekt
      oder was auch immer sein.
      Das nützt aber nichts bei zB Session Hijacking. Ursprünglich wollte ich noch die IP zum Hashwert geben, aber dann gibts Probleme mit Proxies. Habt ihr eigentlich irgendwelche Vorschläge, welche Daten ich zum Hashwert dazugeben könnte (sollte möglichst eindeutig sein).

      Kommentar


      • #4
        Original geschrieben von dibsi
        Habt ihr eigentlich irgendwelche Vorschläge, welche Daten ich zum Hashwert dazugeben könnte (sollte möglichst eindeutig sein).
        ... zum Beispiel eine in der Session gespeicherte Startzeit der Sitzung

        Kommentar


        • #5
          ich glaube, dass wenn jemand Begrif "Session Hijacking" verwendet, der muss auch ein wenig Prinzip von Session Hijacking kennen.

          Nur wenn jemand in Netzwerk eingedrungen ist und direckte Komunikation zwischen dem Server und User verfolgen kann, hat die Möglichkeit Session Hijacking ausüben.

          Deine Methode ist genau so von einem Angrif wie auch normale session-führung geschutzt.

          also würde ich einfach SSH sagen.
          Slava
          bituniverse.com

          Kommentar


          • #6
            Original geschrieben von dibsi
            Das nützt aber nichts bei zB Session Hijacking.
            Wenn es sicherheitskritische anwendungen sind ist ohnehin
            SSL angebracht. Dann hat sich dein session-hijacking problem auch
            erledigt. Dabei gibt es unter umständen wieder probleme mit
            einem ähnlich gelagerten fall nämlich man-in-the-middle angriffe
            um eben die ssl-sitzung zu hijacken.

            Du weisst ja sicher das es perfekte sicherheit nicht gibt.
            Die frage ist wie wichtig sind solche überlegungen für deine konkrete
            aufgabe ?

            greets
            (((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")

            Kommentar


            • #7
              hi @closure
              für Session Hijacking wird eigentlich auch nur man-in-the-middle verwendet.
              aber SSL ist schon ein richtige Einsatz.
              Slava
              bituniverse.com

              Kommentar


              • #8
                Original geschrieben von Slava
                ich glaube, dass wenn jemand Begrif "Session Hijacking" verwendet, der muss auch ein wenig Prinzip von Session Hijacking kennen.

                Nur wenn jemand in Netzwerk eingedrungen ist und direckte Komunikation zwischen dem Server und User verfolgen kann, hat die Möglichkeit Session Hijacking ausüben.
                Nein, als session hijacking wird auch das vorige Erstellen einer Session vom Hacker mit dem folgenden Einloggen des Users über einen präparierten Link in eben diese Session und dem Weiterverwenden der Session vom Hacker bezeichnet. Und dafür braucht man keinen Zugriff aufs Netzwerk...
                Aus eben diesem Grunde, gibt es eine Regel, die man besonders beachten sollte beim Umgang mit Sessions. Beim Einloggen den Hash ändern. Dann kann der Hacker die Session nicht mehr nutzen, weil er den Hash nicht kennt.
                Als kleinen Bonus kann man noch implementieren, dass die Session erst gestartet wird, wenn sie auch wirklich benötigt wird; das hält den Hacker davon ab, überhaupt eine valide SID zu erlangen.

                Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                Wie man Fragen richtig stellt

                Kommentar


                • #9
                  hi @ghostgambler
                  erst mal danke für die Information.
                  welche Möglichkeiten gibt es überhaupt einem user präparierten Link zu schieben?
                  also bei E-Mail kann ich mir noch das vorstellen, aber wie kann man das noch machen ohne Man-In-The-Middle zu sein?
                  Slava
                  bituniverse.com

                  Kommentar


                  • #10
                    Original geschrieben von ghostgambler
                    Nein, als session hijacking wird auch das vorige Erstellen einer Session vom Hacker mit dem folgenden Einloggen des Users über einen präparierten Link in eben diese Session und dem Weiterverwenden der Session vom Hacker bezeichnet.
                    nö, das nennt sich wiederum "Session Fixation".
                    aber die idee, beim login eine neue session-id zu generieren ist gut.

                    was ich in diesem thread vermisse, ist das schlagwort: "cookies".
                    generell ist es sicherer die sid nur per cookie übertragen.
                    wenn die sid per GET kommt, würde ich restriktiver überprüfen - z.b. ip- / browser-check ... etc, ansonsten nicht (oder nur sids per cookies zulassen)
                    Original geschrieben von closure
                    Wenn es sicherheitskritische anwendungen sind ist ohnehin
                    SSL angebracht. Dann hat sich dein session-hijacking problem auch
                    erledigt.
                    also wenn die sid per GET kommt, denke ich, hilft ssl auch nicht so viel - stichwort: referer - ich denke mal, der wird auch bei ssl übetragen (kann mich aber auch täuschen), aber auf alle fälle schützt es nicht, wenn ein depp einen link mit seiner sid postet.

                    Kommentar


                    • #11
                      Original geschrieben von 3DMax
                      nö, das nennt sich wiederum "Session Fixation".
                      Hm ... ist sprachlich irgendwie etwas dahingemurkst wie ich finde, ist aber korrekt *kopf kratz* nyo

                      Hier gibt es ein hübsches PDF zum Thema Session Fixation Attacks
                      http://www.acrossecurity.com/papers.htm

                      Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                      bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                      Wie man Fragen richtig stellt

                      Kommentar


                      • #12
                        Original geschrieben von Slava
                        hi @closure
                        für Session Hijacking wird eigentlich auch nur man-in-the-middle verwendet.
                        aber SSL ist schon ein richtige Einsatz.
                        Deswegen sprache ich von "ähnlich gelagertem problem". Im detail unterscheiden
                        sich diese beiden methoden jedoch. Beim http-session hijacking bzw. bei
                        dessen vorbereitung handelt es sich um einen passiven angriff. Der angreifer
                        braucht, wie du bereits sagtest, nur zugriff auf das netzwerk und kann
                        dann passiv die packete mitlesen und so die session-informationen auslesen
                        und später im eigentlichen angriff verwenden.

                        Wenn es um ssl-sessions geht ist der angriff aktiv. Der angreifer ist man-in-the-middle und muss bereits beim challenge-response-handshake
                        aktiv eingreifen in dem er die sitzungsschlüssel abfängt und dem server und
                        dem opfer jeweils seinen sendet.

                        @3DMax
                        Wenn jemand zugang zu den packeten zwischen den server und client
                        hat hilft auch ein cookie nichts. Man kann die header der anfragen dann
                        auch sehen. Und dann kann man einfach die eigenen anfragen mit der
                        im cookie enthaltenen SID spoofen.
                        Wenn die sache per GET passiert, da hast du natürlich recht, hilft das
                        alles nix.

                        greets
                        (((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")

                        Kommentar


                        • #13
                          Die methode session_regenerate_id(); vergibt eine neue session_id, so dass du mit jedem Request enweder eine neue session-id hast oder feststellen kannst, dass ein session-hijacking angriff erfolgt ist (alte session-id ungültig);
                          PHP-Code:
                          session_regenerate_id();
                          if (!%
                          _SESSION['valid_chk']) {
                          die(
                          "angriff festgestellt");

                          Nicht vergessen, beim login $_SESSION['chk'] auf true zu setzten! (man kann natürlich auch anders feststellen, ob die session ok ist.)

                          falls du auch zwischen zwei requests ein session-hijacking verhindern willst, kannst du das mit ajax-requests oder einem hidden-iframe lösen. Dabei wird die aktuelle session-id gecheckt, ohne sie zu erneuern, z.B. mit einer session_check.php:
                          PHP-Code:
                          <php?
                          session_start();
                          if (
                          $_SESSION['valid_chk']) echo "ok";
                          else echo 
                          "failed";
                          ?> 

                          Kommentar


                          • #14
                            Original geschrieben von frido37
                            Die methode session_regenerate_id(); vergibt eine neue session_id, so dass du mit jedem Request enweder eine neue session-id hast oder feststellen kannst, dass ein session-hijacking angriff erfolgt ist (alte session-id ungültig);
                            Ungültig (geworden) durch was?

                            Das könntest du höchstens durch den optionalen Parameter bewirken - den du in deinem Beispiel aber nicht nutzt, und der erst ab 5.1.0 verfügbar ist.
                            I don't believe in rebirth. Actually, I never did in my whole lives.

                            Kommentar

                            Lädt...
                            X