Login-Bereich soweit fertig... sicher genug?

[Karsten06]

Hallo!

Mein Login-Bereich ist fast fertig, aber ich bin mir bei der Sicherheit noch nicht ganz sicher Ich will einfach nur mal ein paar Kommentare von euch wie ihr jetzt die Sicherheit einschätzt. Folgendes mal zur Beschreibung wie das bei mir läuft:


- Login mit Username und Passwort über ne etwas versteckte Index-Seite (taucht nicht in der normalen Menüleiste auf); Session wird hier bereits gestartet. Alle Seiten im Login-Bereich haben das meta-Tag "robots"-"noindex". und sonst keine Meta-Tags. Es wird ein Cookie "Login" gesetzt, der keine weiteren Informationen beinhaltet sondern "einfach erstmal nur da" ist.

- Login-Formular leitet weiter auf eine redirect.php-Seite, wo Username und Passwort mit MD5-verschlüsselten DB-Einträgen verglichen werden; Username und Passwort werden zudem durch mysql_real_escape_string() geschickt. In der redirect.php wird außerdem über $_GET['sid'] die von der index.php kommend an die URL angehängte Session-ID mit der gestarteten Session verglichen.
Schließlich wird noch geschaut ob der "Login"-Cookie vorhanden ist, d.h. ob man auch wirklich über die index.php auf die redirect zugreift. Er wird nach Prüfung wieder gelöscht.

Fehlt irgendwas an diesen Daten oder ist inkorrekt, gibt die redirect.php eine Fehlermeldung raus, zerstört die Session und verweigert den Login. Über Header:Location wird man auf die öffentliche Startseite der Page geleitet. Gibt ein User 3x falsches Passwort ein, wird der Account temporär deaktiviert; Mail an Admin, der neu freischalten muss (und nur admin kann das).

Ist mit den Daten alles ok, wird man eingeloggt und die Session-ID wandert in die DB. Gleichzeitig wird ein Timestamp in die DB gesetzt; ist der User nach dem Einloggen zu irgendeinem Zeitpunkt 10 Minuten inaktiv, wird er beim nächsten Seitenaufruf automatisch rausgeworfen.

- php-Seiten im Login-Bereich:
Auf jeder folgenden Seite im Login-Bereich ist oben im Quelltext eine authorize_user.inc eingebunden. Diese überprüft fortwährend, ob der User nicht nur rechtmäßig eingeloggt ist, sondern ob er auch die Rechte hat, um php-Seiten dieser Unterkategorie anzeigen zu lassen (nicht jeder darf Meldungen verfassen und umgekehrt nicht jeder die Terminliste bearbeiten). Berechtigungen für die Kategorien stehen in der DB, gleiche Tabelle wie User und passwort.

Erkannt wird der User jeweils an einem Cookie mit seinem Realname, der auch in der DB steht (auch hier Vergleich unter Verwendung von mysql_real_escape_string() ). Das allein wars aber nicht, die aktive Session wird mit dem SessionID-Eintrag in der DB verglichen; der Realname-Cookie hat außerdem ne Ablaufzeit von 10 Minuten und wird nur erneuert wenn in dieser Zeit ne Seite neu aufgerufen wird. Um vor manipulierten Ablauf-Werten zu schützen, fliegt ein User per Timestamp-Vergleich eh raus wenn 10 Minuten inaktiv. Außerdem wird Multiple User Login über Vergleich mit der SessionID in der DB unterbunden; tritt dies auf, fliegen "beide" User raus.

Was haltet ihr davon? Irgendwas zu unsicher, irgendwas redundant? Das Thema Sicherheit ist wie gesagt noch voll "in Arbeit" auf meiner Page und ich bin für alle Anregungen offen.

Viele Grüße, Karsten

[Shurakai]

Was tust du wenn keine Cookies vorhanden sind?

bzgl. mysql_real_escape_string .... benutzt du die mySQL MD5() funktion oder die von PHP?


