Ankündigung

Einklappen
Keine Ankündigung bisher.

Login, Session und der ganze Rest

Einklappen

Neue Werbung 2019

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

  • Login, Session und der ganze Rest

    Heyho, hab mal wieder ne kleine Verständnisfrage.

    Ich sitze gerade an ner neuen Authentifizierungs-Klasse, ein typisches Login Formular mit DB und Session. Ich hadere noch an einem Punkt. Gegen Spam und Bruteforcing möchte ich die Anzahl der Loginversuche auswerten und je nach Anzahl geeignete Maßnahmen starten (Sleep - Account zeitweise inaktiv - Account Sperrung). Angedacht hatte ich dabei die ohnehin schon existente Session zu nutzen (keine Angst, nach erfolgreichem Account gibts ne neue Session) um die Versuche zu zählern, aber ist das sinnvoll? Oder muß ich bei jedem Loginversuch einen Datenbankeintrag machen?
    Wäre für ein paar Tipps (auch sonstige in diesem Themenbereich) dankbar.

    Gruß --ick
    [COLOR="#F5F5FF"]--[/COLOR]
    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
    [COLOR="#F5F5FF"]
    --[/COLOR]

  • #2
    Wenn das Programm welches die Bruteforce angriffe startet keine Session zulässt, dann bringt dir es auch garnichts die Versuche in einer Session zu speichern. Also wenn du sicher gehn willst würd ichs in die DB eintragen.

    Kommentar


    • #3
      Denke nicht, dass das ein logischer schluss ist. Wenn keine Session zugelassen wird, dann sollte man das bruteforce programm / den user gleich auf eine Fehlerseite leiten. Was bringt einem ein Loginsystem, wenn keine Sessions zugelassen werden?
      Eine Datenbank würde ich dafür nicht hernehmen...

      Das mit der Account-Sperrung finde ich auch nicht so toll. (kommt auf das system an)
      Denn der Übeltäter braucht nur besagte Benutzernamen, die selten geheim sind, um beliebigen Usern immer wieder den zugang durch eine Attacke und der nachfolgenden Sperre des Benutzers zu verwehren.


      EDIT: Hier ging es schonmal um das Thema. Vielleicht hilfts ja. http://www.phpfriend.de/forum/ftopic61137.html

      Kommentar


      • #4
        Danke für den Link, ich erinnere mich noch an den Thread. Ich überlege aber vielmehr, ob es effektiv möglich ist, Fehlanmeldungen ohne ständigen Zugriff auf die DB behandeln zu können. Unabhängig der Diskussion dort, werde ich wahrscheinlich wirklich Sleep und die Sperrung für 15-30 Minuten implementieren. Ne andere sinnvolle Möglichkeit sehe ich nicht. Gegen IP Sperrung hab ich was.
        [COLOR="#F5F5FF"]--[/COLOR]
        [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
        [COLOR="#F5F5FF"]
        --[/COLOR]

        Kommentar


        • #5
          Zitat von RaZoR
          Wenn das Programm welches die Bruteforce angriffe startet keine Session zulässt, dann bringt dir es auch garnichts die Versuche in einer Session zu speichern. Also wenn du sicher gehn willst würd ichs in die DB eintragen.

          Ok!
          wir schreiben alle Versuche in DB. Und weiter?
          Wie werden wir aber diese Versuche zu dem user zuordnen?
          ip-adresse von dem User als identifizierung betrachten?
          da können wir aber bei proxis direkt mehrere besucher nicht mehr von einander unterscheiden.
          betrachten dann eine gebeude mit mehreren pc als einen User?

          Welche möglichkeiten haben wir eigentlich um einen user zu identifizieren?
          das sind eigentlich zufalswerte die wir von eine seite zur anderer übergeben, und können dann an diesem wert einen user identifizieren.
          Eigentlich macht Session gerade das, was ich eben beschrieben habe und nimmt mir einfach die arbeit ab das selbe von hand zu programmieren.

          Also ich kann eigentlcih nur session in betracht ziehen um so was zu realisieren.
          Wenn der user seine 3 falsche eingaben gemacht hat, muss man versuchen die zeit zwischen den versuchen zu zählen und wenn es mehrere falsche versuche innerhalb von sehr kurzer zeit vorkommen, erst dann hat es ein sinn die ip zu sperren, da wir ein realistische verdacht auf ein automatischer angriff haben.
          Slava
          http://bituniverse.com

          Kommentar


          • #6
            Dann schaltet man Cookies aus und die Session spielt nicht mehr mit
            Nicht jeder Fehler ist ein Bug.

            Kommentar


            • #7
              Zitat von KingCrunch
              Dann schaltet man Cookies aus und die Session spielt nicht mehr mit
              wer sagt, dass session nur über Cookies läuft?
              bei einer normaler webanwendung weisst du schon nach dem 2-tem seitenaufruf ob der Keks gesetzt wurde.
              wenn nicht, dann übergibst du einfach session_id über GET bzw POST weiter. wenn du kein zugriff auf php.ini hast, dann machst du einfach mit
              output_add_rewrite_var(session_name(),session_id() );
              weiter, ohne dir weitere gedanken zu machen.

              gibt es bessere vorschläge um einen user zu identifizieren?
              Slava
              http://bituniverse.com

              Kommentar


              • #8
                Das setzt voraus, dass der Bot da mitmacht Es ist nun keine Schwierigkeit, dass du ein bruteForce-Programm schreibst, welches die SID sei es über GET, POST oder COOKIE entfernt und der dann jedes mal eine neue Session bekomt
                Nicht jeder Fehler ist ein Bug.

                Kommentar


                • #9
                  ich glaube, dass wir in Moment über verschiedende Sachen sprechen
                  eine bruteForce-Programm wird versuchen sich einzuloggen, bzw nach dem Zufallsprinzip schon vorhandene session_id zu bekommen. in diesem Fall können wir von mir vorgeschlagene Zeitmessung zwischen Versuchen zu machen oder Anzahl von sessions zu begrenzen.
                  Aber die frage bleibt weiter offen wie willst du denn anderes einen user identifizieren?
                  wie willst du der Anzahl von falschen Versuchen ohne rücksicht, ob es in db, datei oder shared memory gespeichert wird, zu einem user zuordnen?

                  OT:
                  <<Es ist nun keine Schwierigkeit, dass du ein bruteForce-Programm schreibst>>
                  hast du schon eine geschrieben?
                  Slava
                  http://bituniverse.com

                  Kommentar


                  • #10
                    Zitat von Slava
                    OT:
                    <<Es ist nun keine Schwierigkeit, dass du ein bruteForce-Programm schreibst>>
                    hast du schon eine geschrieben?
                    Nö, aber was steckt da schon groß drin? Eine Wort-Liste und ne Schleife, im Groben wars das
                    Nicht jeder Fehler ist ein Bug.

                    Kommentar


                    • #11

                      dann schreib eine, und wir werden den leuten ein kontrollierter Bruteforce-Test anbieten.

                      Ich glaube, dass bei einem richtigem Bruteforce-angriff werden die meisten server früher abschmieren, als du richtiger Password und benutzername gefunden hast.
                      Slava
                      http://bituniverse.com

                      Kommentar

                      Lädt...
                      X