Jeg har trukket adgangen tilbage, men de er stadig inde: en session er ikke det samme som en rettighed

Du fjernede en brugers rettighed. Måske lukkede du kontoen helt. Bagefter opdager du, at den person stadig kan gøre ting.

Der er ikke noget i stykker. At logge ind og at være berettiget er to forskellige øjeblikke, og imellem dem er der et hul.

Login sker én gang, rettigheden spørges hver gang

Når du logger ind, rækker systemet dig en billet. Billetten siger: denne person har bevist, hvem vedkommende er, og denne billet gælder indtil et bestemt tidspunkt.

Rettighed er et selvstændigt spørgsmål, der stilles igen ved hver forespørgsel. Men i praksis tager mange systemer ved login en kopi af rettighedskortet, af hensyn til farten, og bruger den kopi et stykke tid.

Heraf opstår to forsinkelser.

Den første: når du fjerner en rettighed, kan en åben session blive ved med at bære den kopi. Ændringen når den først, når sessionen fornys.

Den anden og vigtigere: at slette eller lukke brugeren river ikke den billet i stykker, vedkommende har. Billetten står ved sig selv og forbliver gyldig, indtil den udløber.

Reglen: at trække adgang tilbage er ikke at afslutte en session

Det er to forskellige handlinger, og kun at gøre den første lader et vindue stå åbent bag dig.

Vinduet er ikke uendeligt; en billet gælder ikke et døgn. Men det er heller ikke nul, og i en hastesituation er svaret "det lukker snart" ikke godt nok.

Når nogen stopper, eller en adgangskode er mistænkt

Gør tre ting, i rækkefølge.

Fjern rettigheden. Luk også kontoen, hvis det er berettiget.

Skift adgangskoden. Det lukker vejen til at hente en frisk billet i stedet for den, vedkommende har. Kun at fjerne en rettighed gør ikke det.

Fjern adgangstokens separat. Det er det trin, der oftest springes over. Et token er ikke en session: det udløber ikke af sig selv, det lever, indtil du sletter det. At skifte en brugers adgangskode gør ikke vedkommendes tokens ugyldige. Når du fjerner en bruger, så tjek separat, hvad der blev af vedkommendes tokens.

Og lad os rydde en misforståelse af vejen: totrinsgodkendelse hjælper dig ikke her. Den beskytter selve loginøjeblikket. Om en allerede åben session har den intet at sige.

Den modsatte retning: hvorfor bliver jeg logget ud hele tiden

Det er den anden side af den samme mekanisme.

Billetten har begrænset levetid, og grænsefladen fornyr den jævnligt, så længe du er på fanen. Luk fanen og kom tilbage timer senere: der er ikke sket nogen fornyelse, billetten er død, og du bliver bedt om at logge ind igen. Det er ikke en fejl.

Den anden, mindre kendte årsag er mere interessant: maskinens ur. En billet bærer et tidsstempel. Hvis serverens ur driver, kan en netop udstedt billet se ud, som om den kommer fra fremtiden eller er udløbet for længst. Symptomet forvirrer: adgangskoden er rigtig, login ser ud til at blive accepteret, og lige efter falder sessionen. At lede efter et urproblem på identitetssiden falder ingen ind, men led.

Hvad Atlas gør

Hos Atlas er den cookie, der går til browseren, ikke den ægte billet. Browseren bærer kun en meningsløs tilfældig identitet; selve billetten bliver på serveren.

Forskellen er konkret: selv hvis et browserhul læser cookien, får det ikke fat i billetten selv og kan altså ikke bære den et andet sted hen og bruge den dér. Det eneste, det kan gøre, er at handle fra den browser, så længe den session lever. Det er ikke nulrisiko, men det indsnævrer truslens omfang.

Åbne sessioner skrives til disk, så ingen bliver smidt ud, når produktet opdaterer. Skrivningen sker med vilje i ét trin: var filen blevet halvskrevet, ville, selv om læsesiden tåler det, alle åbne sessioner være faldet.

Det, der virkelig er værd at fortælle, er en mangel, der blev fundet her ved at måle.

Udløbne sessionsposter blev ryddet kun fra hukommelsen, ikke fra filen. En maskine i drift blev undersøgt: i filen lå fem udløbne poster, hver med en billet indeni. De ville have ligget der til næste login, for intet andet skrev nogensinde til den fil.

Kodens hensigt var i forvejen ikke at beholde dem. Det eneste, der manglede, var skrivetrinnet.

Læren gælder alle, der skriver sikkerhedskode: at glemme har to steder. Det, der er fjernet fra hukommelsen, er ikke fjernet fra disken, og af de to lever det på disken altid længst. Når du beslutter, at noget ikke må gemmes, er det andet spørgsmål altid det samme: hvor gemmes det?