[PHP]sessiebeheer/IP-adressen

[Tjolk]

Ik ben bezig met een inlogsysteem bouwen (voor mij de eerste keer dat ik daarmee bezig ben). Op zich heb ik nu een goed werkend systeem: men kan inloggen, aanvinken dat de login onthouden moet worden, etc. Nadeel is alleen: als je inlogt vanaf computer A en vervolgens vanaf computer B (met een ander IP), je op computer A niet meer bent ingelogd. Het moet mogelijk zijn om dan ook nog op computer A ingelogd te zijn, en dat wil ik dus ook mogelijk maken.

Wat ik nu doe met mijn sessies is het volgende (korte samenvatting van 60 regels PHP):

1. Als $_SESSION['suser'] geset is, en de sessietijd is niet verstreken, de sessie verversen
2. Is dat niet het geval: pak de cookie erbij en vergelijk de userid en (gehashde) wachtwoord in de cookie met de gegevens in de database. Kijk daarbij ook of het IP van de inloggende gebruiker matcht met het laatst opgeslagen IP in de database.
3. Is dat niet het geval: session_destroy.

Wat ik nu zit te denken is i.p.v. alleen het laatste IP te slaan in de database, elk IP waarmee de gebruiker succesvol inlogt op te slaan en bij de sessiehandling te kijken of de IP van de inloggende gebruiker matcht met een van de IP's uit de database. Ik vraag me alleen af of dat wel voldoende veilig is.

Wat denken jullie? (en ook: denk ik misschien te ingewikkeld en is er een veel gemakkelijker/beter alternatief?)

[daaan]

Misschien zie ik iets totaal over het hoofd, maar wat is de reden dat je de sessie aan een IP koppelt als je wilt dat je wel overal ingelogd kan blijven?

[Vulpecula]

Ik maak altijd een tabel aan waar alle inlog pogingen worden opgeslagen. Zo kan zie of er iemand bijvoorbeeld met een brute-force aanval bezig is. Je kunt dan ook ervoor zorgen dat er maar maximaal drie keer een foutief wachtwoord mag worden ingevuld.

[PeterSelie]

daaan schreef op vrijdag 15 mei 2009 @ 08:54:
Misschien zie ik iets totaal over het hoofd, maar wat is de reden dat je de sessie aan een IP koppelt als je wilt dat je wel overal ingelogd kan blijven?

Op die manier is het vrijwel onmogelijk een sessie te 'stelen' aangezien sessies aan IPs gekoppeld worden, niet meer dan een stukje beveiliging dus aangezien sessies van een login alleen op het IP gebruikt kunnen worden waar ingelogt is.
Daar doet het systeem dat je ook op meerdere IPs tegelijk kan inloggen dus niets aan af, het behoud zijn functionaliteit

[ Voor 20% gewijzigd door PeterSelie op 15-05-2009 08:59 ]

[Tjolk]

daaan schreef op vrijdag 15 mei 2009 @ 08:54:
Misschien zie ik iets totaal over het hoofd, maar wat is de reden dat je de sessie aan een IP koppelt als je wilt dat je wel overal ingelogd kan blijven?

Ik wil session hijacking voorkomen, maar wil wel mogelijk maken dat mensen vanaf meerdere computers (meest waarschijnlijk de computer thuis en die op het werk) ingelogd kan blijven. Het systeem waarvoor het is, is namelijk juist ontworpen voor mensen die vanaf meerdere locaties werken.

[ZpAz]

Waarom dan geen cookie gebruiken op de locatie waar ze ingelogt moeten blijven?

[PeterSelie]

Dan nog zit hij met het probleem hoe hij dat in de database af gaat handelen omdat je controle natuurlijk niet alleen aan de kant van de client wilt houden, want ook cookies zijn te jatten.

Overigens geeft de OP zelf de oplossing al, lijkt me een prima manier

[ Voor 16% gewijzigd door PeterSelie op 15-05-2009 10:34 ]

[Fuzzillogic]

Sessie koppelen aan IP-nummer is niet verstandig. Mensen met trunked lines surfen vaak met twee of meer IP-nummers tegelijk. Voor die maak je het dus onmogelijk om in te loggen.

