Idee für Login System

[dibsi]

Hallo !
Ich hab da eine Idee für ein Loginsystem und würde gerne eure Meinung hören:
Ich mach nach einem erfolgreichen Login einen Hash aus Browser und Session ID. Den schreib ich in die DB und bei jedem Aufruf der Seite wird ein neuer Has generiert, der ja mit dem alten übereinstimmen sollte. Wenn nicht, fliegt der User raus.
Na, was sagt ihr ?

[closure]

Hi,
oder du überlässt das hashgenerieren einfach php. Php muss es
ohnehin machen wenn eine session beginnt bzw. fortgeführt wird.
Und dann sparst du dir das ganze generieren und prüfst nur ob ein wert in der session
gesetz ist. Dieser wert kann ne id oder ein bool flag oder ein userobjekt
oder was auch immer sein.

[dibsi]

Original geschrieben von closure
Hi,
oder du überlässt das hashgenerieren einfach php. Php muss es
ohnehin machen wenn eine session beginnt bzw. fortgeführt wird.
Und dann sparst du dir das ganze generieren und prüfst nur ob ein wert in der session
gesetz ist. Dieser wert kann ne id oder ein bool flag oder ein userobjekt
oder was auch immer sein.

Das nützt aber nichts bei zB Session Hijacking. Ursprünglich wollte ich noch die IP zum Hashwert geben, aber dann gibts Probleme mit Proxies. Habt ihr eigentlich irgendwelche Vorschläge, welche Daten ich zum Hashwert dazugeben könnte (sollte möglichst eindeutig sein).

[Guido]

Original geschrieben von dibsi
Habt ihr eigentlich irgendwelche Vorschläge, welche Daten ich zum Hashwert dazugeben könnte (sollte möglichst eindeutig sein).

... zum Beispiel eine in der Session gespeicherte Startzeit der Sitzung

[Slava]

ich glaube, dass wenn jemand Begrif "Session Hijacking" verwendet, der muss auch ein wenig Prinzip von Session Hijacking kennen.

Nur wenn jemand in Netzwerk eingedrungen ist und direckte Komunikation zwischen dem Server und User verfolgen kann, hat die Möglichkeit Session Hijacking ausüben.

Deine Methode ist genau so von einem Angrif wie auch normale session-führung geschutzt.

also würde ich einfach SSH sagen.

[closure]

Original geschrieben von dibsi
Das nützt aber nichts bei zB Session Hijacking.

Wenn es sicherheitskritische anwendungen sind ist ohnehin
SSL angebracht. Dann hat sich dein session-hijacking problem auch
erledigt. Dabei gibt es unter umständen wieder probleme mit
einem ähnlich gelagerten fall nämlich man-in-the-middle angriffe
um eben die ssl-sitzung zu hijacken.

Du weisst ja sicher das es perfekte sicherheit nicht gibt.
Die frage ist wie wichtig sind solche überlegungen für deine konkrete
aufgabe ?

greets

[Slava]

hi @closure
für Session Hijacking wird eigentlich auch nur man-in-the-middle verwendet.
aber SSL ist schon ein richtige Einsatz.

[ghostgambler]

Original geschrieben von Slava
ich glaube, dass wenn jemand Begrif "Session Hijacking" verwendet, der muss auch ein wenig Prinzip von Session Hijacking kennen.

Nur wenn jemand in Netzwerk eingedrungen ist und direckte Komunikation zwischen dem Server und User verfolgen kann, hat die Möglichkeit Session Hijacking ausüben.

Nein, als session hijacking wird auch das vorige Erstellen einer Session vom Hacker mit dem folgenden Einloggen des Users über einen präparierten Link in eben diese Session und dem Weiterverwenden der Session vom Hacker bezeichnet. Und dafür braucht man keinen Zugriff aufs Netzwerk...
Aus eben diesem Grunde, gibt es eine Regel, die man besonders beachten sollte beim Umgang mit Sessions. Beim Einloggen den Hash ändern. Dann kann der Hacker die Session nicht mehr nutzen, weil er den Hash nicht kennt.
Als kleinen Bonus kann man noch implementieren, dass die Session erst gestartet wird, wenn sie auch wirklich benötigt wird; das hält den Hacker davon ab, überhaupt eine valide SID zu erlangen.

[Slava]

