[PHP] Wat is veiliger? Cookie of Sessie?

[Evilbee]

Ik ben nu bezig een website te maken met login mogelijkheid. Maar ik zat me nu af te vragen wat nu beter is, Cookies of Sessies. Met cookies weet ik dat ik er veel informatie in kan gooien, en bij sessies kan dit volgens mij niet. Of is een combinatie hiervan het veiligste? Of is er nog een andere mogelijkheid om bepaalde pagina's te beveiligen?

[Tom-Eric]

Een sessie wordt nog steeds opgeslagen als cookie geloof ik, maar in principe zijn cookies net zo (on)veilig als sessies als je ze verkeerd gebruikt. Je moet natuurlijk geen paswoorden in cookies zetten, maar als je bijvoorbeeld een hash opslaat die wat jij can controleren, dan doe je in principe hetzelfde als met sessies.

[Evilbee]

Dus dan zet je in je cookie of sessie iets zoals md5($password) ??

[Cyphax]

Je bedoelt met sessie dat je een sessie maakt zonder cookie, dus via GET of POST data?
Ik denk niet dat er een per definitie veiliger is dan de andere. Mijn voorkeur gaat uit naar de GET data ten opzichte van POST (refresh maar eens...) en cookies (die blijven achter) maar het nadeel is dat je dan niet kan bookmarken (als je systeem goed is opgezet).

Ik heb me dit ook weleens afgevraagd maar 'k vind cookies gebruiken toch niet zo mooi.
En je kan een sessie goed beveiligen opzich (hint: md5hash).

[edit] ah ik zie dat ik te traag ben

Evilbee schreef op 18 January 2003 @ 17:50:
Dus dan zet je in je cookie of sessie iets zoals md5($password) ??

Mwah bijvoorbeeld maar dan limiteer je jezelf (wachtwoord mag niet 2x voorkomen). Dus uitgebreider.
Ik het heb zo gedaan:
Na invoeren van naam en wachtwoord wordt in een tabel (MySQL) een sessie opgeslagen met daarin: userid, sessie-id (unique) en een random nummer (minimaal deze info).
md5-hash maak je dan van usernaam, wachtwoord en random nummer. Check dat bij elke keer dat een pagina geopend wordt.

[ Voor 40% gewijzigd door Cyphax op 18-01-2003 17:55 ]

[Verwijderd]

En wat is dan het nut van dat random nummer?

[Gwaihir]

In een PHP sessie kun je alle informatie gooien waar je maar zin in hebt. Die gaat in een array op de server. Daarvoor maakt het niet uit of je 'sessie eigenaar' identificeerd met een nummer in de URL, met een sessie cookie (in het geheugen van de gebruikers pc) of een permanent cookie (op de HD van gebruikers pc).

Een sessie cookie ligt voor de hand, tenzij je bang bent veel pertinente cookie-weigeraars op je site te krijgen. Een URL toevoeging werkt dan ook goed, maar je moet dan wel iets doen dat problemen voorkomt wanneer een URL met een oud sessienummer erin later weer wordt gebruikt (of gelijktijdig door twee mensen..). Mensen kunnen die URL's immers bookmarken, aan vrienden sturen, etc.

Overigens kun je de verschillende manieren prima combineren in één systeem (ben ik zelf van plan: URL-sessienummers alleen voor cookie weigeraars, permanente cookies voor wie altijd ingelogd wil blijven op een pc).

[Janoz]

Euhm. Wat heb je over beiden al doorgelezen? Ik krijg het ID dat je de werking van beiden niet helemaal begrijpt.

Cookies:
Per domein mogen een maximaal aantal cookies worden gezet. Er is een maximum voor omvang en voor aantal. Aangezien dit gewoon op de computer van de gebruiker staat kan deze de data redelijk makkelijk aanpassen.