[doeternietoe]

SoaDmaggot schreef op vrijdag 15 mei 2009 @ 08:58:
[...]

Op die manier is het vrijwel onmogelijk een sessie te 'stelen' aangezien sessies aan IPs gekoppeld worden, niet meer dan een stukje beveiliging dus aangezien sessies van een login alleen op het IP gebruikt kunnen worden waar ingelogt is.

En IP-spoofing dan? En afgezien daarvan, hoe controlleer je welk IP iemand heeft, wat als de persoon achter een proxy oid zit en er is nog een heel bosje mensen met hetzelfde IP, of door de proxy is het IP iedere request anders?

Veel mensen lossen dat op door de http-header X-Forwarded-For te gebruiken, maar die kan gemakkelijk vervalst worden.

Natuurlijk kan deze manier wel _wat_ extra veiligheid geven, maar denk wel goed na over iedere keuze die je maakt en waan je vooral niet in een schijnveiligheid.

Om de vraag van de TS te beantwoorden, wat dacht je hier van:

SFB schreef op vrijdag 15 mei 2009 @ 08:45:
Wat ik nu doe met mijn sessies is het volgende (korte samenvatting van 60 regels PHP):

1. Als $_SESSION['suser'] geset is, en de sessietijd is niet verstreken, de sessie verversen
2. Is dat niet het geval: pak de cookie erbij en vergelijk de userid en (gehashde) wachtwoord in de cookie met de gegevens in de database. Kijk daarbij ook of het IP van de inloggende gebruiker matcht met het laatst opgeslagen IP in de database. Kijk of de persoon, kort geleden, op dit ip ingelogd is geweest
3. Is dat niet het geval: session_destroy.
4. Bouw logica in dat zodra een gebruiker op "uitloggen" klikt, dit in de database wordt vastgelegd.
5. Geef de gegevens in de database een timestamp mee en controlleer daarmee of de sessie nog geldig is.

Houdt er wel rekening mee dat je met het vastleggen van die sessies in de database voor een zeer klein stukje veiligheid behoorlijk moeilijk doet. Overweeg om dat enkel als log te gebruiken cq helemaal weg te laten. Het enige echte voordeel wat ik zie is dat je brute-force inlog kan blokkeren, maar dat bijhouden van de ip-adressen lijkt me een beetje onnodig.

[trinite_t]

SFB schreef op vrijdag 15 mei 2009 @ 08:45:
[..]
• Is dat niet het geval: pak de cookie erbij en vergelijk de userid en (gehashde) wachtwoord in de cookie met de gegevens in de database.
[..]

Nooit, maar dan ook nooit, zet je een (gehashed) wachtwoord in een cookie. Zelfs userid zou ik niet doen.
Bij mijn in m'n cookies staat alleen een cookie_id en een random hash, aan de hand hiervan kun je alle andere benodigde data uit de database halen.

Verder kun je dan bij verschillende cookies hetzelfde gebruikersid in de db hebben staan, dus volgens mij lost dat ook het dubbel in kunnen loggen op.

[ Voor 13% gewijzigd door trinite_t op 15-05-2009 10:41 ]

[Janoz]

Ik vind je stap 2 heel vreemd. Waarom zou je uberhaupt een userid met gehashed wachtwoord op gaan slaan bij de client? Er is geen enkele noodzaak om de waarde die je daar op slaat ook maar ergens op te baseren. Waarom gebruik je hier niet gewoon een random string voor?

[Noxious]

Fuzzillogic schreef op vrijdag 15 mei 2009 @ 10:33:
Sessie koppelen aan IP-nummer is niet verstandig. Mensen met trunked lines surfen vaak met twee of meer IP-nummers tegelijk. Voor die maak je het dus onmogelijk om in te loggen.

Klopt, en dat komt vooral bij zakelijke gebruikers / werklocaties voor. Ook wifi access points zijn hier berucht om.

[doeternietoe]

trinite_t schreef op vrijdag 15 mei 2009 @ 10:38:
Nooit, maar dan ook nooit, zet je een (gehashed) wachtwoord in een cookie. Zelfs userid zou ik niet doen.
Bij mijn in m'n cookies staat alleen een cookie_id en een random hash, aan de hand hiervan kun je alle andere benodigde data uit de database halen.

