[PHP/MySQL/sessions] Hoe een veilig inlogsysteem te maken?

[VR46]

Ik heb net een behoorlijk complex inlogscript gebakken, met challenge en response e.d. waardoor er nu veilig ingelogd kan worden op de site waarmee ik bezig ben.

Ik heb daar echter een vraagje over. Hoe kan ik op een veilige, snelle manier controlleren of een gebruiker is ingelogd of niet? Is het wel veilig om na het inloggen een sessie aan te laten maken, bijvoorbeeld $_SESSION['loggedin'] = true, en het dan telkens daar van af te laten hangen of een gebruiker wel of niet ingelogd is (ik heb zo mijn vermoedens van niet)?

Graag hoor ik jullie tips en ervaringen over.

Alvast bedankt!

[mithras]

Op zich zou het wel genoeg kunnen zijn, het is nog een stap veiliger om het sessieid op te slaan in de sessie en die ook in de database te koppelen. En dan elke keer een check doen tussen sessie en database. Doe anders eens een [search=php mysql login sessie]

offtopic:
En had je geen betere titel kunnen verzinnen?

[toost]

mithras schreef op vrijdag 25 mei 2007 @ 14:48:
Op zich zou het wel genoeg kunnen zijn, het is nog een stap veiliger om het sessieid op te slaan in de sessie en die ook in de database te koppelen. En dan elke keer een check doen tussen sessie en database. Doe anders eens een [search=php mysql login sessie]

offtopic:
En had je geen betere titel kunnen verzinnen?

dat kan wel maar dan ben je wel afhankelijk van een logout. Anders blijft de sessieid in de dbase staan, en mocht je gesnift zijn of wat dan ook en je sessieid is bekend dan kan deze gefaked worden waardoor je dus zelfs zonder username en password in het systeem kan komen. Je zou dan dus per page aanroep niet alleen van sessie naar dbase moeten controleren maar ook van dbase naar sessie. Want als iemand zijn browser heeft gesloten zonder op logout te drukken is die sessieid niet uit de dbase verwijderd.

[Gwaihir]

cbernardini schreef op vrijdag 25 mei 2007 @ 14:45:
Is het wel veilig om na het inloggen een sessie aan te laten maken, bijvoorbeeld $_SESSION['loggedin'] = true, en het dan telkens daar van af te laten hangen of een gebruiker wel of niet ingelogd is (ik heb zo mijn vermoedens van niet)?

Dáár zit 'm het probleem niet

Op een aantal andere plekken wel en daar valt heel wat over te lezen.

[VR46]

toost schreef op vrijdag 25 mei 2007 @ 15:01:
[...]


dat kan wel maar dan ben je wel afhankelijk van een logout. Anders blijft de sessieid in de dbase staan, en mocht je gesnift zijn of wat dan ook en je sessieid is bekend dan kan deze gefaked worden waardoor je dus zelfs zonder username en password in het systeem kan komen. Je zou dan dus per page aanroep niet alleen van sessie naar dbase moeten controleren maar ook van dbase naar sessie. Want als iemand zijn browser heeft gesloten zonder op logout te drukken is die sessieid niet uit de dbase verwijderd.

Ja maar stel dat je je sessie ID sha1 gehashed in de database opslaat en de gehashde versies ervan vergelijkt, en telkens wanneer iemand inlogd er éérst een nieuwe versie van wordt opgeslagen in de dbase en daarná wordt vergeleken of ze overeenkomen (volg je me nog ), dan moet dat probleem in principe toch opgelost zijn?

(excuses voor het niet afmaken van de titel van het topic - vergeten )

[ Voor 3% gewijzigd door VR46 op 25-05-2007 22:03 ]

[Verwijderd]

cbernardini schreef op vrijdag 25 mei 2007 @ 22:02:
[...]

Ja maar stel dat je je sessie ID sha1 gehashed in de database opslaat en de gehashde versies ervan vergelijkt, en telkens wanneer iemand inlogd er éérst een nieuwe versie van wordt opgeslagen in de dbase en daarná wordt vergeleken of ze overeenkomen (volg je me nog ), dan moet dat probleem in principe toch opgelost zijn?

(excuses voor het niet afmaken van de titel van het topic - vergeten )

Volgens mij helpt dit niks tegen ID hijacking...of je er nu xbit encryptie overheen gooit is allemaal serverside.

En ook na opnieuw inloggen een nieuw ID, ook dat blijft dan natuurlijk gewoon staan .

Je zou nog met een extra cookie aan de kant van de werkelijke client kunnen werken, maar opzich kan dat ook allemaal gesniffed worden. Dan blijft er alleen geforceerd uitloggen na x minuten geen activiteit over, maar dat wil je ook niet...

[VR46]

Kortom, er is geen veel veiligere manier van inlogcheck dan het voorbeeld dat ik genoemd heb? Of kennen jullie nog een alternatief?

En ook na opnieuw inloggen een nieuw ID, ook dat blijft dan natuurlijk gewoon staan .

Maar als je ze sha1 gehashed, zoals ik zei, opslaat in je db, heb je niks aan die sessie ID's als hacker, neem ik aan?

[ Voor 46% gewijzigd door VR46 op 26-05-2007 12:06 ]

[FireDrunk]

van gebruiker tot je server moet je beveiligen met HTTPS of VPN om het dicht te spijkeren
om code lekken te voorkomen is de manier van Mithras wel veilig

[VR46]

thijs_cramer schreef op zaterdag 26 mei 2007 @ 12:04:
van gebruiker tot je server moet je beveiligen met HTTPS of VPN om het dicht te spijkeren
om code lekken te voorkomen is de manier van Mithras wel veilig

Dat is handig bij het inloggen ja, maar ik kan moeilijk iedere pagina via HTTPS laten gaan om te checken of de gebruiker is ingelogd...

[TheBorg]

Je kunt de SID koppelen aan het IP adres, als iemand anders dan met dezelfde SID en een ander IP adres een beveiligde pagina opent de sessie vernietigen.

[Verwijderd]

cbernardini schreef op zaterdag 26 mei 2007 @ 12:01:
Kortom, er is geen veel veiligere manier van inlogcheck dan het voorbeeld dat ik genoemd heb? Of kennen jullie nog een alternatief?


[...]

Maar als je ze sha1 gehashed, zoals ik zei, opslaat in je db, heb je niks aan die sessie ID's als hacker, neem ik aan?

Maar wat doe jij met dat ID van je client...inderdaad, je verhasht het en controleert dat met die waarde uit de DB. Dat is heel effectief tegen directe DB hacks of naught beheerders, maar voor het beoogde doel hier is het alleen maar een overbodige extra stap.

[fleppuhstein]

Een redelijk veilige manier is om een key te generen. Deze op te slaan in een cookie. De cookie geef je een max van 2 dagen mee ofzo. Deze key sla je op in de database, inclusief het IP van de gebruiker.

Vervolgens bij een login check doe je controle op de cookie. En kijk je of de key ook bestaat in de database en controleer je of het ip adres overeen komt. Bij die check gooi je ook direct alle waardes uit je tabel die ouder zijn dan 2 dagen. Eventueel laat je dat laatste doen door cronjob.

- Sessie kunnen nooit langer dan 2 dagen open blijven staan.
- Er wordt geidentifieceerd met een eigen ontworpen key, dus niet een sessie id die een vast format heeft.
- En alleen het ipadres waarmee wordt ingelogd kan gebruik maken van je sessie.