Hoe veilig is de expire date/time van een cookie?

[Koffie]

Ben dus bezig om in Perl iets te doen met cookies.
Als je als expire date/time GEEN tijd meegeeft, of eentje in het verleden zal het cookie automatisch verwijderd worden zodra je de browser afsluit.

Echter hoe veilig is dit ??
Ik wil nl. cookies gebruiken om in te loggen, en gedurende het script ingelogd te blijven.
In testfase werkt het nu.
Eenmalig inloggen, en gedurende de hele sessie ben je inglogd.

Uiteraard komt er nog wel het e.e.a. in het cookie zelf te staan om de geldigheid te controleren.
Maar wat ik me dus afvraag, kun je met gemak vertrouwen op de expire date, of is dit zo lek als je mandje ?

[Verwijderd]

Nou toevallig weet ik dat het in konqueror (tenminste de laatste versie die ik geprobeerd heb) al niet werkte. Die gebruikt voor elke konqueror dezelfde kde-core en zolang je dus kde niet restart blijf je met konqueror ingelogd. Het is dus best wel browserafhankelijk.

[jopiek]

Op woensdag 13 februari 2002 10:50 schreef Koffie het volgende:
Ben dus bezig om in Perl iets te doen met cookies.
Als je als expire date/time GEEN tijd meegeeft, of eentje in het verleden zal het cookie automatisch verwijderd worden zodra je de browser afsluit.

Echter hoe veilig is dit ??
Ik wil nl. cookies gebruiken om in te loggen, en gedurende het script ingelogd te blijven.
In testfase werkt het nu.
Eenmalig inloggen, en gedurende de hele sessie ben je inglogd.

Uiteraard komt er nog wel het e.e.a. in het cookie zelf te staan om de geldigheid te controleren.
Maar wat ik me dus afvraag, kun je met gemak vertrouwen op de expire date, of is dit zo lek als je mandje ?

Je kunt beter voor tijdens het inloggen een sessie variabele gebruiken, die blijft in delucht zolang je de pagina's open hebt, maar wordt weggegooid zodra je de browser sluit. Cookies zijn alleen aardig om terugkerende bezoekers te kunnen herkennen...

[Koffie]

Op woensdag 13 februari 2002 10:54 schreef jopiek het volgende:

[..]

Je kunt beter voor tijdens het inloggen een sessie variabele gebruiken, die blijft in delucht zolang je de pagina's open hebt, maar wordt weggegooid zodra je de browser sluit. Cookies zijn alleen aardig om terugkerende bezoekers te kunnen herkennen...

Dat van sessions had ik al begrepen dat het idd. veiliger is ja.
Klopt mijn volgende inbeelding van session met cookies:

Je laat een compleet random getal/ID genereren, aan de hand van datum/tijdstip/whatever. Hier doeje nog een aantal leuke bewerkingen .. en je hebteen volledig random 'iets'.
Dit houd je in het perlscript vas, en schrijf je weg in het cookie (zou in principe niet eens in een cookie hoeven, toch?).
Elke keer als je checked of er een cookie is, controleer of je het getal in het cookie overeenkomt met wat het scrip denkt dat het is ...

Of zit ik nu helemaal fout te denken ??

[Janoz]

Op woensdag 13 februari 2002 10:54 schreef jopiek het volgende:

[..]

Je kunt beter voor tijdens het inloggen een sessie variabele gebruiken, die blijft in delucht zolang je de pagina's open hebt, maar wordt weggegooid zodra je de browser sluit. Cookies zijn alleen aardig om terugkerende bezoekers te kunnen herkennen...

klok & klepel???

In de meeste gevallen werken sessies gewoon met cookies. Met sessies zul je dus vaak dezelfde problemen hebben.

[Janoz]

Op woensdag 13 februari 2002 11:07 schreef Koffie het volgende:
Je laat een compleet random getal/ID genereren, aan de hand van datum/tijdstip/whatever. Hier doeje nog een aantal leuke bewerkingen .. en je hebteen volledig random 'iets'.
Dit houd je in het perlscript vas, en schrijf je weg in het cookie (zou in principe niet eens in een cookie hoeven, toch?).
Elke keer als je checked of er een cookie is, controleer of je het getal in het cookie overeenkomt met wat het scrip denkt dat het is ...