Agree, even vergeten anders had ik het ook in m'n bericht gezet.

Het hele idee van een hash is weg als je 'm per cookie bij iedere request gaat versturen naar je server, zeker als je geen salt gebruikt. Welk stuk extra veiligheid geeft dat dan nog?

[Cartman!]

met $_SESSION zou ik niet werken met zulke dingen want die instellingen wisselen per server met timeouts enzo. Gewoon cookie uitlezen waar een hash instaat die overeenkomt met een sessie met bijhorend userid.

En zoals gezegd niet locken op ip, die mogelijkheid laat je over aan de gebruiker zelf.

[ Voor 17% gewijzigd door Cartman! op 15-05-2009 11:08 ]

[Voutloos]

Janoz schreef op vrijdag 15 mei 2009 @ 10:42:
Ik vind je stap 2 heel vreemd. Waarom zou je uberhaupt een userid met gehashed wachtwoord op gaan slaan bij de client? Er is geen enkele noodzaak om de waarde die je daar op slaat ook maar ergens op te baseren. Waarom gebruik je hier niet gewoon een random string voor?

Check. Dat moet eerst anders, want zo lang dat op de huidige manier werkt zijn alle overige security afwegingen totaal niet relevant.

[Tjolk]

Janoz schreef op vrijdag 15 mei 2009 @ 10:42:
Ik vind je stap 2 heel vreemd. Waarom zou je uberhaupt een userid met gehashed wachtwoord op gaan slaan bij de client? Er is geen enkele noodzaak om de waarde die je daar op slaat ook maar ergens op te baseren. Waarom gebruik je hier niet gewoon een random string voor?

Nu ja, daar heb je een punt. Dan moet ik alleen wel de random string ook in de database opslaan om te kunnen vergelijken.

Overigens lijkt het risico van een gehashd wachtwoord in een cookie met zéér klein. Ik gebruik er een eigen gemaakte hash voor, en met alleen die hash kunnen ze niets. Maar goed, een random string is natuurlijk helemaal veilig.

Het eerdere probleem waarmee ik de topic gestart heb, heb ik inmiddels opgelost. Wat ik nu doe is een waarde in de database opslaan welke gekoppeld is aan een IP en wat samen ook weer een unieke waarde oplevert. Die waarde wordt opgeslagen in de cookie en bij het hervatten van de sessie vergeleken met de waarde in de database. Daarbij kunnen meerdere van die waardes in de database opgeslagen. Op het moment dat je ergens uitlogt wordt die waarde weer uit de database verwijderd (en eventuele anderen die bij de user_id/IP combinatie horen worden ook opgeruimd, al zouden die er in principe niet moeten staan).


Dat het koppelen van een sessie aan een IP niet verstandig is ivm proxy's e.d. ben ik het niet geheel mee eens. Men heeft de keuze om de login te onthouden, kies je daar niet voor dan wordt er niets met je IP gedaan en kun je zolang de sessie duurt gewoon werken (ofwel: 1 uur of totdat je de browser sluit).

[Cartman!]

