Welches Verfahren als Loginscript?

  • Abend zusammen.

    Ich bin derzeit dran eine Website zu errichten.

    Bin jetzt an meinem ersten wirklichen Problem angelangt.

    Das Loginscript.

    Die Frage ist, welche Variante ich dazu benutzen soll? Bzw. kann ich überhaupt aus verschiedenen auswählen? Wenn Ja, welche ist die Beste (Sicherste)?

    Gibt es evtl. schon diverse Vorlagen die mir helfen könnten?

    Habe bis jetzt immer mit Sessions gearbeitet. In Sachen Sicherheit weiss ich aber noch nicht zu 100% bescheid. Macht es Sinn die Session in einer Tabelle abzuspeichern?

    Für die Antworten danke ich ;)

    MfG XantypiaxD

  • zu deinem Beispiel (jenachdem, können cookies zusätzlich nett sein):

    und nicht alzulanges googlen:
    http://www.administrator.de/index.php?content=40282

    Also, äh, ja. Optimalerweise sollten die usernamen & pw-hashes in einer Datenbank sein (fals die user sich selbst registrieren sollen können - sonst tuts auch eine PHP liste)

    /p.s. aus diesem Beispiel solltest du allerdings $_SERVER['PHP_SELF'] nicht übernehmen.

    2 Mal editiert, zuletzt von Grevas (16. Februar 2011 um 20:55)

  • Danke danke ;)
    Hat mich bei meiner Entscheidung unterstützt ;)


    Edit: Ist es sinnvoll die Session in eine Tabelle einzuschreiben und sie auf gültigkeit abzufragen?
    Oder sollte ich lieber "normal" Sessions abspeichern, wie im Beispiel.

    Edit2: Warum darf ich nicht $_SERVER['PHP_SELF'] .. gibt es dafür eine bessere Lösung?

    2 Mal editiert, zuletzt von XantypiaxD (17. Februar 2011 um 21:57)

  • Du kannst immer mehr Sicherheit integrieren aber irgentwann sind die Änderungen minimal, oder schaden stärk der Userusability folgendes sollte man aber in dem Zusammenhang schon einmal durchsprechen:

    1. Session-IDs werden nach manchen aktionen oder Zeit neu generiert
    2. Passwörter werden gehash und gesaltet in die DB gespeichert
    3. Optional: IP/Agenten erkennungen und jenachdem Multilogins verschiedener IPS vermeiden (für einen gültigen Login)
    4. Optional: Cookies für langen Login, auch wenn der Brwser mal geschlossen wird (RememberMe)
    5. Optional: SessionDBHandler
    6. Optional: Session in UserTabelle (für einen gültigen Login)
    7. Optional: Anmeldung, botSperren, Emailaktivierungen
    8. Optional: Passwort vergessen über Email oder ähnlichen

    Fazit: Man sollte immer schauen für was der Login ist, Communitys sind anders abzusichern als Spiele und die anderes als Seiten die mit Finanzen arbeiten

    Das oben genannte Beispiel funktioniert, aber kaum zu empfehlen.
    Wenn man nicht die kenntnisse hat soll man sich nicht an ein Login waagen, dass geht meistens schief

    mfg

  • [...]
    Fazit: Man sollte immer schauen für was der Login ist, Communitys sind anders abzusichern als Spiele und die anderes als Seiten die mit Finanzen arbeiten

    Das oben genannte Beispiel funktioniert, aber kaum zu empfehlen.
    Wenn man nicht die kenntnisse hat soll man sich nicht an ein Login waagen, dass geht meistens schief
    [...]

    Wenn wir schon dabei sind:

    9. Overengineering

    Fazit:
    Das Script deckt eine Loginprozedur super ab. Bis auf die 2 Mankos die ich bereits erwähnte.

    RememberMe, User- /AcitivityTracking, Anmeldung gehen hier ganz schön am Thema vorbei. Wie du RememberMe und IP-Bindung des Logins so nah beieinander erwähnen kannst, bleibt mir ein Rätsel - aber egal, Hauptsache du hast irgendwas gesagt :) .


    /P.S. um auf die Frage von XantypiaxDhttps://www.forum-hilfe.de/members/14301-XantypiaxD einzugehen:
    brauchst die Session nicht in einer Tabelle zu speichern. Ich persönlich prüfe bei jedem Aufruf nochmal die eingegeben Logindaten ab (in der Session speicher ich nur den passwort-hash, nicht den input) - falls warum auch immer ein User gesperrt werden soll, wird er es damit auch sofort. Wenn du sowas aber nicht brauchst, reicht im prinzip auch ein $_SESSION['loged_in'] = true;

    2 Mal editiert, zuletzt von Grevas (18. Februar 2011 um 14:19)

  • Danke für eure Antworten ;) Hat mir sehr geholfen.

    Habe jetzt dennoch ein kleines Problem. Habe jetzt sobald ich angemeldet bin und die
    Daten stimmen, eine Weiterleitung in den "geschützten" Bereich geplant.

    Ich wollte dies eigentlich mit header() umsetzen. Aber ich bekommen den allseits bekannten
    "Header already sent"-Fehler... Habe jetzt schon sämtliche Sachen ausprobiert (ob_start(), ...)
    aber ich weiss einfach nicht was ich falsch mache, bzw wie ich es anders lösen könnte..

    Hier meine Codes:

    index.php


    login.php

    Einmal editiert, zuletzt von XantypiaxD (18. Februar 2011 um 19:09)

  • Ganz ehrlich, irgendwo reichts.
    Sagst schon selbst, dass das Problem 'berühmt' ist - bemüh die Suche und versuch es zu verstehen... Wurde sogar hier im Forum schon zigmale erklärt.

  • Schau dir mal CMS Systeme an :)

    3 Mal editiert, zuletzt von Pion (19. Februar 2011 um 00:15) aus folgendem Grund: Soll er mit anderen Diskutieren

  • Xanti, bemüh dich mal darum das EVA-prinzip zu verstehen...
    und wenn du schon buffer verwenden willst, dann mach es richtig, dann klappt das auch..
    header klapt nicht, wenn du vorher nen output hattest, also sorge dafür dass es so is.
    vielleicht solltest du doch direkt mit klassen arbeiten, welche die nur verarbeiten und dann bauste die nen view-modul, was die daten aus deinen kontrollklassen auswerten und danach anzeigen kann