Bijna. Het script controleerd niet of het getal in de cookie overeenkomt met wat ie verwacht, maar kijkt of dat nummer een keer is uitgegeven en haalt de bijbehorende gegevens op (Uit bestand of db oid).

[Koffie]

Dat gedeelte van bijhouden/uitlezen is een extra stukje beveiliging neem ik aan.
Voor een impel beheer scripje wat je wel eens op andere PC's draait, zou het zonder een 'databaseje' al voldoende zijn, toch ?

[jopiek]

Op woensdag 13 februari 2002 11:10 schreef Janoz het volgende:

[..]

klok & klepel???

In de meeste gevallen werken sessies gewoon met cookies. Met sessies zul je dus vaak dezelfde problemen hebben.

eerder jij, dat is iig onjuist m.b.t. ASP/IIS waar sessie variabelen essentieel anders zijn als cookies...
Het is niet voor niets een variable:

Lifetime of Variables
A variable declared outside a procedure can be accessed and changed by any script in the ASP page in which it is declared.

A variable declared inside a procedure is created and destroyed every time the procedure is executed. No scripts outside that specific procedure can access or change that variable.

To make a variable accessible to several ASP pages, declare it either as a session variable or as an application variable.

Session Variables
Session variables store information about one single user, and are available to all pages in one application. Common information stored in session variables are username and userid. To create a session variable, store it in a Session Object.

Application Variables
Application variables are also available to all pages in one application. Application variables are used to hold information about all users in a specific application. To create an application variable, store it in an Application Object.

http://www.w3schools.com/asp/asp_variables.asp
http://www.scripts.nl/asp/asp_var_4.asp

aanvulling:
http://groups.google.com/groups?q=asp+difference+cookies+session&hl=nl&selm=%23PA91oWs%24GA.280%40cppssbbsa05&rnum=10
->
"Session objects are not cookies. A particular session is identified by a cookie on the client machine. The actual data is stored in the server's non-paged memory."

Er bestaat enige onduidelijkheid over het beestje een naam geven, daarom zeggen mensen schijnbaar afwijkende dingen die op hetzelfde neerkomen.

[Orphix]

Op woensdag 13 februari 2002 11:49 schreef jopiek het volgende:
eerder jij, dat is iig onjuist m.b.t. ASP/IIS waar sessie variabelen essentieel anders zijn als cookies...
Het is niet voor niets een variable:

De variabelen worden (gelukkig) server-side opgeslagen, maar de identificatie van de gebruiker wordt nog steeds client-side (in de vorm van een cookie) opgeslagen. Dus als de browser sluit worden niet 'opeens' je variabelen verwijderd, dit gebeurd na een bepaalde time-out. Sessies zijn beter dan cookies, maar het is nog niet perfect.

[ACM]

Op woensdag 13 februari 2002 12:42 schreef Orphix het volgende:
Sessies zijn beter dan cookies, maar het is nog niet perfect.

Die zin is fout.

Beter is "Sessies zijn beter dan cookies voor de opslag van allerlei belangrijke gegevens."

[Janoz]

Op woensdag 13 februari 2002 11:49 schreef jopiek het volgende:

[..]

eerder jij, dat is iig onjuist m.b.t. ASP/IIS waar sessie variabelen essentieel anders zijn als cookies...
Het is niet voor niets een variable:

Sorry voor het omhoog schoppen, maar hier wil ik nog ff op reageren. Tuurlijk is er verschil tussen sessions en cookies. Dit verschil is echter niet relevant bij het probleem van de topicstarter. Bij cookies worden de gegevens bij de client opgeslagen in het cookie, terwijl bij sessions een reverentie sleutel in een cookie wordt opgeslagen. Deze reverentie sleutel wijst op zijn beurt aan de serverkant naar een aantal variabelen. Er wordt nog steeds gebruik gemaakt van een cookie en aangezien het probleem van de topicstarter zich specifiek op de lifetime van die cookies richt is het gebruik van een session geen oplossing. Mischien zou een 'miereneuker' kunnen zeggen dat session-id's ook met een get-parameter kunnen worden doorgegeven, maar dit vind ik persoonlijk geen mooie oplossing.