Maak het jezelf niet moeilijk met meerdere systemen in 1 waar je nu mee bezig bent. Gewoon elke login een sessie in de db geven met daarbij de bijhorende mogelijkheden (onthouden ja/nee (evt. hoe lang), vast op ip, etc). Wat als iemand zn login wel wil onthouden maar achter netwerk zit met loadbalancing (meerdere ip's), dat kan dan ineens niet...

[trinite_t]

SFB schreef op vrijdag 15 mei 2009 @ 13:02:
[...]
Nu ja, daar heb je een punt. Dan moet ik alleen wel de random string ook in de database opslaan om te kunnen vergelijken.

like duh

Overigens lijkt het risico van een gehashd wachtwoord in een cookie met zéér klein. Ik gebruik er een eigen gemaakte hash voor, en met alleen die hash kunnen ze niets. Maar goed, een random string is natuurlijk helemaal veilig.
[...]

Een eigen hash functie? Ik denk dat dat juist makkelijker te kraken is, van veel hashfuncties zijn de veiligheidsproblemen zolangzamerhand wel bekend (denk aan md5/sha1, niet te herstellen, maar wel via rainbow table te achterhalen). Het zou mij niet verbazen als een eigen gemaakte hash functie "gewoon" te decrypten is. Dan maakt zelfs de hash lengte niet eens meer uit...

Let wel, ik zeg niet dat het zo is, maar denk er iig altijd goed over na als je eigen/niet bewezen technieken gaat gebruiken.

[Voutloos]

trinite_t, het gaat puur om een willekeurig hash output. Het hash algoritme zelf hoeft niet per se te veranderen.

[trinite_t]

Voutloos schreef op vrijdag 15 mei 2009 @ 13:51:
trinite_t, het gaat puur om een willekeurig hash output. Het hash algoritme zelf hoeft niet per se te veranderen.

Als ik dit lees:

SFB schreef op vrijdag 15 mei 2009 @ 13:02:Overigens lijkt het risico van een gehashd wachtwoord in een cookie met zéér klein. Ik gebruik er een eigen gemaakte hash voor, en met alleen die hash kunnen ze niets. Maar goed, een random string is natuurlijk helemaal veilig.
[...]

Dan gaat het volgens mij niet om een willekeurige hash output. Onder een willekeurige hash output versta ik een gehashte random string, niet een wachtwoord dat gehashed wordt.
Verder heeft het hashen van een random string trouwens geen meerwaarde, aangezien je het aantal mogelijke resultaten alleen maar kleiner maakt, maar dat terzijde.

[ Voor 9% gewijzigd door trinite_t op 15-05-2009 13:57 ]

[Janoz]

SFB schreef op vrijdag 15 mei 2009 @ 13:02:
[...]
Nu ja, daar heb je een punt. Dan moet ik alleen wel de random string ook in de database opslaan om te kunnen vergelijken.

klopt

Overigens lijkt het risico van een gehashd wachtwoord in een cookie met zéér klein. Ik gebruik er een eigen gemaakte hash voor, en met alleen die hash kunnen ze niets. Maar goed, een random string is natuurlijk helemaal veilig.

Het risco lijkt jou klein, maar dat is het niet. Een cookie moet je als onveilig en publiek beschouwen. Aan de ene kant kan de gebruiker het makkelijk aanpassen en aan de andere kant kan iemand met een beetje moeite de inhoud van een cookie ook nog wel achterhalen bij iemand anders.

Om te beginnen is er geen enkele noodzaak om voor dit token ergens op te baseren. Het slaat dus nergens op om mogelijk gevoelige gegevens publiek beschikbaar te maken. Sterker nog, je beperkt jezelf alleen maar in de mogelijkheden. Om nu een cookie te invalideren zal iemand zijn wachtwoord aan moeten passen! Zou je gewoon random tokens in je database aan een gebruiker gaan hangen dan kun je gewoon een record uit je DB flikkeren en dat specifieke token is ongeldig.

Het eerdere probleem waarmee ik de topic gestart heb, heb ik inmiddels opgelost. Wat ik nu doe is een waarde in de database opslaan welke gekoppeld is aan een IP en wat samen ook weer een unieke waarde oplevert. Die waarde wordt opgeslagen in de cookie en bij het hervatten van de sessie vergeleken met de waarde in de database. Daarbij kunnen meerdere van die waardes in de database opgeslagen. Op het moment dat je ergens uitlogt wordt die waarde weer uit de database verwijderd (en eventuele anderen die bij de user_id/IP combinatie horen worden ook opgeruimd, al zouden die er in principe niet moeten staan).

Waarom waarde combineren met IP? Waarom niet gewoon die waarde in je cookie stoppen? Op de serverkant heb je het token, heb je het IP waar het bij hoort en weet je welke IP er bij zou moeten horen.

Dat het koppelen van een sessie aan een IP niet verstandig is ivm proxy's e.d. ben ik het niet geheel mee eens. Men heeft de keuze om de login te onthouden, kies je daar niet voor dan wordt er niets met je IP gedaan en kun je zolang de sessie duurt gewoon werken (ofwel: 1 uur of totdat je de browser sluit).

Wanneer je je algoritme niet zo enorm afhankelijk maakt van het IP dan kun je de gebruiker de keuze geven. Zet gewoon het token bij de client en in de database. Wanneer de gebruiker aangeeft de sessie aan het IP te willen koppelen sla je het IP ook op. Bij het valideren controleer je alleen op IP wanneer er een IP bij dat token staat en klaar is kees.

Hoe meer info je in je token versleutelt die ergens op is gebaseerd hoe onveiliger je algoritme wordt!!.

[Cartman!]

Ik zou het trouwens irritant vinden als ik op mn laptop uitlog en dat ook mn desktop pc is uitgelogd omdat ze op t zelfde ip-adres zitten. Dat zijn keuzes voor de gebruiker (zie logout pagina hier op GoT bijv).

[Voutloos]

trinite_t schreef op vrijdag 15 mei 2009 @ 13:56:
[...]
Als ik dit lees:

Je hebt gelijk, ik haalde wat reacties door elkaar. Inmiddels moge duidelijk zijn de het sessie id random moet zijn.

[Tjolk]

Goed, ik heb jullie raad ter harte genomen. In de cookie staat nu een random string, en daar wordt naar gezocht in de database, waarna e.e.a. verder wordt afgehandeld.

Het IP-adres heb ik eruit gehaald.

Bedankt voor de tips!

[Precision]

Ik werk ook met een random string die ik opsla als sessie in de database, ik laat de gebruiker er eventueel een locatie aanhangen.

Stappenplan:
1) Gebruiker bezoekt pagina
2) ($_SESSION["logged_in"] = true;) en is de info ($_SESSION["info"]) opvraagbaar? stap 6 en anders stap 3
3) Indien er geen sessie aanwezig is, kijk of er een cookie ($_COOKIE["login"]) aanwezig is, is dit zo? stap 4 anders stap 7
4) Is de cookie aanwezig en is deze valid? Stap 5 en anders stap 7
5) Regel dan de $_SESSION afhandeling, stap 6
6) OK, gebruiker is ingelogd
7) Toon inlogvenster
Ik werk zo dat alle info over een gebruiker in klasse User wordt opgeslagen, en die serialize() ik en stop ik in een $_SESSION["info"]. als ik dan iets nodig hebt is het bv. unserialize( $_SESSION ) -> getUserName();
De klasse User die ik link aan $_SESSION["info"] is er één met alleen maar getters en die enkel maar geset kan worden via de constructor die een object verwacht van type User, dusja ik heb praktisch 2 klasses User, beetje zoals bij asp dat je UserDTO gebruikt

