Session absichern

[SebiPuck]

Hallo,
ich stehe derzeit bei meinem Projekt auf der Leitung...
Da der Login - Bereich nun fertig ist (User und Passwort),
frage ich mich nun, wie ich eine recht sichere Session hinbekommen kann. Ich hatte die Idee die Session folgender Maßen aufzubauen:

$_SESSION['user'] = $username
$_SESSION['pass'] = $password

Bei jedem Login sollte dann überprüft werden, ob die Daten in der Session mit der Datenbank übereinstimmen.
Der User wird hier in Klartext abgespeichert und das Passwort ist per md5 verschlüsselt.

Nun denke ich, dass ich so eine Überprüfung theoretisch an jeder geschützten Seite machen müsste, oder ?

Heute habe ich von "session_regenerate_id" gehört. Ich habe schon einiges dazu gelesen, ich blicke hier jedoch nicht so wirklich durch.

Meine Befürchtung ist: Jemand manipuliert eine Session (oder ein Cookie) und kann sich somit Zutritt in anderen Accounts verschaffen.
Ist das mit Sessions überhaupt möglich ?
Wie sollte ich Cookies am besten absichern ?

Vielen Dank im Voraus,
LG

 

[ComFreek]

Hallo,

MD5 ist keine Verschlüsselung. Und MD5 zum Passwordhashen ist ein absolutes No-Go! => bcrypt (inkl. Salts)!!
Bitte lies und verstehe alles in folgendem Link: http://security.stackexchange.com/q/211/27234

Session-Daten werden auf dem Server gespeichert. Im Cookie (das der Nutzer/Browser einsehen kann) steht nur eine ID, mittels derer der Server die Daten zuordnen kann.
Es kann also keiner Session-Daten manipulieren.

In Bezug auf session_regenerate_id(): Somit kannst du dich gegen Session Hijacking absichern.
Wozu willst du das PW in der Session speichern?

 

[SebiPuck]

Hallo,

MD5 ist keine Verschlüsselung. Und MD5 zum Passwordhashen ist ein absolutes No-Go! => bcrypt (inkl. Salts)!!
Bitte lies und verstehe alles in folgendem Link: http://security.stackexchange.com/q/211/27234

Session-Daten werden auf dem Server gespeichert. Im Cookie (das der Nutzer/Browser einsehen kann) steht nur eine ID, mittels derer der Server die Daten zuordnen kann.
Es kann also keiner Session-Daten manipulieren.

In Bezug auf session_regenerate_id(): Somit kannst du dich gegen Session Hijacking absichern.
Wozu willst du das PW in der Session speichern?

Ich habe mich falsch ausgedrückt, Entschuldigung.
Das mit dem Password meine ich wie folgt:
Wenn ich ein Cookie habe und darin $username steht, kann ja jeder daher kommen und sein Cookie manipulieren, sodass er automatisch mit einem anderen Account eingeloggt ist.
Trifft diese Theorie zu ?
Wie könnte ich mich vor solch einer Gefahr schützen ?
Danke im Voraus,
LG

 

[ComFreek]

Trifft diese Theorie zu ?

Nein, wie gesagt, die Session wird auf dem Server gespeichert. Wie sollte jemand seinen Nutzername, der in der Session gespeichert ist, ändern?

 

[SebiPuck]

Nein, wie gesagt, die Session wird auf dem Server gespeichert. Wie sollte jemand seinen Nutzername, der in der Session gespeichert ist, ändern?

Nein, ich beziehe mich hier auf Cookies
Wie siehts da aus ?
LG

 

[ComFreek]

Kannst du bitte dein genaues Angriffsszenario beschreiben?

Natürlich besteht die Chance, dass ich durch Ausprobieren von Session-IDs jene eines eingeloggten Admins bekomme. Die Chance ist verschwindend gering. Du kannst Session-IDs natürlich auch stehlen.
Siehe auch: http://security.stackexchange.com/questions/35977/session-cookie-stealing-protection

 

[SebiPuck]

Kannst du bitte dein genaues Angriffsszenario beschreiben?

Natürlich besteht die Chance, dass ich durch Ausprobieren von Session-IDs jene eines eingeloggten Admins bekomme. Die Chance ist verschwindend gering. Du kannst Session-IDs natürlich auch stehlen.
Siehe auch: http://security.stackexchange.com/questions/35977/session-cookie-stealing-protection

Ich verstehe nun was gemeint ist danke.
jedoch verstehe ich nun etwas was du erwähnt hast ganz und garnicht.
Wenn ich ein Password mit salts usw. verschlüssle, wird das ja sozusagen random generiert.
Wie kann ich dann einen login ermöglichen, wenn "test" nicht immer xy ist ?

Das ganze password muss ja in der mysql db gespeichert werden und bei einem Login soll ja dann geprüft werden, ob das eingegebene Passwort mit dem in der Datenbank valide ist...
Danke im Voraus,
LG

 

[ComFreek]

MD5 ist einfach eine Hash-Methode, die zum Passworthashen völlig ungeeignet ist. Unter anderem ist MD5 viel zu schnell zum Berechnen! Ich kann locker Millionen Hashes pro Sekunde berechnen.
Da helfen dir Salts auch nicht mehr viel weiter. Zwar müsste ich dann eine neue Rainbow-Tabelle erstellen, aber da die Berechnung von MD5 selbst so schnell vonstattengeht, ist das kein großes Hindernis.

Du verschlüsselst ein Passwort nichts! Du hashst es! Sozusagen ist dies eine Einwegverschlüsselung, wenn du magst.

Wie kann ich dann einen login ermöglichen, wenn "test" nicht immer xy ist ?

Diese Frage verstehe ich leider nicht.
Den Salt speicherst du selbstverständlich auch in der DB - natürlich unverschüsselt.

 

[SebiPuck]

MD5 ist einfach eine Hash-Methode, die zum Passworthashen völlig ungeeignet ist. Unter anderem ist MD5 viel zu schnell zum Berechnen! Ich kann locker Millionen Hashes pro Sekunde berechnen.
Da helfen dir Salts auch nicht mehr viel weiter. Zwar müsste ich dann eine neue Rainbow-Tabelle erstellen, aber da die Berechnung von MD5 selbst so schnell vonstattengeht, ist das kein großes Hindernis.

Du verschlüsselst ein Passwort nichts! Du hashst es! Sozusagen ist dies eine Einwegverschlüsselung, wenn du magst.

Diese Frage verstehe ich leider nicht.
Den Salt speicherst du selbstverständlich auch in der DB - natürlich unverschüsselt.

bei md 5 ist es immer so, dass "test" 098f6bcd4621d373cade4e832627b4f6 ist.
Wenn ich es mit einem hash versuche (und mit salt usw.) kann ich nicht mehr diesen vergleich machen, da test immer ein anderer hash ist.
wie kann ich dieses Problem lösen ?

 

[ComFreek]

Jede Hashfunktion spuckt für die gleichen Eingabeparameter denselben Hash aus.

Eingabeparameter schließen u. a. Iterationszahl, Salt und Passwort mit ein.

Du musst natürlich den gleichen Salt benutzen. Zeig mal, wie du es versucht hast.