✔ Loginsession Sicherheit

[aargau]

Ich habe eine kleine Frage, aufwelche ich momentan keine wirkliche Lösung finde.
Ich habe seit langem ein Loginsystem. Dies Funktioniert soweit sehr gut und durch die Hilfe hier im Forum sollte das ganze auch relativ sicher sein. Nun habe ich aber dennoch einen "Problem" welches ich lösen möchte aber dennoch kein Sicherheitsrisko eingenen möchte.

Das Loginsystem ist darauf ausgelegt das es ein user automatisch wieder einloggt wenn er wieder auf die Page kommt. Damit dies momentan Funktioniert wird beim Login in die db-tabelle "sessions" ein Eintrag erstellt.Zugleich ein cookie angelgt mit einem hash aus Zeit, IP und Browser (nur um sicher nicht doppelt den gleichen zu kriegen). Dieser hash wird natürlich auch in die DB gespeichert.
Soweit sogut.
Kommt der User nun auf die Seite und bringt das cookie mit wird die DB nach dem cookie-hash druchsucht und falls die Session noch "existiert" wird eine neue session gestartet.

Somit bekommt der user bei jedem neustarten des Browsers eine neue Session. Für mich ist nun einfach unklar ob die alte Session (welche ja nicht zwingend mit session_destroy() beendet wurde immer noch auf dem Server liegt und theoretisch wenn ein anderer user die Session mithört und genau den gleichen Browser etc. hat noch verwendbar ist oder ob diese nach kurzerzeit gelöscht wird?

Nun Frage ich mich ob es ev. sogar sinnvoll wäre das phpsession cookie auf X Tage laufzeit zu setzen, damit ich nur noch ein cookie habe genau so nur noch eine session auf dem Server oderdoch besser via DB zu prüfen.

Zusätzlich suche ich nach der möglichkeit das kein user doppelt eingeloggt sein kann. Dies geht momentan nur beschränkt, meldet sich User X auf einem PC an so könnte sich User X auch auf PC2 anmelden und wäre bei beiden PCs online. Schliesst er allerdings den Browser ist er ausgeloggt.
Dies ist so weil nur beim "starten" bzw. "widerherstellen" einer session geprüft wird ob sich der cooklie hash in der db geändert hat. Ist so eine Prüfung ohne eine weiter mysql query überhaupt irgend wie möglich?

Edit:
Ev. habe ich noch eine Lösung. Den cookie-hash in die benutzer-db zu Speichern und bei jedem mal zu checken ob er geändert wurde. Dies würd keine zusätzliche Query brauchen da eh bei jedem aufruf infos aus der benutzerzeile augegeben werden (wurde ein user gesperrt, hat er neue nachrichten, hat er freundesanfragen etc)

Nur die Frage mit der Session-Speicherzeit auf dem Server bleibt übrig...
Wird die Session so oder so no X Tage oder Stunden gespeichert denke ich würde es auch gehen die Session für "immer" via cookie beim Nutzer zu Speichern um den User nicht mit mehreren cookies zu nerven.

 

[djbergo]

Speicher doch einfach die Provider IP im Cookie und in der Session dann haste:

A. nicht das Problem, dass jemand die Session weiterverwenden kann.
B. kannst du dann abfragen, ob die Provider IP bereits eingeloggt ist und ein weiteres Login verbieten
C. Kannst du damit auch ungebetene Benutzer fernhalten, indem du bei der Abfrage Prüfst, ob die Provider IP auf der Blacklist steht.

 

[aargau]

Die Idee mit der IP hatte ich auch schon, jedoch gibt es da auch einige Probleme:

- Mehrere PCs im selben Haushalt -> Mehrere User = Probleme
- Dynamische IPs bei DSL z.B. die Zwangstrennung
- Mobile Internetverbindungen arbeiten meist über Proxys und somit mind pro Zelle die selbe IP, heisst wenn man Mobile ist wechselt die IP womöglich im Minutentakt.

Daher denke ich das dies keine guete Idee ist ein user an eine IP zu binden und anhand von dem zu Kontrollieren. Bezüglich der Sicherheit wäre es natürlich nahezu die grösste die es gibt.

Momentan bin ich dabei das ganze einfach mit den übermittelten Daten (Browser / OS / Akzeptierte Sprache etc.) zu sichern und trage wie oben geschrieben einfach ein hash in die DB beim Login welcher dann bei jedem aufruf gebrüft wird. Loggt sich also wärend dem der User aktiv ist ein anderer mit dem selben Account ein wird die Session vom anderen Automatisch zerstört.

 

[Sven Mintel]

Moin,

wenn du etwas in dem Cookie speichern musst, dann sind es Userid+Passwort(zumindest Passwort natürlich gehasht...wie du das ganze "verschlüsselst", ist deiner Kreativität überlassen)...damit kannst du das automatische Login vornehmen, mit sonst nichts.

Bei jedem Login-Vorgang(ob nun per Cookie oder per Formular) speicherst du die Session-ID ebenfalls in der DB.

Bei jedem Vorgang vergleichst du jetzt, ob die Session-ID mit der in der DB hinterlegten übereinstimmt.
Falls nicht, wird die aktuelle Session destroy()'ed, der Login-Cookie geprüft(falls keiner Vorhanden, Loginformular etc.).

Bei erfolgreichem Login per Formular wird nun der Login-Cookie geschrieben und die neue Session-ID in die DB geschrieben.
Bei erfolgreichem Login per Cookie wird nur die neue Session-ID in die DB geschrieben.

Auf diesem Weg hast du niemals mehr als einen eingeloggten Client pro Account, und immer einen verifizierten.

Alle anderen Daten wie IP,Browser, Sprache sind absolut nebensächlich.

 

[aargau]

hmm wiso username+passwort?
es reicht doch eigentlich wenn ich die session lebensdauer auf 1Jahr setze und dann die session_id() in die benutzer Tabelle zu Speichern und bei jedem aufruf zu testen ob diese noch aktuell ist. Heisst wenn sich benutzer x nun an PC2 einloggt ändert sich die session_id() in der db und der andere user würde falls er aktiv wird rausfliegen.

Somit muss ich nicht unnötig viele Cookies setzen, für jeden User gibt es genau eine session Datei auf dem Server.

Zusätzlich kontrolliere ich aber Browser und OS dennoch, denn sollte es jetzt jemandem gelingen das cookie zu klauen könnte dieser sich solange wie sich der andere user nicht neu einloggt herumtreiben und machen was er möchte. Die Browser und OS geschichte ist natürlich nicht die sicherste, denn das diese übereinstimmen könnte wohl relativ schnell der Fall sein, aber es gibt dennoch einen schutz und da die session sonst ja zerstört wird sehe ich darin eigentlich ein sehr sehr sehr kleines Risiko. Da würde wohl nur noch die IP zusätzlich helfen. Sowas könnte man bei den Adminfunktionen vieleicht aus sicherheit noch einbauen aber auch da (z.B. bei mir) wäre es eher lässtig da ich sehr oft Mobile im WWW bin und ich dann ev. beim löschen eines Bild ausgeloggt werden würde weil die IP nicht mehr stimmt.

Sollte es irgend eine grosse Sicherheitproblematik durch meine "version" des Logins geben, so bitte ich es hier zu schreiben!

 

[Sven Mintel]

hmm wiso username+passwort?

Wie sonst willst du einen Benutzer authentifizieren?

Über eine Session-ID?

Ist übrigens eine feine Idee, die Session-Lebensdauer auf 1 Jahr festzulegen(interessiert den Browser übrigens oftmals garnicht, weil diese in der Grundeinstellung idR. Sessions von sich aus beim Schliessen beenden )
Dir ist schon klar, dass für jede Session eine Datei auf dem Server erstellt wird....wenn diese 1 Jahr aufbewahrt werden sollen, hoffe ich nur, dass du nicht allzuviele User hast oder/und nicht allzuviele Daten in der Session speichern musst

Dazu ist übrigens eine Session da: um Daten für die Dauer einer Sitzung zu Speichern....und nicht um jemandem für 1 Jahr ungeprüft allumfassende Rechte einzuräumen.

Du kannst ja gerne mal (sofern du hier automatisches Login nutzt) deinen Session-Cookie(bbsessionhash) löschen....deine Sitzungsdaten sind weg, eingeloggt bist du aber immer noch...weil UserID+PW ebenfalls in Cookies gespeichert sind. Glaubst du, die machen Murks bei vbulletin?

 

[aargau]

der Benutzer wird ja beim Login in die session gespeichert, bzw. seine ID. Bis vor kurzem war es nun so das einfach ein cookie gesetzt wurde mit einem mix aus zeit, ip usw natürlich in md5 und dann in die db-table "sessions" eingetragen wurde mit der user id des benutzers. Nun würde wenn keine session offen war getestet ob ein cookie gesetzt wurden und falls ja in der DB nachgeschaut ob es diesen code gibt und wenn ja eine neue session gestartet mit der userid.

Die Sessions werden ja beim Logout zerstört, somit sind diese danach auch nicht mehr auf dem Server.
Ich weis von einer grossen Plattform (5000+ Online Member) das die das ganze auch mit nur einem cookie und der Lebensdauer von einem Jahr gelöst haben. Gegen Foren mit >30 Leute ist diese Seite rasend schnell, benutz werden "nur" drei Server + X Fileserver wo Bilder und Videos gespeichert sind.
Andernfalls würde ich das ganze wie früher mit dem zusätzlichen cookie machen.

 

[Sven Mintel]

Dann mache es halt so wie du willst...ich weiss dann aber nicht, wozu du fragst, wenn du keine Antwort hören willst.

Meine Antwort jedenfalls: das ist Murks

 

[aargau]

Ich sage ja nicht das es die beste lösung ist, aber das es bestimmt auch geht ^^
Ich kenn den Code dieser Seite ja nicht, vieleicht hat er auch ein eines Session Management geschrieben oder was weis ich. Ich weis nur 1Cookie, 1Jahr, 5000+ User, 3Hauptserver für mysql + php und wenige fileserver.

Was haltest du denn von der vorherigen Version? Wie geschrieben cookie + DB eintrag -> jeweils neue Session
Sessions wie immer auf Standard Lebensdauer von "0" setzen.

Heisst grundsätzlich einfach: Eine DB Abfrage beim Login oder "wiederlogin" mehr, zwei cookies.

Ansonsten wenn ich komplett deine Version nutze (username+pw) wie würde ich das im cookie dann verschlüsseln damit ich es wieder entschlüsseln kann?

 

[Sven Mintel]

Ansonsten wenn ich komplett deine Version nutze (username+pw) wie würde ich das im cookie dann verschlüsseln damit ich es wieder entschlüsseln kann?

Du musst es nicht entschlüsseln, man darf es garnicht entschlüsseln können(niemand, nicht mal der, der in die DB gucken kann)

1.Cookie: Userid, Username oder dergleichen....daran kann man sehen, welcher Datensatz in der DB gemeint ist->der bleibt "unverschlüsselt"
2.Cookie: da kommt das gehashte Passwort(MD5 oder dergleichen rein)

In der DB steht auch dieses gehashte Passwort...damit wird einfach verglichen.

Vorteil der Sache: klaut jemand den Cookie, kann er sich zwar darüber automatisch einloggen, er kann aber nicht das Passwort herausbekommen, weil man Hashes nicht entschlüsseln kann. Wenn du nun bspw. bei allen Änderungen am Account vorher nochmal das Passwort abfragst, kennt der "Dieb" dieses nicht..er kann also über den Cookie nicht den Account stehlen.

Sicherer ist bei diesem Hash noch die Verwendung eines Salt's ...das ist eine (zufällige)Zeichenkette, welche du ebenfalls in der DB speicherst.

Also Vorgehen:
Erstellung des Accounts....

• Du speicherst in der Salt-Spalte eine zufällige Zeichenkette, sagen wir mal hjskk5(ist egal welche)
• Das Passwort des Users ist mal angenommen passwort
• In der Passwort-Spalte speicherst du einen MD5-Hash aus dem Salt und dem Passwort

MD5('passworthjskk5')

...ergibt 3c0f7ea68112c825476dd67980f3bd9f (das kann man nicht entschlüsseln, weil es keine Verschlüsselung ist)

• Diesen Hash speicherst du auch so im Cookie
• Fürs automatische Login benötigst du nun ein Query nach diesem Schema:

SELECT * FROM usertabelle WHERE useridspalte=wertaususeridcookie AND hashspalte=wertaushashcookie

• Fürs Login per Formular sähe das Query dann so aus:

SELECT * FROM usertabelle WHERE usernamespalte=wertausbenutzernamenformularfeld AND hashspalte=MD5(CONCAT(wertauspasswortformularfeld,saltspalte))

Dies so der sinngemässe Ablauf, es gibt da noch weitere Möglichkeiten, das noch sicherer zu gestalten, z.B. in der DB den Hash mit 2x MD5() erstellen, im Cookie aber nur mit 1x MD5() speichern....so wäre es nicht möglich, sich durch einen Blick in die DB über den Hash einen Cookie selbst zu Basteln.