[ Voor 44% gewijzigd door Precision op 18-05-2009 17:49 ]

[HuHu]

Wat een ingewikkeld ding, waarom niet gewoon zoiets:

1. gebruiker bezoekt een pagina en bovenaan staat session_start() in de PHP-code
2. is de gebruiker ingelogd ($_SESSION['logged_in'] == true)?
- ja: geen probleem, toon pagina
- nee: HTTP-redirect naar inlog-formulier

Meer dan dit hoeft het toch niet te zijn?

[HuHu]

Ow... eventueel voeg je natuurlijk aan de $_SESSION['logged_in'] == true nog iets toe als:

PHP:

session_start();

if ($_SESSION['logged_in'] == true && $_SESSION['ip'] == $_SERVER['REMOTE_ADDR']) {
  // toon pagina
} else {
  // redirect naar log-in
}

Om zo je sessie aan het IP-adres te koppelen.

[remmelt]

Voorts is het natuurlijk heel leerzaam om zoiets zelf te schrijven, maar waarom maak je geen gebruik van een bestaand framework? Daar zitten de meeste dingen al in en heb je het voordeel van de vele ogen die de code bekijken. Kijk bijvoorbeeld eens naar Zend Framework.

[Patriot]

HuHu schreef op maandag 18 mei 2009 @ 18:50:
Wat een ingewikkeld ding, waarom niet gewoon zoiets:

1. gebruiker bezoekt een pagina en bovenaan staat session_start() in de PHP-code
2. is de gebruiker ingelogd ($_SESSION['logged_in'] == true)?
- ja: geen probleem, toon pagina
- nee: HTTP-redirect naar inlog-formulier