Schließlich macht es einen Unterschied, ob du MD5('test\'name') oder md5(test'name) machst ... !

[Manni_the_Dark]

Du solltest eine PHP Datei nicht mit der Endung .inc haben, sonst kann man sie im Browser wie eine normale Textdatei angucken (Es sei denn, du behandelst *.inc-Dateien als PHP-Dateien)

Du könntest das Passwort außerdem noch zusätzlich mit einem Salt verschlüssen, falls du das noch nicht getan hast. (Salted Hash)

Und du könntest für die Session auch noch eine feste IP eintragen, dass heißt, nur von einer bestimmten IP aus kann auf eine laufende Session zugegriffen werden.

[Karsten06]

Original geschrieben von Shurakai
Was tust du wenn keine Cookies vorhanden sind?

bzgl. mysql_real_escape_string .... benutzt du die mySQL MD5() funktion oder die von PHP?


Schließlich macht es einen Unterschied, ob du MD5('test\'name') oder md5(test'name) machst ... !

Der User wird darauf hingewiesen dass er Cookies zwingend braucht. Sind die ausgeschaltet, efolgt kein Login. Zum überprüfen ist der Cookie "Login" von der Index-Seite da. Fehlt der, wird der Login-Vorgang komplett über die("blablabla") abgebrochen, ohne dass die DB überhaupt angesprochen wurde. Bei erfolgreichem Login wird der Cookie gelöscht über setcookie("Login", "goodbye", time()-1)

Ich benutze die md5-Funktion von PHP.


Was die inc-Dateien angeht: ich hab die Includes alle in einem Verzeichnis, das über chmod 711 und ".htaccess --> deny from all " abgesichert ist. Nach meiner Prüfung lassen sich die inc-Dateien so weder direkt anzeigen über den browser noch per Link "ziehen".

[Karsten06]

Original geschrieben von Manni_the_Dark

Und du könntest für die Session auch noch eine feste IP eintragen, dass heißt, nur von einer bestimmten IP aus kann auf eine laufende Session zugegriffen werden.

hm, und was ist mit AOL-Usern? Ich kann mich irren, aber ist das bei denen nciht so dass manchmal mittendrin die IP wechselt? Und was wenn man die verbindung zwischendurch futsch geht und man keine feste ip hat?

[Koala]

jemanden zur Cookieannahme zu zwingen find ich aber
überhaupt nicht nett.

[danysahne333]

ist es auch nicht. ich würde gänzlich auf cookies verzichten. wäre genauso als würde ich ein navigationsmenü komplett in javascript schreiben )

[Karsten06]

wie, auf Kekse ganz verzichten? Die waren bisher einer der wichtigsten Bestandteile meines Login-Bereichs. Über den Realname-Cookie wird in der authorize_user.inc der User erkannt (s. o.). In der gegenwärtigen Version erfolgt der Session-Vergleich erst wenn der Cookie zum DB-Realname passt.

Mich persönlich störts nicht wenn mir wo gesagt wird "Cookies an!" - außerdem handelts sich ja nicht um den öffentlichen Teil der site wo normale user vergrault werden können sondern um den geschützten Bereich wo höchstens sechs Mann Zugriff haben werden (ist ne Vereins-Seite wo diese höchstens sechs Mann über nen von mir geschaffenen kleinen Content Manager Pressemeldungen, Newsletter und Terminlisten reinstellen können).

Reicht es denn aus, dass nur die Session-ID in der DB fortwährend mit der aktiven Session verglichen wird?


Lustig ist als Fussnote hierzu jedoch: der Quelltext jeder einzelnen HTML-Seite der Website (die ich ja fertig als neuer Webmastah übernommen habe außer dem neuen Content Manager) enthält ein völlig (!!) funktionsloses Cookie das nirgendwo anders abgefragt wird und als Wert einzig und allein ein Ablaufdatum enthält. Wer denkt sich sowas aus?!?!

[Herr Kaiser]

Cookie das nirgendwo anders abgefragt wird und als Wert einzig und allein ein Ablaufdatum enthält. Wer denkt sich sowas aus?!?!

wenns nirgendwo abgefragt wird isses natürlich doof ;-) Aber sonst könnte man das schon verwenden... man kann ja abfragen ob es existiert, und wenn nicht(oder doch) ist es ein grund für dieses oder jenes

aber warum nutzt du für die sicherheit kein htaccess? für simple funktionen, wenns nich gross stört wenns mal nicht klappt (klickcounter oder sowas) find ich cookies auch nicht schlimm, aber für so elementare sachen würde ich drauf verzichten...

[Karsten06]

Ich weiß nicht ob man mit htaccess so komfortabel User verwalten kann und ihre Aktivitäten loggen und spezifische Benutzerrechte überwachen/einrichten wie mit nem "richtigen" PHP/MySQL-Login-Bereich.

[paranoia]Schließlich will ich als Admin schon wissen wer wann was genau im Login-Bereich gemacht hat.[/paranoia]

[tontechniker]

Reicht es denn aus, dass nur die Session-ID in der DB fortwährend mit der aktiven Session verglichen wird?

Ich versteh einfach nicht warum mann sich immer wieder ein neues System für Session ausdenken muss? Das System ist sicher und wenn man die Session noch in der Datenbank speichert kann man das auch machen - was allerdings der Realname in einem Cookie soll den jede andere Seite auslesen kann - versteh ich einfach nicht. Die Session ist doch eine toll sache die den User auch eindeutig indentifiziert oder?? Außerdem geht die Sessoin auch in Browser ohne Cookie / bei Usern die Cookies aus haben - sonst hört sich das System relativ sicher an... - die Zeit von 10min würde ich aber grade in deinem fall auf min. 15 hochsetzten da du (wie ich es verstehe) für ein Backend eines CMS programmierst und da kannes es chon vorkommen das man länger als 10min einen Text schreibt oder??

[Karsten06]

Stimmt, das mit den 15 Mins wäre ne Idee, damit man nicht immer alles in nem Texteditor vorher fertig machen muss.

Hab übrigens grad ne "Logout vergessen!"-Funktion reingemacht, die User anmahnt sich richtig auszuloggen nach ner Sitzung... so wie mans von den ganzen Webmailern kennt. Basiert auf ner Spalte "loggedin" (INT(1)) deren Wert 0 oder 1 ist und der nur bei Logout über den dafür vorgesehenen Button auf null gesetzt wird (selbiger button zerstört auch die session und löscht alle (in der jetzigen Version noch gesetzten) cookies.

[tontechniker]

sry aber auch quatsch - wenn du die session id in der db hast löscht du die beim logout einfach - ja die noch drin ist kommt "logout vergessen"

[Karsten06]

stimmt ist eigentlich viel einfacher...