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

  • nikosch
    hat ein Thema erstellt Login, Session und der ganze Rest.

    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

  • Slava
    antwortet

    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.

    Einen Kommentar schreiben:


  • KingCrunch
    antwortet
    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

    Einen Kommentar schreiben:


  • Slava
    antwortet
    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?

    Einen Kommentar schreiben:


  • KingCrunch
    antwortet
    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

    Einen Kommentar schreiben:


  • Slava
    antwortet
    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?

    Einen Kommentar schreiben:


  • KingCrunch
    antwortet
    Dann schaltet man Cookies aus und die Session spielt nicht mehr mit

    Einen Kommentar schreiben:


  • Slava
    antwortet
    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.

    Einen Kommentar schreiben:


  • nikosch
    antwortet
    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.

    Einen Kommentar schreiben:


  • pepe24
    antwortet
    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

    Einen Kommentar schreiben:


  • Flor1an
    antwortet
    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.

    Einen Kommentar schreiben:

Lädt...
X