Meer dan dit hoeft het toch niet te zijn?

Dan omzeil je het hele idee van ingelogd blijven door middel van cookies toch, lijkt me niet echt handig?

HuHu schreef op maandag 18 mei 2009 @ 18:54:
Ow... eventueel voeg je natuurlijk aan de $_SESSION['logged_in'] == true nog iets toe als:

PHP:

session_start();

if ($_SESSION['logged_in'] == true && $_SESSION['ip'] == $_SERVER['REMOTE_ADDR']) {
  // toon pagina
} else {
  // redirect naar log-in
}

Om zo je sessie aan het IP-adres te koppelen.

Hangt een beetje af van het soort koppeling, het is in dit geval eenzijdig. Dat wil zeggen, een sessie krijgt wel een IP aangewezen maar een IP geen sessie (zoals ze dat hier op T.net volgens mij wel doen?).

[HuHu]

Patriot schreef op maandag 18 mei 2009 @ 19:05:
[...]


Dan omzeil je het hele idee van ingelogd blijven door middel van cookies toch, lijkt me niet echt handig?

Hoezo dan? De aanroep naar session_start() regelt al het ingelogd-blijven gedoe, daar hoef je zelf niet naar te kijken. Standaard zet PHP een cookie volgens de instellingen in je php.ini (met een bepaald sessie-id, lifetime, naam, enz...). Bij elk request wordt dat cookie vanzelf meegestuurd en PHP regelt het ophalen van de sessie gegevens en dergelijke.

[...]


Hangt een beetje af van het soort koppeling, het is in dit geval eenzijdig. Dat wil zeggen, een sessie krijgt wel een IP aangewezen maar een IP geen sessie (zoals ze dat hier op T.net volgens mij wel doen?).

Hier op Tweakers.net en ook op FOK! en vele andere sites heb je per sessie één IP, oftewel: je sessie is gekoppeld aan je IP. Sessies zijn sowieso per computer (dus niet per se ook per IP), omdat het cookie maar op één computer staat.

Je wilt ook geen sessie aan een IP toekennen, want anders zou iemand met hetzelfde IP opeens je sessie delen. Je slaat het IP op bij (of in) de sessie, zodat je kunt controleren of de sessie bij elk request nog wel van hetzelfde IP vandaan komt.

[Patriot]

HuHu schreef op maandag 18 mei 2009 @ 19:19:
[...]
Hoezo dan? De aanroep naar session_start() regelt al het ingelogd-blijven gedoe, daar hoef je zelf niet naar te kijken. Standaard zet PHP een cookie volgens de instellingen in je php.ini (met een bepaald sessie-id, lifetime, naam, enz...). Bij elk request wordt dat cookie vanzelf meegestuurd en PHP regelt het ophalen van de sessie gegevens en dergelijke.

Met ingelogd blijven doelt men over het algemeen op een aparte cookie die ervoor zorgt dat je ook tussen verschillende sessions ingelogd blijft.

[...]

Hier op Tweakers.net en ook op FOK! en vele andere sites heb je per sessie één IP, oftewel: je sessie is gekoppeld aan je IP. Sessies zijn sowieso per computer (dus niet per se ook per IP), omdat het cookie maar op één computer staat.

Die koppeling is er dus niet per definitie, bij Tweakers.net is het in ieder geval optioneel. Dat is ook logischer, omdat een gebruiker die om één of andere reden van meerdere ip's jouw site kan bezoeken anders geen toegang (of in ieder geval zeer beperkte toegang) zou hebben tot je website.

Je wilt ook geen sessie aan een IP toekennen, want anders zou iemand met hetzelfde IP opeens je sessie delen. Je slaat het IP op bij (of in) de sessie, zodat je kunt controleren of de sessie bij elk request nog wel van hetzelfde IP vandaan komt.

Zo vanzelfsprekend vind ik het anders niet dat je een sessie niet aan een IP vastkopppelt. Het hangt sterk af van je users (gebruikers die niet weten of ze een statisch danwel dynamisch IP hebben wil je de optie waarschijnlijk niet geven), maar het is zeker een mogelijkheid.