hi @ghostgambler
erst mal danke für die Information.
welche Möglichkeiten gibt es überhaupt einem user präparierten Link zu schieben?
also bei E-Mail kann ich mir noch das vorstellen, aber wie kann man das noch machen ohne Man-In-The-Middle zu sein?

[3DMax]

Original geschrieben von ghostgambler
Nein, als session hijacking wird auch das vorige Erstellen einer Session vom Hacker mit dem folgenden Einloggen des Users über einen präparierten Link in eben diese Session und dem Weiterverwenden der Session vom Hacker bezeichnet.

nö, das nennt sich wiederum "Session Fixation".
aber die idee, beim login eine neue session-id zu generieren ist gut.

was ich in diesem thread vermisse, ist das schlagwort: "cookies".
generell ist es sicherer die sid nur per cookie übertragen.
wenn die sid per GET kommt, würde ich restriktiver überprüfen - z.b. ip- / browser-check ... etc, ansonsten nicht (oder nur sids per cookies zulassen)

Original geschrieben von closure
Wenn es sicherheitskritische anwendungen sind ist ohnehin
SSL angebracht. Dann hat sich dein session-hijacking problem auch
erledigt.

also wenn die sid per GET kommt, denke ich, hilft ssl auch nicht so viel - stichwort: referer - ich denke mal, der wird auch bei ssl übetragen (kann mich aber auch täuschen), aber auf alle fälle schützt es nicht, wenn ein depp einen link mit seiner sid postet.

[ghostgambler]

Original geschrieben von 3DMax
nö, das nennt sich wiederum "Session Fixation".

Hm ... ist sprachlich irgendwie etwas dahingemurkst wie ich finde, ist aber korrekt *kopf kratz* nyo

Hier gibt es ein hübsches PDF zum Thema Session Fixation Attacks
http://www.acrossecurity.com/papers.htm

[closure]

Original geschrieben von Slava
hi @closure
für Session Hijacking wird eigentlich auch nur man-in-the-middle verwendet.
aber SSL ist schon ein richtige Einsatz.

Deswegen sprache ich von "ähnlich gelagertem problem". Im detail unterscheiden
sich diese beiden methoden jedoch. Beim http-session hijacking bzw. bei
dessen vorbereitung handelt es sich um einen passiven angriff. Der angreifer
braucht, wie du bereits sagtest, nur zugriff auf das netzwerk und kann
dann passiv die packete mitlesen und so die session-informationen auslesen
und später im eigentlichen angriff verwenden.

Wenn es um ssl-sessions geht ist der angriff aktiv. Der angreifer ist man-in-the-middle und muss bereits beim challenge-response-handshake
aktiv eingreifen in dem er die sitzungsschlüssel abfängt und dem server und
dem opfer jeweils seinen sendet.

@3DMax
Wenn jemand zugang zu den packeten zwischen den server und client
hat hilft auch ein cookie nichts. Man kann die header der anfragen dann
auch sehen. Und dann kann man einfach die eigenen anfragen mit der
im cookie enthaltenen SID spoofen.
Wenn die sache per GET passiert, da hast du natürlich recht, hilft das
alles nix.

greets

[frido37]

Die methode session_regenerate_id(); vergibt eine neue session_id, so dass du mit jedem Request enweder eine neue session-id hast oder feststellen kannst, dass ein session-hijacking angriff erfolgt ist (alte session-id ungültig);

session_regenerate_id();
if (!%_SESSION['valid_chk']) {
die("angriff festgestellt");
} 

Nicht vergessen, beim login $_SESSION['chk'] auf true zu setzten! (man kann natürlich auch anders feststellen, ob die session ok ist.)

falls du auch zwischen zwei requests ein session-hijacking verhindern willst, kannst du das mit ajax-requests oder einem hidden-iframe lösen. Dabei wird die aktuelle session-id gecheckt, ohne sie zu erneuern, z.B. mit einer session_check.php:

<php?
session_start();
if ($_SESSION['valid_chk']) echo "ok";
else echo "failed";
?> 

[wahsaga]

Original geschrieben von frido37
Die methode session_regenerate_id(); vergibt eine neue session_id, so dass du mit jedem Request enweder eine neue session-id hast oder feststellen kannst, dass ein session-hijacking angriff erfolgt ist (alte session-id ungültig);

Ungültig (geworden) durch was?

Das könntest du höchstens durch den optionalen Parameter bewirken - den du in deinem Beispiel aber nicht nutzt, und der erst ab 5.1.0 verfügbar ist.