Hoewel er niet echt een goed of fout is, ben ik benieuwd op welke waarde jullie je session timeout hebben staan. De default is 1440 seconden (24 minuten). Toch kan dat lijkt me in sommige situatie te kort zijn. Bijv. als je in de backend van de website een uitgebreid redactioneel artikel aan het schrijven bent. Dat kan best langer duren dan die 24 minuten. Als je dan na bijv. 40 minuten je artikel wil opslaan is je sessie verlopen ... oeps.
Maak je de sessie timeout-duur te lang, bijv. 2 uur, dan vergroot je (theoretisch gezien) de kans dat een sessie wordt gekaapt.
Dus wat is wijsheid? Wat is een goede session timeout-duur?
>> In een oplossing waarbij het niet uitmaakt dat een sessie verloopt is het verlopen van een sessie geen probleem...
Dat is zeker waar. De vraag is alleen óf, en zo ja hoe je dit volledig kan dichttimmeren.
>> Te meer omdat deze al naar gelang de situatie on-the-fly aangepast kan worden.
Dit is natuurlijk ietsje te makkelijk ... veel instellingen kunnen on the fly worden aangepast. Betekent echter niet dat je daarom niet hoeft na te denken over een goede basisinstelling.
>> De default sessie-timeout is een goede sessie-timeout.
Oké ... maar leg mij dan eens uit waarom die default setting van 1440 seconden (ofwel 24 minuten) een goede setting is volgens jou? Waar baseer jij dat op? Ik kan je alvast verklappen dat die 1440 seconden per toeval de default zijn geworden, omdat de default van oudsher eigenlijk een dag was (1440 minuten). In de loop der jaren zijn die minuten ooit per ongeluk seconden geworden. Er zit dus niet een of andere gedachte achter die 24 minuten. Maar dan ben ik dus benieuwd waarom dit volgens jou exact de juiste setting is.
De default instelling doet verder geen aannames over wat dat ook. Zie het als een initialisatie met een gedocumenteerde waarde. Deze standaard instellen op een andere waarde zonder dat je weet waarvoor deze gebruikt gaat worden is second guessing.
Toegegeven, het is naïef om er vanuit te gaan dat iets per definitie zijn default waarde heeft en het is altijd verstandig om dit te toetsen, maar ik vind het al helemaal takke-irritant als webhosters zelf denken slim te zijn en een heleboel waarden een eigen, en afwijkende, default te geven.
Assumption is the mother of all f*ckups, en ik kon mijzelf wel voor mijn kop slaan toen ik een poos geleden er achterkwam dat een host register_globals aan had staan, maar ik vroeg mij tegelijkertijd af wat de mentale gesteldheid van iemand is om dit zelf zo te configureren als de standaard al jaren "Off" is...
Defaults worden inderdaad vaker zomaar aangepast ... maar bij mij staat de default voor de session timeout wel gewoon op 1440. Dus die is niet aangepast. Ik kan 'm wel zelf wijzigen ... maar de vraag is in hoeverre dat dus een risico met zich meebrengt. Stel dat ik de timeout instel op bijv. 3600 seconden (ofwel een uur) worden mijn websites dan gevoeliger voor session hijacking? Of is het verschil tussen 24 minuten versus een uur verwaarloosbaar in dat opzicht?
In dat opzicht is het verwaarloosbaar. De risico's op hijacking worden ook zwaar overdreven. Het is uiteraard afhankelijk van de responsetijd van je applicatie, maar 63^27 is bijna een 4 met 48 nullen aan combinaties. In theorie kun je een keer geluk hebben en op een key als aaaaaaaaaaaaaaaaaaaaaaaaaaa tegenkomen, maar de kans daarop is 1 op de 63^27. Je beveiliging staat of valt niet met de sessieduur, maar de overige maatregelen. Op een forum als dit zou ik geen IP controle gebruiken, er is geen echt gevoelige informatie. Bij andere applicaties wel, of deels (bijvoorbeeld de eerste 3 octets). Vermoedelijk bestaat de session timeout ook alleen om sessies na verloop van tijd op te kunnen ruimen en heeft het geen ander doel. Hier heb ik geen harde data over, maar het voelt logischer dan iets anders.
Ik gebruik gewoon de default. Afhankelijk van de applicatie gaat dat gepaard met overige maatregelen, zoals bijvoorbeeld automatisch verlengen mbv ajax requests, IP controles etc. Ik moet er ook bij zeggen dat ik eigenlijk altijd een database session handler gebruik omdat dit wat meer controle geeft over het verloop etc. Het maakt het een stuk eenvoudiger om verdachte sessions te detecteren, en in het geval van een snel wisselend id vanaf 1 ip de toegang te blokkeren. Wat ik doe is niet eens heel relevant, het is per applicatie verschillend, per geval verschillend, het ligt net aan de eisen die je stelt (of die gesteld worden).
Voorbeelden genoeg, er is een topic van eerder vandaag waarin zo'n handler staat. Nu zou ik hem anders opbouwen, maar de strekking van het gebruik van [php]session_set_save_handler[/php] is hetzelfde. Je maakt een functie voor het lezen van je sessie, het openen, sluiten etc, en niet onbelangrijk: de gc handler. Je kunt hierdoor veel invloed uitoefenen vanuit je handlers met je implementatie. Het heeft als bijkomend voordeel dat je de sessies centraal kunt weergeven/stoppen etc. Je kunt gebruikers hiermee dus ook controle geven over hun lopende sessies.