Sessies:
Bij sessies word er op de server een bestandje (of db record, maar php's standaard implementatie maakt gebruik van een bestandje) aangemaakt waarin de variabelen worden opgeslagen. Er is geen enkele vorm van beperking op aantal en grootte behalve de beschikbare ruimte op je server. Verder wordt er een random uniek nummer/tekenreeks gegenereerd, en deze moet die client onthouden. Dit is om ervoor te zorgen dat het juiste bestandje bij de juiste gebruiker terecht komt. Deze code kan worden opgeslagen in een cookie maar kan ook als parameter aan elke link worden meegegeven.

[Cyphax]

Verwijderd schreef op 18 januari 2003 @ 17:59:
En wat is dan het nut van dat random nummer?

Dan kan iemand die van een ander naam en wachtwoord weet iig niet een sessie hijacken (omdat het met GET data gebeurt). Dan moet je logins wel beveiligen natuurlijk (als er al iemand is ingelogd kan je niet inloggen bijvoorbeeld).
Het sessienummer moet je ook meesturen. Dan stuur je alleen mee; sessienummer, en die hash.

't is NET even iets zekerder...

[Verwijderd]

Cyphax schreef op 18 January 2003 @ 18:04:

Dan kan iemand die van een ander naam en wachtwoord weet iig niet een sessie hijacken (omdat het met GET data gebeurt). Dan moet je logins wel beveiligen natuurlijk (als er al iemand is ingelogd kan je niet inloggen bijvoorbeeld).
Het sessienummer moet je ook meesturen. Dan stuur je alleen mee; sessienummer, en die hash.

't is NET even iets zekerder...

Het is redelijk onzinnig als je beseft hoeveel sessie id's er mogelijk zijn. NAtuurlijk verkleint het de kans, maar die kans is al zo klein. Ik vergelijk de user_id van het cookie met de user_id uit de sessie, dus het gebeurt alvast niet dat sessies per ongeluk van eigenaar veranderen. Opzettelijk kan nog wel, maar wegens het grote aantal mogelijke session id's maak ik me er geen zorgen over dat iemand de juiste session id bij een user_id in één keer raadt.
Bij verdachte zaken trash je namelijk die sessie.

[dusty]

Op mijn site gebruik ik een eigen sessie.. (die langdurig blijft staan..) en het bestaat uit 100 karakters...

Als een sessie niet klopt wordt er aan de client doorgegeven de sessie te verwijderen. als het dan nog een paar keer een sessie van dezelfde IP wordt afgegeven weet je dat er iets niet klopt......

[Cyphax]

Verwijderd schreef op 18 January 2003 @ 18:08:

[...]

Het is redelijk onzinnig als je beseft hoeveel sessie id's er mogelijk zijn. NAtuurlijk verkleint het de kans, maar die kans is al zo klein. Ik vergelijk de user_id van het cookie met de user_id uit de sessie, dus het gebeurt alvast niet dat sessies per ongeluk van eigenaar veranderen. Opzettelijk kan nog wel, maar wegens het grote aantal mogelijke session id's maak ik me er geen zorgen over dat iemand de juiste session id bij een user_id in één keer raadt.
Bij verdachte zaken trash je namelijk die sessie.

Ach het is een futiliteit... een random nummertje
Het is iets mooier vind ik, maar verder
Mijn sessie-id is niet random trouwens he..
Als dat bij jou wel zo is dan zou dat betekenen dat je het vrijwel hetzelfde hebt gedaan als ik

[dusty]

Verwijderd schreef op 18 januari 2003 @ 18:08:
[nohtml]
[...]
[/nohtml]
Opzettelijk kan nog wel, maar wegens het grote aantal mogelijke session id's maak ik me er geen zorgen over dat iemand de juiste session id bij een user_id in één keer raadt.

Gooi de "sessie-id's" in een database, en maak van dat column een unieke column, betekent meteen dat je gewoonweg geen kans meer hebt op een dubbele sessie-id

[Cyphax]

dusty schreef op 18 January 2003 @ 19:51:

[...]

Gooi de "sessie-id's" in een database, en maak van dat column een unieke column, betekent meteen dat je gewoonweg geen kans meer hebt op een dubbele sessie-id

Zo heb ik dat idd ook gedaan, sessionid is een int, auto_increment en not null.
Verder sla ik in een sessie ook op of ie open is of locked.
Dat om te voorkomen dat oude sessies gebruikt worden (als iemand uitlogt zal nooit via de history vd browser de pagina teruggeroepen kunnen worden).

[Suepahfly]

Sessies zijn in volgens mij veiliger ( sessies worden niet opgeslagen als cookie, maar als .SES bestand op de server) bovendien, als de browser gesloten wordt, wordt de sessie ook vernietigt.

Enige probleem waar je mee zit is wachtwoord encriptie, maar daar is vast wel een oplossing voor te vinden -md5 / SSH- (bovendien, hoe groot is de kans dat iemand een packet snifer draait op je ip en op moment dat je inlogd)

[ Voor 18% gewijzigd door Suepahfly op 19-01-2003 02:52 ]

[Verwijderd]

sessie....

[dusty]

Er zijn hier wat mensen die zich wat beter moeten verdiepen in het verschil tussen sessie en cookie.

Ik daag hierbij iedereen die denkt dat sessies veiliger zijn om dit maar eens haarfijn uit te leggen, daarna zal ik uitleggen waarom ik een systeem veiliger kan maken met cookies ipv sessies.

[Soultaker]

Aangenomen dat ik goede random nummers als sessie-ID gebruik en de bestanden die ik opsla niet door een ander proces in te zien zijn (desnoods hou ik ze in 't geheugen) is mijn sessie net zo veilig als een cookie, lijkt me. Om het overzetten naar een ander IP te voorkomen kan ik het IP van de client in de sessie opslaan. In theorie kan ik ook per request een nieuwe sessie-ID genereren, maar dat is slechts een klein voordeel, omdat er dan nog steeds iemand tussen de server en de client door kan komen.

Kom maar op met die uitleg.

[ Voor 4% gewijzigd door Soultaker op 19-01-2003 13:24 ]

[smaij]

Sessies kunnen net zo onveilig zijn als cookies. Als je goed gebruikt maakt (bij voorkeur van beide) kan je het systeem zo veilig mogelijk maken. Je kan zelfs het veiligheidsniveau aan de gebruiker overlaten. Als die wilt dat ie elke keer opnieuw inlogd, dan betekent dat er geen cookie nodig is, alleen een sessie-cookie die verwijderd word zodra de browser gesloten word.. Overigens word de sessie niet verwijderd van de server zodra de gebruiker zijn browser sluit. Dit is IMHO onmogelijk. De sessie verloopt en een script zal de verlopen sessies verwijderen.
Ik maak gebruik van sessie (dus ook sessiecookies) en cookies en een database, met daarin timetolive, userid, ip-adres en een random reeks etc. etc. Deze tabel is alleen nodig als er geen huidige sessie gevonden is, maar wel een cookie, om te kijken of de gegevens in de cookie juist ijn. 'Veiliger' kan imho niet en is in mijn wereld ook niet nodig. Je kan altijd nog SSL gebruiken, maar het nut daarvan is voor de meeste websites toch niet nodig.

[Zoijar]

Je slaat bij elke userid een key op die steeds veranderd bij elke pageview. Dit doe je op de server, bv in een database.
Dan encrypt je al je "sessie" data op die key (bv met rsa en 1024bit key ofzo). Dit laat je de client als cookie opslaan samen met z'n userid. Bij de volgende page view krijg de server dit cookie, zoekt hij de encryption key op uit de database (ahv userid) en decrypt het. Dan kan de server zo al zien aan de hand van een checksum of het een "valid cookie" was. Dan wordt er een nieuwe key gegenereerd en herhaald het process zich.

Wat kan hier fout gaan? Zo op het eerste gezicht zie ik persoonlijk geen enkele manier om dit te kraken. Als je het verkeer kan "sniffen" kan je er alsnog niets mee omdat de encryption key nooit verstuurd wordt. Als je het userid weet is dat leuk, maar ken je de key niet en kan je nooit een valid cookie maken. Je kan ook niet een replay attack doen omdat de key steeds wisselt. Zelfs als je verkeer zou kunnen veranderen schiet je er nog niets mee op.

Dit zou veiliger zijn dan de sessie manier waar je het session ID kan afvangen/sniffen en dan met IP spoofing de sessie kan kapen.

Ik verzin dit net ter plekke, misschien dat ik nog iets over het hoofd zie?

[Verwijderd]

Volgens mij is veiligheid een directe vijand van gebruikersgemak. Hoe meer veiligheid je wilt, hoe meer de gebruiker ermee geconfronteerd zal worden. Bij elke webapplicatie zul je veiligheid moeten afwegen tegen gebruikersgemak en kosten, en voor de beste combinatie kiezen.

Veiligheid is relatief, en volgens mij is de zwakste schakel meestal de gebruiker van de applicatie die zo nodig fool-proof moest zijn.

[Soultaker]

Zoijar schreef op 19 januari 2003 @ 13:50:
Ik verzin dit net ter plekke, misschien dat ik nog iets over het hoofd zie?

Eigenlijk zie ik niet hoe jou methode veiliger is dan gewoon een random sessie-id oversturen (zoals de PHP implementatie). De client weet niet wat er in zijn cookie zit; het is gewoon een ondoorzichtige handle; zowel in jouw voorstel als in de PHP implementatie. Dat geldt ook voor een 'hacker': of 'ie nou een sessie-id moet afvangen of gecodeerde sessiedata, in beide gevallen kan hij de gegevens terugzenden alsof hij de client was.

Voor de equivalentie is het wel van belang dat het sessie-id dusdanig random is dat het niet 'gegokt' kan worden (dus geen oplopende getallen gebruiken).

Je hebt gelijk als je zegt dat met jouw methode de sessiedata niet door de client gemanipuleert kan worden, maar dat geldt voor sessie-id's ook.

Volgens mij voegt jouw methode dus niets toe en belast je de server nodeloos met ingewikkelde encryptie, en de client met de verantwoordelijkheid zijn sessieinfo op te slaan. Dat laatste zou handig zijn, omdat de server dan minder hoeft te onthouden, ware het niet dat je toch al je key bij de server op moet slaan.

Care to comment?

[ACM]

dusty schreef op 19 January 2003 @ 11:53:
Er zijn hier wat mensen die zich wat beter moeten verdiepen in het verschil tussen sessie en cookie.

Ik daag hierbij iedereen die denkt dat sessies veiliger zijn om dit maar eens haarfijn uit te leggen, daarna zal ik uitleggen waarom ik een systeem veiliger kan maken met cookies ipv sessies.

Dat is een onzin statement
Cookies en sessies zijn verschillende toepassingen voor het opslaan van client-speficieke-data bij een bepaalde site.

Het grootste verschil is dat er bij cookies op de browser vertrouwd wordt voor het aanreiken van die data en bij sessies dat de server dat zelf doet.
Normaliter kan je je 'eigen' server wel vertrouwen en de browser van de gebruiker niet.
Alleen daarom is een sessie al veiliger dan een cookie.

Dat jij dan met een hele waslijst aan encryptie technieken de cookie net zo veilig kan krijgen als een sessie is leuk, maar een standaard toegepaste sessie is in principe veiliger dan een standaard toegepaste cookie.
Tenminste, op het gebied van betrouwbaarheid kwa informatie opslag en informatie "zekerheid". Veiligheid is maar een relatief begrip natuurlijk (zei Cheatah ook al ja).

De sessie is dan dus ook veiliger doordat de data erin niet meer gecontroleerd hoeft te worden op validiteit omdat het niet aangepast kon worden door de gebruiker.

Nou daag ik jou uit een cookie systeem veiliger te maken dan een goed sessie systeem, want dat beweer je te kunnen...

[Zoijar]

Soultaker schreef op 19 January 2003 @ 13:58:
[...]

Dat geldt ook voor een 'hacker': of 'ie nou een sessie-id moet afvangen of gecodeerde sessiedata, in beide gevallen kan hij de gegevens terugzenden alsof hij de client was.

Nee dat is niet waar. In het sessie geval dat boven werd genoemd kan de hacker op een spoofed ip het sessie id dat hij heeft afgevangen sturen en dan is het "gekraakt".

Met de cookie manier kan de hacker niets sturen. Hij zou wel een cookie met het userid kunnen sturen op een spoofed ip, maar hij kan nooit een geldig cookie construeren omdat de hacker de encryptie key niet kent. Elke poging hiertoe wordt dus meteen door de server ontdekt. (het cookie bevat een md5 checksum van de data, en wordt daarna rsa encrypted)
De hacker kan ook niet het complete cookie afvangen en doorsturen, omdat er dan altijd 1 van de twee (user of hacker) een ongeldig cookie stuurt en dit meteen wordt opgemerkt en gemeld.

edit:
ik ben persoonlijk voor een sessie systeem met SSL, maar probeer het van beide kanten te zien

[ Voor 7% gewijzigd door Zoijar op 19-01-2003 14:09 ]

[Soultaker]

Zoijar schreef op 19 January 2003 @ 14:07:
Nee dat is niet waar.

Wellus.

In het sessie geval dat boven werd genoemd kan de hacker op een spoofed ip het sessie id dat hij heeft afgevangen sturen en dan is het "gekraakt". Met de cookie manier kan de hacker niets sturen. Hij zou wel een cookie met het userid kunnen sturen op een spoofed ip, maar hij kan nooit een geldig cookie construeren omdat de hacker de encryptie key niet kent. Elke poging hiertoe wordt dus meteen door de server ontdekt. (het cookie bevat een md5 checksum van de data, en wordt daarna rsa encrypted)

En een hacker kan wel de sessie op de server manipuleren? Nee hoor.

De hacker kan ook niet het complete cookie afvangen en doorsturen, omdat er dan altijd 1 van de twee (user of hacker) een ongeldig cookie stuurt en dit meteen wordt opgemerkt en gemeld.

Dat kan ook met een random sessie-id per request, zoals ik voorstelde. Maar dat is niet perfect: als de hacker al een actie uitvoert en de originele client nooit meer een request doet (wanneer de hacker dus letterlijk de verbinding overneemt) gaat het nog steeds mis.

Ik blijf er dus bij dat jouw methode geen enkele security toevoegd. Als je dat anders ziet, mag je nogmaals een poging doen me te overtuigen.

[ Voor 3% gewijzigd door Soultaker op 19-01-2003 14:48 ]

[Soultaker]

Ik ben trouwens benieuwd hoe je een TCP connectie opzet met een spoofed IP, als je de lijn tussen de echte client en je server niet kunt afluisteren op IP pakketjes. Lijkt me (hardware) technisch vrijwel onmogelijk. Als security zo belangrijk is, moet je maar met encryptie gebaseerd op bekende public/private keys werken. (SSL werkt niet vanwege de man-in-the-middle attack).

[ Voor 16% gewijzigd door Soultaker op 19-01-2003 14:50 ]

[ACM]

Soultaker schreef op 19 January 2003 @ 14:50:
Ik ben trouwens benieuwd hoe je een TCP connectie opzet met een spoofed IP, als je de lijn tussen de echte client en je server niet kunt afluisteren op IP pakketjes. Lijkt me (hardware) technisch vrijwel onmogelijk. Als security zo belangrijk is, moet je maar met encryptie gebaseerd op bekende public/private keys werken. (SSL werkt niet vanwege de man-in-the-middle attack).

SSL kent ook een set functies voor public/private keys, SSL is meer dan alleen domweg https:// intikken en op ja drukken als die stomme server geen geldig certificaat had

Er zijn wel wat mogelijkheden voor sniffing en zeker voor spoofing, maar ik denk dat dat over het algemeen gruwelijk overschat wordt en weet vrij zeker dat een hacker zich veel eerder op andere aspecten zal richten dan proberen te sniffen en spoofen.

[TlighT]

Een inlogsysteem dat van cookies gebuik maakt, kan even veilig gemaakt worden als een systeem dat sessies gebruikt, maar dit kost wel meer moeite (omdat je dan eigenlijk je eigen sessie-systeem aan het bouwen bent). In de praktijk zullen systemen die van cookies gebruik maken veelal onveiliger zijn, omdat ontwikkelaars niet die moeite ervoor nemen.

[Soultaker]

ACM schreef op 19 januari 2003 @ 15:07:
SSL kent ook een set functies voor public/private keys, SSL is meer dan alleen domweg https:// intikken en op ja drukken als die stomme server geen geldig certificaat had

Voor zover ik weet worden per sessie de public keys gegenereerd en uitgewisseld. Alleen als je de key bij een rootserver kan verifieren ben je beschermd tegen hackers. Als je inderdaad gewoon op 'ja' drukt heb je in theorie geen enkele beveiliging tegen een man in the middle attack.

Het gaat er niet om dat SSL "functies voor public/private keys" heeft. Het kritische punt in public/private key encryptie is om je public keys op een betrouwbare manier te distribueren. Een key authentication server is daarbij natuurlijk van vitaal belang.

[Zoijar]

Soultaker schreef op 19 januari 2003 @ 14:46:
[...]


Wellus.


[...]


En een hacker kan wel de sessie op de server manipuleren? Nee hoor.


[...]


Dat kan ook met een random sessie-id per request, zoals ik voorstelde. Maar dat is niet perfect: als de hacker al een actie uitvoert en de originele client nooit meer een request doet (wanneer de hacker dus letterlijk de verbinding overneemt) gaat het nog steeds mis.

Ik blijf er dus bij dat jouw methode geen enkele security toevoegd. Als je dat anders ziet, mag je nogmaals een poging doen me te overtuigen.

goed punt Stond er net onder de douche nog is over te denken (moet iets doen onder het douchen...:X) en kwam toen idd op hetzelfde nadeel. zoals ik al zei ben ik ook voor de sessie oplossing, maar vanwege het statement van dusty probeer ik een veiligere cookie oplossing te vinden... ik denk nu dat beide manieren equivalent zijn, met cookie based iets in het nadeel omdat je theoretisch het cookie zou kunnen decrypten (niet echt realistisch).

Niets van dit is idd veilig voor man-in-the-middle. Dan moet je echt van te voren elkaars public key hebben. Het probleem is n hoe deze uit te wisselen, man in the middle kan namelijk beide partijen een van zn eigen keys geven. Dan kom je op dingen als key-escrow etc.

[Soultaker]

Zoijar schreef op 19 januari 2003 @ 15:25:
Niets van dit is idd veilig voor man-in-the-middle. Dan moet je echt van te voren elkaars public key hebben. Het probleem is n hoe deze uit te wisselen, man in the middle kan namelijk beide partijen een van zn eigen keys geven. Dan kom je op dingen als key-escrow etc.

Maar kom je dan door een authentication server heen? Ik denk van niet.

Ik ga er dan vanuit dat je de public keys van een aantal authentication servers veilig verkregen hebt (die staan op je Windows XP CD'tje enzo), anders sta je weer precies voor hetzelfde probleem.

[Zoijar]

Soultaker schreef op 19 januari 2003 @ 15:28:
[...]

Maar kom je dan door een authentication server heen? Ik denk van niet.

Ik ga er dan vanuit dat je de public keys van een aantal authentication servers veilig verkregen hebt (die staan op je Windows XP CD'tje enzo), anders sta je weer precies voor hetzelfde probleem.

Ja klopt dat is ook een niet op te lossen probleem. Je moet op een gegeven moment aan nemen dat je een authentic public key in bezit hebt. Bv door die aangetekend met de post te versturen? Of even langsbrengen hehe.

Of de klassieke oplossing dat authentication servers hun keys in de krant publiceren.

[ Voor 8% gewijzigd door Zoijar op 19-01-2003 15:36 ]

[ACM]

Soultaker schreef op 19 January 2003 @ 15:25:
Voor zover ik weet worden per sessie de public keys gegenereerd en uitgewisseld. Alleen als je de key bij een rootserver kan verifieren ben je beschermd tegen hackers. Als je inderdaad gewoon op 'ja' drukt heb je in theorie geen enkele beveiliging tegen een man in the middle attack.

Het gaat er niet om dat SSL "functies voor public/private keys" heeft. Het kritische punt in public/private key encryptie is om je public keys op een betrouwbare manier te distribueren. Een key authentication server is daarbij natuurlijk van vitaal belang.

Ik doelde meer op de client-side key authenticatie

Dat een client dus een vaste, voorgegenereerde (evt passwordprotected) key installeerd in zijn browser en je zo dus behoorlijk zeker kan zijn dat ie het idd ook is.
Maar voor een normale ssl-sessie heb je idd on the fly het oversturen van de pub key (ze worden niet on the fly gegenereerd meen ik, de private key sowieso niet maar de public key volgens mij ook niet). En is een authentication server erg belangrijk. Echter is dat voornamelijk belangrijk voor de klant die jou moet vertrouwen, niet voor jou om je klant te vertrouwen.

En volgens mij kent SSL standaard al bescherming tegen man-in-the-middle door dat het een vaste private key heeft.
Dat IE dan vervolgens verzuimde te controleren of het certificaat wel van de host komt dat het certificaat zegt dat het komt is wat anders...

[ Voor 10% gewijzigd door ACM op 19-01-2003 15:55 ]

[Soultaker]

ACM schreef op 19 januari 2003 @ 15:52:
Dat IE dan vervolgens verzuimde te controleren of het certificaat wel van de host komt dat het certificaat zegt dat het komt is wat anders...

Dat is ook geen zinnige controle in het geval van een man-in-the-middle attack. Voor de meeste andere hackpogingen, is het natuurlijk wel prettig.

[dusty]

Om een correcte antwoord te vinden zal er eerst een antwoord gevonden moeten worden op de vraag wat precies een cookie is en wat een sessie is, wat de overeenkomsten zijn en wat de verschillen tussen beiden zijn.

[Zoijar]

dusty schreef op 19 January 2003 @ 22:08:
Om een correcte antwoord te vinden zal er eerst een antwoord gevonden moeten worden op de vraag wat precies een cookie is en wat een sessie is, wat de overeenkomsten zijn en wat de verschillen tussen beiden zijn.

Een sessie is een paketje data dat op de server wordt bijgehouden (en waar ook alleen de server bij kan). Dit paketje wordt door de client geidentificeerd mbv een cookie die het nummer van het pakketje bevat. (ie. session-id)

Een cookie is in feite precies hetzelfde alleen staat de data direct in het cookie en houd de server zelf niets bij.

Een cookie werkt zo dat de server bepaalde waardes naar de client stuurt in een header (of met javascript) en dat de client bij de volgende request deze data weer naar de server stuurt in een header.

Als ik het zo zie zijn beide eigenlijk equivalent. Alles wat je met cookies zou kunnen doen kan je ook met sessies. Het enige verschil is waar de data wordt bijgehouden. Je zal meer moeite moeten doen met cookies zodat de client zelf die data niet kan veranderen.

En nu zou ik dan graag dusty's veiligere systeem horen voor een sessie met ip/referer check en wisselend session-id. (mijn systeem was veiliger dan een sessie systeem met vaste session-id, en gelijk aan een met wisselend)

[Verwijderd]

Zoijar schreef op 19 January 2003 @ 22:34:

En nu zou ik dan graag dusty's veiligere systeem horen voor een sessie met ip/referer check en wisselend session-id. (mijn systeem was veiliger dan een sessie systeem met vaste session-id, en gelijk aan een met wisselend)

En toch zou ik gebruik kunnen maken van jouw account als je jouw systeem zou implementeren in bijvoorbeeld dit forum.

[FlowDesign]

Ik ben een beetje nieuw met PHP en ben nu met een site bezig waarbij ik een deel van de site voor administratie doeleinden 'secure' heb gemaakt met login.
Ik heb de site gehost bij YourHosting.nl , die draaien daar alles op Linux enzo en ik kan gewoon een .htaccess en een .htpasswd file in een bepaalde map zetten samen met een php file en dan krijg je een login-schermpje als je in die map wil

Ik zie nu net dat dit trouwens ook met een cookie is

Heb ik meteen een vraag...

Is het beter om een logout functie te maken als iemand inlogt met een cookie?

[Zoijar]

Verwijderd schreef op 19 januari 2003 @ 22:38:

[...]

En toch zou ik gebruik kunnen maken van jouw account als je jouw systeem zou implementeren in bijvoorbeeld dit forum.

Hmmm hoe dan? En dan op zo'n manier dat het met cookies niet kan? Dus bv getvars in een img url vallen dan al weg. (bovendien kan dat niet met een steeds wisselend sessie id)

[ Voor 9% gewijzigd door Zoijar op 20-01-2003 11:11 ]

[LightYears]

Ervan uit gaande dat vele hun cookies uithebben of uit moeten hebben dan kan je beter voor een sessie kiezen, aangezien je op die manier meer mensen kan benaderen. Immers, sessies regelt de server

[Verwijderd]

Ik begrijp niet hoe sommige posters denken dat een cookie veiliger kan zijn dan een sessie... met een sessie staat de data op de server... dus die is niet voor de client bereikbaar (indien dit wel het geval is heb je wel een veel groter probleem dan de discussie cookie/sessie veilig/of niet). Encryptie voor de cookie kan ook voor de sessie-id dus dat maakt verder ook niet zo veel uit.. Als je de sessie-id ook nog koppelt aan het ip wordt het wel erg moeilijk om de id te sniffen en over te nemen... Ik wil die claim van dusty nog graag zien....

[Evilbee]

FlowDesign schreef op 19 January 2003 @ 22:52:
Ik ben een beetje nieuw met PHP en ben nu met een site bezig waarbij ik een deel van de site voor administratie doeleinden 'secure' heb gemaakt met login.
Ik heb de site gehost bij YourHosting.nl , die draaien daar alles op Linux enzo en ik kan gewoon een .htaccess en een .htpasswd file in een bepaalde map zetten samen met een php file en dan krijg je een login-schermpje als je in die map wil

Ik zie nu net dat dit trouwens ook met een cookie is

Heb ik meteen een vraag...

Is het beter om een logout functie te maken als iemand inlogt met een cookie?

Ik heb in het begin ook gewerkt met .htaccess maar dit is er lastig om er een dynamisch systeem van te maken. Je moet telkens htpasswd.exe uitvoeren om er een account bij te maken. Ik PHP kan je dit gewoon in een MySQL database zetten. Daarom ook mijn vraag welke van de 2 systemen het veiligste kan zijn

[ Voor 40% gewijzigd door Evilbee op 20-01-2003 21:40 ]

[Kwai_gon_jinn]

punt is van de topic starter ( hey klasgenoot ) of nou cookies of sessions veiliger zijn..

Mijn mening ervan is.. het is maar net hoe goed je je server hebt dicht getimmerd qua beveiliging.. niks is natuurlijk secure.. alleen lastiger te maken voor een ander..
maar sessions ( schijnt ) veiliger te zijn.. aangezien je vars in je geheugen worden op geslagen en deels op de server als session ergens op de schijf ( waarschijnelijk ergens anders dan de schijf waar de websites e.d. op komen ).

sessionid's zijn telkens verschillend ( hangt van de comp af waar je van afinlogt heb ik in de gaten.. op dezelfde comp is hetzelfde session id ( correct me if I'm wrong ) ).. Iig heb ik m'n sessions afgeschermd met md5 ( 2 maal ) en ben van plan om een andere encryptie te gaan gebruiken ervoor..

maar nou de cookies.. de cookies kun je ook wel encrypten.. alleen en laten uit lezen.. maar dan raad ik je aan om met een sleutel te gaan werken.. zodat een cookie hijacker niet zomaar cookies kan maken of clonen.. en die key zou ik net als een session random maken van af ut punt dat je inlogt tot het eind van wanneer je cookie lifetime verloopt.. om kort te wezen.. cookies zijn wel handig.. maar unsecure voor een inlogsysteem ( VINDT IK )

maar wrom 1 van de 2 kiezen als je het ook kunt combineren? Iig heb je een dubbele beveiliging.. want je moet cookies hijacken en packetsniffen voor de sessions.. en daarna nog eens decrypte.. maar voordat je dat af hebt is hoogst waarschijnelijk de lifetime van de cookie en de sessie verlopen.( mits je het goed hebt geconfigureerd )

enne wees nou eerlijk... de beveiligingslekken zitten in een klein gaat.. de mens maakt ook wellus fouten

[Verwijderd]

dusty schreef op 19 January 2003 @ 11:53:
Er zijn hier wat mensen die zich wat beter moeten verdiepen in het verschil tussen sessie en cookie.

Ik daag hierbij iedereen die denkt dat sessies veiliger zijn om dit maar eens haarfijn uit te leggen, daarna zal ik uitleggen waarom ik een systeem veiliger kan maken met cookies ipv sessies.

Ik durf het niet aan om uit te leggen of/waarom sessies veiliger zouden zijn, maar ik ben wel benieuwd naar je verhaal, kan je het eens uitleggen?

[dusty]

Verwijderd schreef op 21 januari 2003 @ 10:16:
[...]
Ik durf het niet aan om uit te leggen of/waarom sessies veiliger zouden zijn, maar ik ben wel benieuwd naar je verhaal, kan je het eens uitleggen?

Groot verhaal komt nog.

voor nu: Niemand heeft bepaald dat als je cookies gebruikt dat je dan in die cookies de gebruiker gegevens MOET plaatsen. Netzoals bij sessies kan je dat ook nog steeds op de server plaatsen. Echter met een eigen cookie kan je zelf bepalen hoe je de informatie in de cookie opbouwt en zit je niet aan de standaard sessie id's vast.

[Zoijar]

dusty schreef op 21 januari 2003 @ 10:23:

[...]

Groot verhaal komt nog.

voor nu: Niemand heeft bepaald dat als je cookies gebruikt dat je dan in die cookies de gebruiker gegevens MOET plaatsen. Netzoals bij sessies kan je dat ook nog steeds op de server plaatsen. Echter met een eigen cookie kan je zelf bepalen hoe je de informatie in de cookie opbouwt en zit je niet aan de standaard sessie id's vast.

Hmmm bij een sessie ben je vrij om je data op te slaan hoe je wilt (eventueel met eigen sessie handler). Verder ben je in je sessie ids ook volledig vrij mbv session_id(). Dus je kan zelf bepalen hoe je de informatie op bowt, en je zit niet aan de standaard sessie ids vast.

[Janoz]

dusty > In mijn belevings wereld is de php implementatie van sessie volgens het 'sessie systeem', maar iets volgens het 'sessie systeem' hoeft niet automatisch gelijk te zijn aan de php implementatie.

Persoonlijk definieer ik sessie-systemen als volgt:
Een sessie systeem is een systeem waarbij bij de gebruiker een (voor een gedeelte) random sleutel wordt geplaatst, en dat op de server een berg variabelen worden gehangen aan deze sleutel.

Een cookie systeem definieer ik als:
Een systeem waarbij alle data in een cookie wordt opgeslagen zodanig dat het inloggen gesimuleerd zou kunnen worden door zelf (in redelijke tijd) een cookie te fabriceren uitgaande van het feit dat een security by obscurity systeem hacken geen tijd kost.

[dusty]

Janoz schreef op 21 januari 2003 @ 11:13:
dusty > In mijn belevings wereld is de php implementatie van sessie volgens het 'sessie systeem', maar iets volgens het 'sessie systeem' hoeft niet automatisch gelijk te zijn aan de php implementatie.
[..]

Topic Titel: [PHP] Wat is veiliger? Cookie of Sessie?.

Ik betrek deze discussie dus op een cookie systeem of op de PHP-sessie systeem dús wel degelijk de PHP implementatie van sessies.

Kwa definities ben ik het met je eens, echter omdat dus het betrekking heeft op PHP betrek ik de sessie dus op de standaard PHP-Sessie prut.

[ Voor 13% gewijzigd door dusty op 21-01-2003 11:35 . Reden: additie. ]

[ACM]

Nou, dan neem ik React's (PHP) sessie-systeem als tegenvoorbeeld.

Maakt geen gebruik van php's session* functies en we noemen het toch een sessie systeem en is nog geschreven in PHP ook...

[Zoijar]

dusty schreef op 21 January 2003 @ 11:33:

[...]

Topic Titel: [PHP] Wat is veiliger? Cookie of Sessie?.

Ik betrek deze discussie dus op een cookie systeem of op de PHP-sessie systeem dús wel degelijk de PHP implementatie van sessies.

Kwa definities ben ik het met je eens, echter omdat dus het betrekking heeft op PHP betrek ik de sessie dus op de standaard PHP-Sessie prut.

Als je alles met je cookie systeem mag doen, dan mag je ook alles met je sessie systeem doen en dus de standaard PHP implementatie vervangen mbv session_id en session.handler.
Anders is het geen eerlijk vergelijk, dan stel ik dat er cookie in het topic staat en dat je alleen standaard cookies mag gebruiken zonder encryptie oid.

[dusty]

ACM schreef op 21 januari 2003 @ 11:45:
Nou, dan neem ik React's (PHP) sessie-systeem als tegenvoorbeeld.

Maakt geen gebruik van php's session* functies en we noemen het toch een sessie systeem en is nog geschreven in PHP ook...

Maakt het gebruik van SetCookie() toevallig ?

[ACM]

Ja, het is nogal suf om de header functie zelf direct aan te roepen, vind je niet
Maar dat de sessie-key in een cookie opgeslagen wordt maakt het absoluut geen cookie-systeem... Het maakt gebruik van cookies...

Als je een cookie-systeem voor je client-data gebruikt dan sla je de data op dmv setcookie, niet alleen de sessie-key...

[Kwai_gon_jinn]

maar ffies terug ontopic.. ( gaat nu wel verdacht steeds over "WAT" is per "definitie" een cookie/ session systeem )..

Wat is nou echt veiliger? Het verhaal van de sessies of het verhaal van de cookies.. ( ik hoop op het eerste ( ga ik m'n gelijk krijgen ) )

[Zoijar]

Kwai_gon_jinn schreef op 22 januari 2003 @ 09:51:
maar ffies terug ontopic.. ( gaat nu wel verdacht steeds over "WAT" is per "definitie" een cookie/ session systeem )..

Wat is nou echt veiliger? Het verhaal van de sessies of het verhaal van de cookies.. ( ik hoop op het eerste ( ga ik m'n gelijk krijgen ) )

Lijkt me toch wel dat je een antwoord uit de draad kan afleiden nu.

Een goed cookie systeem is veiliger dan een slecht sessie systeem; een goed sessie systeem is veiliger dan een slecht cookie systeem. Een goed sessie en goed cookie systeem zijn vrijwel equivalent, alleen vereist het cookie systeem wat meer werk.

[djluc]

Dat zou dan dus het voordeel van de twijfel geven aan Kwai_gon_jinn, kan ie blij zijn!

[ACM]

Persoonlijk vertrouw ik gewoon niet op het cookiesysteem voor het traceren van de gebruikers en het opslaan van relevante en/of belangrijke gerelateerde data. Daar hebben ze, vind ik, sessies voor bedacht en die vind ik er ook beter voor geschikt. (geen limitaties in hoeveel je op kan slaan, geen gedoe met encryptie als het echt veilig moet, geen gedoe met mensen die cookies blokken, zelfs daar is met sessies voor korte duur omheen te werken).

[Evilbee]

Kortom: Volgens de meerderheid zijn sessie veiliger?

[Soultaker]

Evilbee schreef op 22 January 2003 @ 16:17:
Kortom: Volgens de meerderheid zijn sessie veiliger?

In ieder geval beter, en niet minder onveilig.