Wie gestalte ich ein sicheres Loginsystem? (Im Detail)
0 
Matthias Apsel
0 1 
molily
0 0 http://www.php-login.net/
Wie gestalte ich ein sicheres Loginsystem? (Im Detail)
AugeWie sieht ein sicheres Loginsystem aus? Session, Cookies oder MySQL (Oder alles zusammen)?
-
Om nah hoo pez nyeetz, lska!
Wie sieht ein sicheres Loginsystem aus? Session, Cookies oder MySQL (Oder alles zusammen)?
- In einer Session legst du ein paar Daten ab, die für das Login wichtig (oder auch weniger wichtig) sind
- Auf cookies kannst du verzichten, sie liefern lediglich Komfort wie angemeldet bleiben, …
- eine Datenbank hat mit dem Loginsystem nichts zu tun, du benötigst dennoch die Zuordnung Benutzername - Passwort. Das kann auch eine einfache Textdatei sein
selhtmlwiki -- Loginsystem
unfertige NeufassungMatthias
-
Hello,
- Auf cookies kannst du verzichten, sie liefern lediglich Komfort wie angemeldet bleiben, …
Man kann das auch mit Auth-Basic oder Auth-Digest machen.
Ich bevorzuge allerdings Cookies. Für die Session benötigt man schließlich auch einen, wenn man die Session-ID nicht ständig in der Request-URi mitführen will.
Der "Sessioncookie" muss aallerdings nur solange leben, wie die Browserinstanz lebt, ist aber ein Cookie!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo
- Auf cookies kannst du verzichten, sie liefern lediglich Komfort wie angemeldet bleiben, …
Man kann das auch mit Auth-Basic oder Auth-Digest machen.
Ich bevorzuge allerdings Cookies. Für die Session benötigt man schließlich auch einen, wenn man die Session-ID nicht ständig in der Request-URi mitführen will.
Was macht, speziell in dieser Frage, den Unterschied zwischen Session-Cookie und Auth-Token aus? Beide werden bei jedem Request übertragen und beide können serverseitig ausgewertet werden.
Der "Sessioncookie" muss aallerdings nur solange leben, wie die Browserinstanz lebt, ist aber ein Cookie!
Das ist beim Auth-Token automagisch gegeben.
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
Veranstaltungsdatenbank Vdb 0.3-
Hello,
Was macht, speziell in dieser Frage, den Unterschied zwischen Session-Cookie und Auth-Token aus? Beide werden bei jedem Request übertragen und beide können serverseitig ausgewertet werden.
Der "Sessioncookie" muss aallerdings nur solange leben, wie die Browserinstanz lebt, ist aber ein Cookie!
Das ist beim Auth-Token automagisch gegeben.
Definiere bitte "Auth-Token".
Und mMn setzen übliche Browser den "Auth-Token" als "Session-Cookie" um, also als solchen, der beim Schließen der Browserinstanzen, für die er vorgesehen war, ungültig wird und möglichst auch gelöscht.
Ich verstehe jetzt aber nicht, was Du überhaupt sagen wolltest.
Du verwechselst jetzt aber nicht Auth-Basic/Auth-Digest mit Auth-Token/Sessioncookie?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo
Was macht, speziell in dieser Frage, den Unterschied zwischen Session-Cookie und Auth-Token aus? Beide werden bei jedem Request übertragen und beide können serverseitig ausgewertet werden.
…
Du verwechselst jetzt aber nicht Auth-Basic/Auth-Digest mit Auth-Token/Sessioncookie?Ok, ich habe mich missverständlich ausgedrückt. Ja, ich meine Auth-Basic/-Digest, also die Eingabe von Benutzername und Passwort und deren Übertragung an den Server. Die Authentifizierungsdaten werden bis zum Ende der Browsersession bei jedem Request an den aufgefordert habenden Server mit übertragen.
Speziell in Hinsicht auf deinen Gedankengang halte ich Auth-* zu Cookies für gleichwertig. In beiden Fällen kann man das übertragene Datum serverseitig auswerten. Dass sich dieses Bild bei weiteren Anforderungen ratzfatz ändert, ist klar.
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
Veranstaltungsdatenbank Vdb 0.3-
Hello,
Du verwechselst jetzt aber nicht Auth-Basic/Auth-Digest mit Auth-Token/Sessioncookie?
Ok, ich habe mich missverständlich ausgedrückt. Ja, ich meine Auth-Basic/-Digest, also die Eingabe von Benutzername und Passwort und deren Übertragung an den Server. Die Authentifizierungsdaten werden bis zum Ende der Browsersession bei jedem Request an den aufgefordert habenden Server mit übertragen.
Speziell in Hinsicht auf deinen Gedankengang halte ich Auth-* zu Cookies für gleichwertig. In beiden Fällen kann man das übertragene Datum serverseitig auswerten. Dass sich dieses Bild bei weiteren Anforderungen ratzfatz ändert, ist klar.
Das ist keinesfalls gleichwetig.
siehe
http://www.w3.org/2001/sw/Europe/events/foaf-galway/papers/fp/token_based_authentication/Das ist zwar eine Menge Geschreibe um Dinge, die schon seit dem Beginn der Netzwerktechnik klar waren, aber das w3 hat es gehostet, und damit muss es ja nun gut sein ;-))
Kurz: Auth-Basic überträgt bei jedem Request die Original-Credentials, die sich auch nach der Sitzung nicht unbedingt ändern werden, also Bestand haben.
Auth-Token ==(=) Session-Cookie überträgt einen Ersatzschlüssel mit begrenzter Haltbarkeit. Klar, das Passwort und der Loginname müssen auch erst einmal durchs Netz, das muss aber nicht in einem Request erfolgen, sondern kann auch auf zwei aufgeteilt werden. Dafür kann man dann denselben Token verwenden (ohne Authorisierung, nur zur Identifizierung) und ihm im zweiten Schritt die Auth-Rechte zuordnen, oder man nimmt besser zwei Tokens.
Aber solange alles unverschlüsselt übertragen wird, dient diese vermeintliche Sicherheit sowieso nur gegen billige Gangster. Die Profis lesen mit. Und die absoluten Obergangster klinken sich am Quell- oder Zielport ein, nutzen das Tagging, stellen den Server-Host fest und greifen dort direkt ab. Solange die Kommunaktion durch die Obergangster-Netze flitzt und keine anderen dazwischen sind, bleiben die Tags an den Paketen erhalten. Im Falle einer "notwendigen Abschaltung" des Netzes kann man so die ungetaggten einfach unterdrücken, die anderen bequem verfolgen.
Das wissen wir ja nicht erst seit Snowden.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Speziell in Hinsicht auf deinen Gedankengang halte ich Auth-* zu Cookies für gleichwertig. In beiden Fällen kann man das übertragene Datum serverseitig auswerten.
Es sind zwei unterschiedliche Ansätze und es ist m.M.n. verwirrend, sie ohne weiteres in einem Atemzug erwähnen. Das eine ist Authentifizierung auf Request-Ebene, das zweite sind Sessions mit (optionaler) Authentifizierung.
HTTP ist ein zustandsloses Protokoll und mit Sessions versucht man dies aufzuheben, indem man mehrere Requests über ein gemeinsames Datum zusammenfasst – die Session-ID.
Die Session-IDs werden serverseitig gespeichert (nicht notwendig, aber üblicherweise) und es können weitere Daten mit ihnen verknüpft sein ($_SESSION bei PHP). Die Session wird also serverseitig erzeugt und kann serverseitig beendet werden. Die verknüpften Daten werden gelöscht werden, sobald die Session beendet wird.
Mit Session-IDs kann man *auch* Authentifizierung umsetzen, muss es aber nicht. Dazu wird ein Loginstatus in der Session gespeichert. Nach erfolgter Anmeldung mit Username/Passwort oder sonst einem Token gelten sämtliche Requests, die die Session-ID übermitteln, als »beglaubigt«.
Das alles gibt es bei HTTP Auth nicht, weil hier eine Authentifizierung für einen einzelnen Request stattfindet. Es wird keine Session erzeugt in dem Sinne, dass statuslose HTTP-Requests einen Status bekommen. (Wenn man einmal von der Nonce bei Digest Auth absieht, die ein gemeinsames Datum zwischen Requests darstellt – diese ist m.W. zufällig und ewig gültig.)
Mathias
-
Hello,
Mit Session-IDs kann man *auch* Authentifizierung umsetzen, muss es aber nicht. Dazu wird ein Loginstatus in der Session gespeichert. Nach erfolgter Anmeldung mit Username/Passwort oder sonst einem Token gelten sämtliche Requests, die die Session-ID übermitteln, als »beglaubigt«.
Der "Loginstatus" muss nicht in die Sessiondatei geschrieben werden. Man kann ihn auch bei jedem Request neu ermitteln, z.B. mit Hilfe der Datenbank. Das ist zu empfehlen, da man dadurch requestbasiert reagieren kann und nicht nur sessionbasiert.
Das alles gibt es bei HTTP Auth nicht, weil hier eine Authentifizierung für einen einzelnen Request stattfindet.
Nur weil PHP auf Anhieb keine Funktionen dafür bereit stellt, kann man nicht behaupten "das gibt es nicht". Selbstverständlich kann man auch auf Auth-Basic eine Session aufbauen. Mit etwas Getrickse kann man sogar die Sessionfunktionen von PHP dafür verwenden und muss nicht _alles_ selber stricken.
Man muss sich nur entscheiden, was man will.
Idendifizierung mit integrierter (Teil-)Authorisierung
daran dann eine Sessiondatei ankoppelnoder
erst eine Sessiondsatei eröffnen
und dann mittels Identifikation eine (Teil-)Authentifizierung durchführen.Unter "Session" versteht man üblicherweise Identifikation + Authorisierung + Datenzuordnung
Was PHP als "Session" bezeichnet, ist nur die Sessiondatei + Identifikation
Der Nachteil von Loginname/Passwort gegenüber Auth-Key ist ja in
<[link:http://www.w3.org/2001/sw/Europe/events/foaf-galway/papers/fp/token_based_authentication/>
lang- und breitgelatscht worden.Ein weiterer Nachteil von Auth-Basic ist, dass eine "Abmeldung" nur mittels Änderung des (Usernames oder) Passwortes möglich ist (Usernamen ändern wird nicht empfohlen!).
Alternativ kann man nur alle Browserfenster schließen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Der "Loginstatus" muss nicht in die Sessiondatei geschrieben werden.
Muss man nicht – habe ich auch nicht behauptet –, aber üblich ist es. Dafür sind Sessions gedacht.
Man kann ihn auch bei jedem Request neu ermitteln, z.B. mit Hilfe der Datenbank.
Man kann sich auch auf den Kopf stellen und dabei eine Limo trinken.
Das ist zu empfehlen, da man dadurch requestbasiert reagieren kann und nicht nur sessionbasiert.
Diese Unterscheidung halte ich für verwirrend – das hatten wir bereits und ich habe alles nötige dazu gesagt.
Nur weil PHP auf Anhieb keine Funktionen dafür bereit stellt, kann man nicht behaupten "das gibt es nicht".
Nein, es ist KONZEPTIONELL nicht möglich, dass HTTP Auth die BESAGTEN Eigenschaften von Sessions erfüllt. Welche und warum, habe ich beschrieben. Ich werde es nicht wiederholen, da ich mich, wie ich finde, recht klar ausgedrückt habe.
Selbstverständlich kann man auch auf Auth-Basic eine Session aufbauen.
Das wäre eine »Session«, die nie wirklich anfängt und nie wirklich endet. Der Anfang wäre der erste authentifizierte Request, das Ende kann höchstens heuristisch mit einem Timeout bestimmt werden. Ein aktives Beenden der Session ist nicht möglich, wie du auch schreibst.
Also ist es keine wirkliche Session, sondern bloß ein Log, das den letzten authentifizierten Request verzeichnet.
Für Mitlesende, die sessionbasierte Logins umsetzen wollen, sind solche praxisfernen, rein hypothetischen Diskussionen bloß verwirrend. Noch einmal: HTTP Auth ermöglicht Authentifizierung, aber keine Sessions im besagten Sinne.
Mathias
[1] »What are Sessions? – HTTP is a stateless protocol. Sessions make it stateful.« http://guides.rubyonrails.org/security.html#what-are-sessions-questionmark
-
Hello,
Der "Loginstatus" muss nicht in die Sessiondatei geschrieben werden.
Muss man nicht – habe ich auch nicht behauptet –, aber üblich ist es. Dafür sind Sessions gedacht.
Man kann ihn auch bei jedem Request neu ermitteln, z.B. mit Hilfe der Datenbank.
Man kann sich auch auf den Kopf stellen und dabei eine Limo trinken.
Nun sei doch nicht gelich beleidigt, weil ich hier gegen die irrige Meinung auftrete, dass ein "Logged-Flag" in die Sessiondatei gehören würde. Das hast Du dir doch auch nicht ausgedacht, sondern wiederholst es nur, weil Du bisher nix anderes kennengelernt hast :-P
Das ist zu empfehlen, da man dadurch requestbasiert reagieren kann und nicht nur sessionbasiert.
Diese Unterscheidung halte ich für verwirrend – das hatten wir bereits und ich habe alles nötige dazu gesagt.
Requestbasiert: gilt pro Request
Sessionbasiert: gilt für die ganze Session.Darüber haben die damals bei Novell ganze Bücher geschrieben.
(Ich hab's mir also auch nicht selber ausgedacht) :-)Nur weil PHP auf Anhieb keine Funktionen dafür bereit stellt, kann man nicht behaupten "das gibt es nicht".
Nein, es ist KONZEPTIONELL nicht möglich, dass HTTP Auth die BESAGTEN Eigenschaften von Sessions erfüllt. Welche und warum, habe ich beschrieben. Ich werde es nicht wiederholen, da ich mich, wie ich finde, recht klar ausgedrückt habe.
Nein, Du bist einfach nur beleidigt.
Nach deiner Lesart kann aber der PHP-Sessionmechanismus (das ist noch keine Session!) konzeptionell auch nicht die "besagten" Eigenschaften von HTTP-Auth erfüllen, denn mit einem Aufruf von "session_start()" habe ich noch lange keine Authorisierung durchgeführt.
Andersherum habe ich mit einer Anmeldung per HTTP-Auth aber sowohl eine Authentifizierung als auch eine Authorisierung, aber noch keine Session-DATEI. Die kann ich aber sehr wohl "zu Fuß" anschließen, da ich ja weiß, wem die Daten gehören, die da übermittelt werden.
Selbstverständlich kann man auch auf Auth-Basic eine Session aufbauen.
Das wäre eine »Session«, die nie wirklich anfängt und nie wirklich endet. Der Anfang wäre der erste authentifizierte Request, das Ende kann höchstens heuristisch mit einem Timeout bestimmt werden. Ein aktives Beenden der Session ist nicht möglich, wie du auch schreibst.
Das ist in erster Linie ein Manquo der Browser. Und auf dem Server kann man sehr wohl die Authorisierung beenden. Damit wäre dann auch die Session zuende. Es ist aber äußerst unpraktisch für den User. Der benötigt dann nämlich ein neues Passwort. Und das schrieb ich auch!
Also ist es keine wirkliche Session, sondern bloß ein Log, das den letzten authentifizierten Request verzeichnet.
Das verstehe ich jetzt nicht. Was ist nur ein Log?
Eine "wirkliche Session" gibt es in der "verbindungslosen" Kommunikation sowieso nicht. Dort werden nur einzelne Nachrichten verschickt. Es gibt keinen Träger, keine Stromschleife oder ähnliche Mittel, durch die man physisch erkennen kann, dass die Verbindung gekappt wurde.
Eine "wirkliche Session" ermöglicht dem Server die Feststellung _angemeldeter_ Benutzer, also mit aktiver Session. Eben dies ist bei HTTP nicht möglich. Welche Vorgehnesweise nun "stateful" ist, können wir ja nochmal zur Diskussion ausschreiben.
Die Verwendung eines Auth-Tokens ist ein eleganter Ersatz für Username/Passwort.
Für Mitlesende, die sessionbasierte Logins umsetzen wollen, sind solche praxisfernen, rein hypothetischen Diskussionen bloß verwirrend. Noch einmal: HTTP Auth ermöglicht Authentifizierung, aber keine Sessions im besagten Sinne.
Das ist absolut nicht praxisfern. Du verstehst es nur nicht.
Und außerdem möchte ich nochmals daran erinnern, dass es darum ging, Cookies zu verwenden, oder nicht. Und ich habe den Zweig "Session mit HTTP-Auth" nur erwähnt, weil es sehr wohl möglich ist, eine Session damit zu betreiben. Dass es unsicherer ist, Auth-Daten direkt für die "Verbindungserkennung" zu benutzen, habe ich auch erwähnt. Das führt dann zum Auth-Token.
Dass die Browser die Crendetials auch ohne Aufforderung ständig weitersenden und keine Möglichkeit der Löschung im Cache vorsehen, ist ein konzeptioneller Fehler der Browser, nicht der Server.
Und außerdem könnte man auch bei HTTP-Auth auf ein Token wechseln. Der eigentlich "geschützte Bereich" kann ja ganz woanders zu finden sein, als die Anmeldung.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
-
-
Hallo,
- Auf cookies kannst du verzichten, sie liefern lediglich Komfort wie angemeldet bleiben, …
Cookies sind essentiell, um die Session-ID zu übertragen und somit einzelne HTTP-Requests als zusammengehörig zu erkennen – und als authentifiziert, da mit der Session-ID der serverseitig Login-Status verknüpft ist.
Andere Übertragungswege sind möglich, aber unsicherer. Der Verzicht auf Sessions (Authentifizierung mit jedem Request mitsenden, wie bei HTP Basic oder Digest Auth) ist möglich, aber unsicherer. (Kurz gesagt.)
Mathias
-
Hallo Matthias,
unabhängig von der Machart des Login Systems: Was haltest Du davon, bei einem Loginsystem mit zeitlicher Begrenzung (also zB. automatischer Logout nach 15 Minuten) als eine _zusätzliche_ Sicherheitsstufe bei jedem Seitenaufruf nicht nur den Loginstatus zu überprüfen, sondern auch, ob die IP des Clients die selbe ist wie zum Zeitpunkt des Logins? (Was in diesem Beispiel ja maximal 15 Minuten her sein kann.)
Oder sind da dynamische IPs ein Argument, das _nicht_ zu tun?
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?-
Hello Melvin,
ich bin zwar nicht Matthias, aber möchte auf deine Frage doch mal antworten.
unabhängig von der Machart des Login Systems: Was haltest Du davon, bei einem Loginsystem mit zeitlicher Begrenzung (also zB. automatischer Logout nach 15 Minuten) als eine _zusätzliche_ Sicherheitsstufe bei jedem Seitenaufruf nicht nur den Loginstatus zu überprüfen, sondern auch, ob die IP des Clients die selbe ist wie zum Zeitpunkt des Logins? (Was in diesem Beispiel ja maximal 15 Minuten her sein kann.)
Leider sind hier in diesem Thread verschiedene Anliegen durcheinander geraten. Darum möchte ich nochmal zusammenfassen:
Wir sprechen von HTTP 1.0 oder 1.1, also von einem Protokoll, an dem wir als PHP-Applikationsentwickler nichts ändern können.
Wir können die fehlende Session-Bindung, also ein "Stateful" Protokoll, dass in der Netzwerkschicht (z. B. TCP) grundlegend ermöglicht wird und in der Sessionschicht implemnetiert werden kann in der Applikationsschicht (also die API für PHP) nicht herstellen, ohne in die darunterliegenden Schichten einzugreifen. Wir können es bestenfalls emulieren.
Das wird bei den derzeitigen Möglichkeiten von Clients und PHP unter der Annhame, dass uns nur HTTP zur Verfügung steht, am besten realisiert werden mit Auth-Tokens, also den "Session-Cookies" von PHP.
Die andere Möglichkeit, Authenzifizierung und Authorisierungsnachweis über Http-Auth-Basic zu betreiben, ist schon eine Stufe schlechter, weil dann bei jedem Request zur Wiedererkennung sowohl Loginname als auch Passwort übermittelt werden müssen. Es sind andere Konstruktionen denlbar, aber nicht üblich.
Die Gültigkeit des Auth-Tokens bei jedem Request zu testen ist sinnvoll.
Das funktioniert bei PHP aber nur dann sinnvoll, wenn er nicht in der Sessiondatei selbt eingetragen wird, denn die ist ohne zusätzliche Maßnahmen aus Serversicht gar nicht dem User zuzuordnen (da stehen z.B. ca. 70.000 Dateien mit sess_* im Verzeichnis, welche gehört jetzt zum User?), also erfragen wir die Berechtigung doch gleich in der DB-Tabelle. Das hat bei passendem Select-Statement auch noch den Vorteil, dass wir wissen können, welche User in den letzten x Sekunden einen Request hatten. Und wir können die Session dort für ungültig erklären, ohne aus Versehen einen falschen User zu erwischen.Eine "stateful Session" (das ist jetzt eigentlich doppelt gemoppelt) können wir selber in HTTP aber nicht aufbauen. Selbst unter Verwendung von AJAX für einen "Keep Alive Heartbeat" ist es nicht möglich, HTTP von außen zu einem symmetrischen Protokoll zu machen. Es wird bauartbedingt immer ein unsymmetrisches (definierter Client und Server) bleiben. Man unterscheidet da noch zwischen "halboffenen" und "halbgeschlossenen" Protokollen.
HTTP lässt jedenfalls keine Anfrage vom Server an den Client zu, nur Antworten auf Anfragen. Auch wenn der Client und der Server die "Verbindung" aufrecht erhalten (HTTP 1.1), ist trotzdem geregelt, dass der Server dem Client keine Requests senden darf.
Dass das in korrumpierten Systemen vielleicht trotzdem möglich ist, steht auf einem anderen Blatt.
Die Gültigkeit eines Auth-Tokens kann man leicht am Server beenden oder ihn am Client wegwerfen.
Die Gültigkeit der HTTP-Auth-Basic Credentials lässt sich auf Serverseite nur beenden, wenn man das Passwort ändert oder (noch schlechter) den User ganz deaktiviert.Wenn ein Client keine Cookies zulässt, lässt sich eine saubere Auth-Token-Lösung nicht implementieren. Die Tokens schwirren dann immer wieder irgendwo sichtbar herum (in der URi).
Das ist aber technisch bedingt. Die Browser könnten z.B. auch eine Möglichkeit schaffen, die Credentials für Auth-Basic wieder zu vergessen, ohne (im Extremfall) das Programm beenden zu müssen.
Die IP einzubeziehen ist bei diesem Protokolltyp (HTTP) nicht sinnvoll, da es den eigentlichen Sinn des Protokolls konterkarieren würde. AOL hat uns das ganz massiv vorgeführt.
Ich habe auch bei meinem 1&1 Zugang seit längerem die IPs jeden Tag registriert. Das hat mir gezeigt, dass es auch nicht mehr sinnvoll ist, die Netzwerkanteile der IP einzubeziehen. Die wechseln auch, wenn auch bisher nur zwischen zwei Netzen, teilweise mehrmals täglich (wir haben hier öfter kurze Stromausfälle). Wenn ich aber die Lastteilung mit dem Nachbarn zuschalte, haben wir schon sechs (ich zwei, er vier) unterschiedliche Netze für unser DSL. Und die Client-Anteile variieren über die ganze Breite der C-Netze.
Beantwortet das jetzt ungefähr deine Frage?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom,
danke für Deinen ausführlichen Input!
Beantwortet das jetzt ungefähr deine Frage?
Naja, den ersten Teil habe ich _überhaupt nicht_ verstanden. Das hättest Du mir auch ein chinesisches Buch über Topfpflanzen hinlegen können. Das übertrifft mein Wissen und Verständnis um Lichtjahre. Aber wenn ich es richtig verstanden habe, sprichst Du da ja die Authentifizierung per .htaccess Datei und mit AuthType Basic an. Ich hingegen sprach rein von einem herkömmlichen Loginsystem _ohne_ .htaccess Authentifizierung, also so, wie es im Erstposting dieses Threads IMHO gemeint war.
Aber Bezug nehmend auf Deinene letzten 2 Absätze, wo Du auf meine eigentliche Frage eingehst:
Die IP einzubeziehen ist bei diesem Protokolltyp (HTTP) nicht sinnvoll, da es den eigentlichen Sinn des Protokolls konterkarieren würde. AOL hat uns das ganz massiv vorgeführt.
Auch da verstehe ich nicht, wie Du das meinst, aber wenn ich den darauf folgenden Absatz richtig interpretiere, dann bist Du der Meinung, dass IPs ein und derselben Nutzer zu oft wechseln, als dass man das einbauen soll. Richtig?
Meine persönliche Herangehensweise:
Auf meinem Webspace gibt es auch einen Bereich, der nicht für jeden bestimmt ist. Es existieren ein paar Gruppen, denen dann auf ein und der selben Seite je nach Gruppe verschiedene Inhalte präsentiert werden. Dort löse ich den Login, der nach 15 Minuten automatisch beendet wird, folgendermaßen:
Die Übertragung von Gruppenname und PIN erfolgt mit SSL. Ist die Überprüfung der Daten erfolgreich, passiert folgendes: Aus einer Kombination aus time() in Mikrosekunden und einer Stringkette entsteht eine 30-stellige unique Zufalls ID. Diese ID ordne ich einer neuen 15-Minuten-Loginzeit eines Useres zu. Der User selbst bekommt einen Cookie 'id' mit der ihm zugeteilten ID und der Ablaufzeit von 15 Minuten. Auf dem Server wird eine Session angelegt. Dabei ist die ID der Variablenname und der Variablenwert entspricht dem Gruppennamen, für die man eingeloggt ist. Zusätzlich gibt es auf dem Server eine .txt Datei mit einem Array, in dem die Indices den Timestamp des Login-Endes und die Werte die IDs wiedergeben. Die neu erstellte ID wird nun samt dem gewünschten Gültigkeits-Endzeitpunkt in dieses Array dazugespeichert.
Bei jedem Seitenaufruf, wo nun ein Login bzw. die zugehörige Gruppe überprüft werden soll, müssen für eine erfolgreiche Ausgabe 3 Punkte erfüllt sein:
1.) Beim User muss sich ein Cookie 'id' befinden.
2.) Auf dem Server muss sich eine Sessionvariable befinden, deren Name der Inhalt des 'id' Cookies ist.
3.) Das Array der .txt Datei wird ausgelesen und sämtliche Werte, deren Integerwert des Indexnamens kleiner als der aktuelle Timestamp sind, werden gelöscht. Danach muss sich der Inhalt des 'id' Cookies noch immer als Wert imm Array, das jetzt nach der Bereinigung wieder gespeichrt wird, befinden.Trifft das alles zu, gilt der User als eingeloggt und die Ausgabe erfolgt der Gruppe entsprechend. Anderenfalls gibt es eine automatische Weiterleitung zur Loginseite, wobei sämtliche evt. existierende Cookies und SESSION Variablen gelöscht werden.
Bei jedem Aufruf einer geschützten Seite verwende ich zusätzlich session_regenerate_id(). Die Passwörter der Gruppen sind md5()-gespeichert. Die Datei mit den Gruppen und Passwörtern sowie alle anderen Ressourcen, die hier arbeiten, liegen außerdem außerhalb des Rootverzeichnisses meiner Domain, können also vom User nicht direkt per URL aufgerufen und ausgelesen werden.
Dieses System kommt ohne einer Datenbank aus und für die Verwaltung der paar Gruppen, mit denen ich hier arbeite, ist das IMHO _mehr_ als sicher.
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?-
Hello,
Dieses System kommt ohne einer Datenbank aus und für die Verwaltung der paar Gruppen, mit denen ich hier arbeite, ist das IMHO _mehr_ als sicher.
Glückwunsch!
Wo liegt denn Deine Textdatei für die User?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom,
Glückwunsch!
Wo liegt denn Deine Textdatei für die User?Die User und Passwörter sind in einer PHP Ressource gespeichert, damit man direkt damit arbeiten kann:
<?php $groups = array(); $groups['admin'] = '91b827e257eeae8e5989d961fe3011df'; $groups['gruppe1'] = 'd4061b1486fe2da19dd578e8d970f7eb'; $groups['gast'] = '6dc13510ac2bcf8ac6c2226b2e16e51e'; ?>Abgesehen davon, dass die Passwörter md5()-kodiert gespeichert sind, liegt die Ressource ebenfalls außerhalb des Rootverzeichnisses, kann also noch dazu auch nicht direkt aufgerufen werden.
Falls es Dich interessiert, ich habe es (hier ohne SSL) als Beispiel online gestellt.
Von der Indexseite aus kommt man entweder zum Login, oder zum geschützten Directory. Vom Directory aus kommt man zu den Beispielseiten. Von den Beispielseiten aus kommt man zu Indexseite und Directory zurück. Solange man aber nicht eingeloggt ist, landet man _immer_ beim Login. Der Link zur Loginseite bewirkt ein automatisches Ausloggen.
Mögliche User :
" gast " mit dem Passwort " gast "
" admin " mit dem Passwort " 0815 "Der Login ist bei diesem Beispiel auf 5 Minuten beschränkt.
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?-
Hello,
<?php
$groups = array();
$groups['admin'] = '91b827e257eeae8e5989d961fe3011df';
$groups['gruppe1'] = 'd4061b1486fe2da19dd578e8d970f7eb';
$groups['gast'] = '6dc13510ac2bcf8ac6c2226b2e16e51e';
?>Hier machst Du dir noch das Leben schwer. Es gibt serialize() / unserialize -> <http://de1.php.net/manual/en/function.serialize.php> und parse\_ini\_file() -> <http://de1.php.net/manual/en/function.parse-ini-file.php> um strukturiert Daten abzulegen. Wenn die Datenmenge nicht zu groß wird, sind die beiden, je nach Einsatzzweck, sehr praktisch. Bei Parse-Ini-File ist die Datei "human readable" und auch mit einem Editor sicher veränderbar. Dafür ist die Strukturtiefe begrenzt. Da könnte man dann auch gleich für jeden User eine Liste der erlaubten Verzeichnisse und Dateien nebst der Rechte darauf (nur gezielt ansehen, listen und ansehen, ändern, hinzufügen, löschen, Rechte für Andere vergeben/löschen, usw. hinterlegen. Und irgendwann kommt man dann an die Stelle, an der ein DBMS praktischer wird :-) Denk bei dem System auch an die notwendigen Dateisperren für den konkurrierenden Betrieb. Das muss man bei einer Datenbank für die meisten einfachen Fälle nicht selber tun. Zu einem Login- und Berechtigungssystem gehören selbstverständlich auch die Pflegefunktionen: Benutzer verwalten, anlegen, ändern, sperren, löschen, suchen, effektive Rechte des Benutzers anzeigen, usw. Das ist ein Riesenpaket. Hochachtung vor demjenigen, der es fertig bekommt. Liebe Grüße aus dem schönen Oberharz Tom vom Berg  -- ☻\_ /▌ / \ Nur selber lernen macht schlau <http://bikers-lodge.com>-
Hallo Tom,
Es gibt
serialize() / unserializeDas ist mir natürlich bekannt und bei der .txt Datei verwende ich das auch. In diesem speziellen Fall handelt es sich wirklich nur um 4 oder 5 Gruppen, da schenke ich mir das und die PHP Lösung tut es auch.
Da könnte man dann auch gleich für jeden User eine Liste der erlaubten Verzeichnisse und Dateien nebst der Rechte darauf (nur gezielt ansehen, listen und ansehen, ändern, hinzufügen, löschen, Rechte für Andere vergeben/löschen, usw. hinterlegen.
So etwas _ähnliches_ habe ich auch, aber hier ging es ja nur um das Login Verfahren.
Denk bei dem System auch an die notwendigen Dateisperren für den konkurrierenden Betrieb.
Natürlich, das mache ich sowieso _immer_, wenn ich mit den PHP Filefunctions arbeite!
Zu einem Login- und Berechtigungssystem gehören selbstverständlich auch die Pflegefunktionen: Benutzer verwalten, anlegen, ändern, sperren, löschen, suchen, effektive Rechte des Benutzers anzeigen, usw.
So kompliziert muss das in _meinem_ Fall gar nicht sein, es handelt sich _wirklich nicht_ um mehr als die Freigabe verschiedener weniger Dokumente für ein paar Gruppen! :)
Hochachtung vor demjenigen, der es fertig bekommt.
Hast Du Dir meine kleine online Demo angesehen und getestet?
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?-
Hello,
Hochachtung vor demjenigen, der es fertig bekommt.
Hast Du Dir meine kleine online Demo angesehen und getestet?
Klar habe ich geguckt.
Du erzeugst damit natürkich auch "Soft 404" für die Suchmaschinen. Die Diskussion hatten wir neulich erst.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom,
Du erzeugst damit natürkich auch "Soft 404" für die Suchmaschinen. Die Diskussion hatten wir neulich erst.
Diesen Ausdruck kannte ich bis dato nicht. Habe jetzt versucht, mich via GOOGLE schlauer zu machen, so ganz klar ist mir die Sache aber nicht. Es ist ja nicht so, dass an einer Adresse _nichts_ gefunden wird, es wird halt nur (auf Grund fehlendem Logins) zu einer anderen Seite (=Login) weitergeleiet.
Stellt das für Suchmaschinen ein Problem dar?
Wäre es besser, statt der Umleitung an der Originaladresse ein "Sie müssen eingeloggt sein, um diese Seite sehen zu können" zu platzieren und statt der automatischen Umleitung einen Link zum Login zu setzen?
Wenn dem so ist: Du sagen, ich machen! =)
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?-
Hello Melvin,
Stellt das für Suchmaschinen ein Problem dar?
Naja, die haben eben dann unter diversen URis denselben Content. Das mögen die nicht.
Wäre es besser, statt der Umleitung an der Originaladresse ein "Sie müssen eingeloggt sein, um diese Seite sehen zu können" zu platzieren und statt der automatischen Umleitung einen Link zum Login zu setzen?
Ich persönlich finde es überhaupt nicht schlimm.
Aber nach der Diskussion von neulich habe ich mal die User von Seiten beobachtet, die das genauso machen. Die User sind irritiert, wenn der Link "nicht funktioniert" und z.B. zur Startseite oder Logininseite zurückführt. Und die User sind für mich viel wichtiger, als die Suchmaschinen ;-)
Also gibt es demnächst eine nette Fehlerseite, auf der dann aus einer Datenbank "rein zufällig" immer noch ein Spruch des Tages kommt und ein "Sorry. Bitte suche dort...->".
Und was den Suchmaschinen viel wichtiger ist, ein HTTP-Status 404, wenn es den Link nicht gibt und ein 302 (?) (das sendest Du), wenn er nur im Moment nicht zugänglich ist.
Musst mal im Archiv suchen von diesem Jahr nach "Status 404" oder "Soft 404".
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
-
-
-
Hallo,
Die Übertragung von Gruppenname und PIN erfolgt mit SSL. Ist die Überprüfung der Daten erfolgreich, passiert folgendes: Aus einer Kombination aus time() in Mikrosekunden und einer Stringkette entsteht eine 30-stellige unique Zufalls ID.
So etwas ist keine gute Idee, weil sehr einfach von Angreifern erratbar. Es ist keine zufällige, sondern eine völlig deterministische ID! time() ist Angreifern bekannt und eine konstante Stringkette lässt sich per Brute-Force finden.
Warum nutzt du keine PHP-Sessions? Die Session-IDs von PHP nutzen viel mehr Entropie als das hier. Zufällig und damit schwer erratbar sind lediglich Session-IDs aus kryptografischen Pseudo-Zufallsgeneratoren, die mit guter Entropie geseedet sind.
Auf dem Server wird eine Session angelegt. Dabei ist die ID der Variablenname und der Variablenwert entspricht dem Gruppennamen, für die man eingeloggt ist. Zusätzlich gibt es auf dem Server eine .txt Datei mit einem Array, in dem die Indices den Timestamp des Login-Endes und die Werte die IDs wiedergeben. Die neu erstellte ID wird nun samt dem gewünschten Gültigkeits-Endzeitpunkt in dieses Array dazugespeichert.
Warum implementierst du das selbst und nutzt nicht PHP-Sessions? Du setzt hier, soweit ich das verstehe, haargenau das um, was PHP-Sessions dir out-of-the-box liefern: Sessions als Dateien mit der Session-ID im Namen, darin serialisierte PHP-Objekte, ein Garbage Collector beendet die Sessions nach einem konfigurierten Timeout.
Bei jedem Aufruf einer geschützten Seite verwende ich zusätzlich session_regenerate_id().
Also nutzt du PHP-Sessions bereits? Dann scheinst du komplett daran vorbei zu programmieren, denn sie bieten bereits, was du offenbar auf deren Basis implementiert hast.
Im Übrigen ist es nicht sinnvoll, die Session-ID mit jedem Request zu erneuern. Das setzt nämlich voraus, das Requests immer streng nacheinander erfolgen. Werden sie parallel abgesendet, was in zwei Browsertabs durchaus vorkommen kann, kommt es zu einer Race Condition: Mit Request A und B jeweils die Session-ID S1 gesendet. Wird Request A zuerst abgearbeitet, wird S1 für ungültig erklärt, serverseitig gelöscht sowie S2 erzeugt und zum Browser gesendet. Wenn der Server anschließend Request B verarbeitet, dessen Request-Header S1 beinhalten, wird dieser Request als unautorisiert verworfen (Weiterleitung auf die Login-Seite o.ä.).
Die Passwörter der Gruppen sind md5()-gespeichert.
Das alleine verbessert die Sicherheit überhaupt nicht! Dann kannst du sie auch im Klartext speichern. MD5 ist eine längst kompromittierte kryptografische Hashfunktion, nicht mehr zu empfehlen ist. Wenn du sie nutzt, dann nur mit einem zufälligen Salt.
Dir scheint Grundlagenwissen zu fehlen – das soll kein Vorwurf oder Angriff sein, nur eine Bestätigung dessen, dass selbstgebaute Lösungen im Bereich Sicherheit in aller Regel unsicher sind. Ich könnte das auch nicht besser, ich weiß lediglich, wovon ich besser die Finger lasse.
Dieses System kommt ohne einer Datenbank aus und für die Verwaltung der paar Gruppen, mit denen ich hier arbeite, ist das IMHO _mehr_ als sicher.
Ein solches System ist halbwegs sicher, wenn es
- gängige Best Practices implementiert,
- geprüfte Bibliotheken und Module korrekt nutzt,
- die Komplexität und Angriffsfläche klein hält,
- einen unabhängigen Security-Audit überstanden hat.
Grüße
Mathias
-
-
-
Was haltest Du davon, bei einem Loginsystem mit zeitlicher Begrenzung (also zB. automatischer Logout nach 15 Minuten) als eine _zusätzliche_ Sicherheitsstufe bei jedem Seitenaufruf nicht nur den Loginstatus zu überprüfen
Ob das sinnvoll ist, hängt ganz von deiner Site und deren Anwendungsfällen ab.
Bei den meisten Sites, bei denen ich mich einlogge, will ich nicht automatisch nach 15 Minuten rausgeworfen werden, sondern am liebsten ewig eingeloggt bleiben. Jemand müsste entweder die Session stehlen oder sich meines Computers bemächtigen, um das auszunutzen – dagegen gibt es jeweils Sicherungen.
Bei einigen wenigen Sites (Banking z.B.) gibt es einen sichtbaren Timer, der die Session in unter 10 Minuten terminiert. Das ist auch äußerst sinnvoll.
sondern auch, ob die IP des Clients die selbe ist wie zum Zeitpunkt des Logins?
Oder sind da dynamische IPs ein Argument, das _nicht_ zu tun?Wovor willst du dich damit schützen? Das Erschweren von Session Hijacking würde mir einfallen. Natürlich sind wechselnde IP-Adressen ein Argument dagegen. Single-Sign-On-Dienste nutzen die IP-Adresse höchstens als ein Merkmal unter vielen, um Session Hijacking zu erkennen. User-Agent und geografische Position sind weitere Daten, die einfließen.
Generell kann ich drei Regeln empfehlen:
- Als Laie nichts sicherheitskritisches selbst erfinden und implementieren
- Vorhandene, stabile, auf Sicherheit überprüfte Systeme einsetzen
- In seriösen Quellen recherchieren (d.h. nicht das SELFHTML Forum fragen, denn dies ist kein Forum, in dem ausgewiesene Security-Experten Grundlagen dozieren)
Mathias
-
Hello,
Generell kann ich drei Regeln empfehlen:
- Als Laie nichts sicherheitskritisches selbst erfinden und implementieren
Nee, mimm lieber SSL :-P
Ich hoffe, dass die Open-Source-Gemeinde in Zukunft etwas aufmerksamer wird.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
Hello,
Wie sieht ein sicheres Loginsystem aus? Session, Cookies oder MySQL (Oder alles zusammen)?
Alles zusammen & https :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Hello,
Wie sieht ein sicheres Loginsystem aus? Session, Cookies oder MySQL (Oder alles zusammen)?
Alles zusammen & https :-)
Schon mal einen Link aufs Archiv:
http://forum.de.selfhtml.org/archiv/2014/1/t216393/#m1483761noch ohne https.
Dazu passend gibt es auch eine skalierbare Rechteverwaltung.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Om nah hoo pez nyeetz, Tom!
Schon mal einen Link aufs Archiv:
http://forum.de.selfhtml.org/archiv/2014/1/t216393/#m1483761Ein Link auf ihre/seine eigene Frage …
Matthias
-
Hello Matthias,
Schon mal einen Link aufs Archiv:
http://forum.de.selfhtml.org/archiv/2014/1/t216393/#m1483761Ein Link auf ihre/seine eigene Frage …
*rotfl*
Das war wohl schon zu lange her.
Dürfen wir den anderen Usern hier eigentlich auch eigene Spitznamen geben, oder wäre das gemein?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
Hallo,
Wie sieht ein sicheres Loginsystem aus? Session, Cookies oder MySQL (Oder alles zusammen)?
Entschuldige, aber diese allgemeine Frage zeigt, dass du dich anscheinend noch nicht mit den Hinweisen auseinandergesetzt hast, die wir dir in deinem vorherigen Thread gegeben haben.
Noch einmal die Links, die dir gegeben wurden:
http://wiki.selfhtml.org/wiki/Technische_Ergänzungen/Loginsystem
http://www.php.net/manual/de/book.session.php
http://wiki.selfhtml.org/wiki/Benutzer:Suit/Loginsystem_und_Benutzerregistrierung_mit_PHP_und_MySQLBitte arbeite die durch und Frage dann konkret nach, wenn dir etwas unklar ist oder wenn du nicht weiterkommst. Dann können wir dir gerne genauere Hinweise geben.
Sessions? Ja, PHP-Sessions.
Cookies? Ja, vorzugsweise.
MySQL? Kannst du verwenden, um Nutzer und deren gehashte Passwörter zu speichern. Musst du nicht verwenden, wenn du keine komplexe Nutzerverwaltung hast.Mathias
-
Wie sieht ein sicheres Loginsystem aus? Session, Cookies oder MySQL (Oder alles zusammen)?
Es muss so beschaffen sein, dass die Auslieferung autorisierter Inhalte (Dokumente, Anwendungen) nicht umgangen werden kann. Dazu muss es möglich seine, die Autorisierung überhaupt prüfen zu können, welche eine Policy regelt, gewöhnlich über die Benutzergruppe oder den Benutzer.
Idealerweise machen an Inhalte gebundene URLs keine Aussage darüber, dass überhaupt eine Policy greift, beispielsweise wird über /index.html für Benutzergruppe public ein völlig anderer Inhalt ausgegeben als für Benutzergruppe private.
Manipulationen am URL, Parameter, Pfad betreffend, dürfen keine Umgehung der Policy ermöglichen.
Manipulierbar ist jedoch IMMER die Session-ID, ein Angreifer kann diese ID ändern, egal ob die im Request-Header (Cookie) oder im URI (Parameter) übertragen wird.
Baue die Funktion, die für eine weltweit eindeutige Session-ID sorgt, nicht selbst. Use SSL.
-
Inhalte und Anwendungen unterliegen einer Zugangskontrolle, sie sind entweder für alle Besucher/Benutzer zugänglich oder einer bestimmten Benutzergruppe zugeordnet. Idealerweise ist die Zugangskontrolle vom Code vollständig getrennt, was ein Höchstmaß an Sicherheit bietet. Gleichermaßen vereinfacht das den Code, der Entwickler kann sich auf das Wesentliche konzentrieren.
Die Trennung der Zugangskontrolle vom Code wird dadurch erreicht, dass die Policy über der Konfiguration angesiedelt ist, so ist auch die Policy vom Code getrennt. Eine Policy regelt das Aushandeln von Inhalten, auch bekannt unter dem Begriff Content Negotiation.
-
