Hvordan bruges cookies bedst til godkendelse?

[NickyThomassen]

Indenfor en overskuelig fremtid, regner jeg med at skulle lave en hjemmeside fra bunden af, som bl.a. skal håndtere CPR-numre. Det betyder at sikkerheden er nødt til at være i top, og ting som kryptering bliver et krav. Det hele bliver lavet i Perl, fremvist med HTML+CSS og får en database som backend lager.

Alt undtagen cookies tror jeg at jeg har styr på, men de driller så tilgengæld også. Med tvungen kryptering burde risikoen for at nogen stjæler en brugers cookies, være ret lav, og samtidig sætter jeg cookies, til kun at må sendes via HTTPS, for alle tilfældes skyld.

Spørgsmålet handler mest om det sessions-ID, som bliver lagret i sessions-cookien. Kan det virkelig passe, at det er alt som bekræfter at en bruger er logget ind? Og hvis det er det, hvordan beskytter man så den cookie, og dens indhold, udover tvungen kryptering?

[AJenbo]

brugernavn + adganskode er ikke mere sikkert end sessions-ID-der-er-lige-så-lang-som-de-2-sammenlagt. så længe algoritmen der danner sessions-ID er i orden.

Her er en teknik der sørge for at kun 1 browser kan være logget ind pr. bruger.
http://stackoverflow.com/questions/4773609/what-is-a-relatively-secure-way-of-using-a-login-cookie

Her er også nogle headers som du bør indsætte på din side:
http://www.version2.dk/artikel/fire-http-headere-du-altid-boer-bruge-i-sikkerhedens-navn-55954

[NickyThomassen]

Nej, det er selvfølgelig rigtigt. Jeg har ikke kigget på Perls algoritmer endnu, men selv hvis Perl ikke har noget ordentligt, så kan man jo bare bruge systemets, eller 3. parts.

Tak for linksne, jeg kendte slet ikke til de ekstra headers, så der er vist lidt læsearbejde foran mig.

Når jeg nu skal lave sådan et sessions-ID, så ser man tit at det bliver lavet ud fra ($salt + $user_id). Jeg tænker lidt, at det måske ville give mening at (($salt + (2bits fra /dev/random)) + $user_id + $current_nano_time), og så lave sessions-ID'et 2048bits eller 3072bits langt. Er det noget du har set før?

[AJenbo]

Da sessionID skal sendes ved hver forspørgsel er det bedst ikke at lave det alt for stort, og det skal også enkodes. Bruger man hex bliver det en fordobling, så din 3072bits kode ender med at tage 0,7Kb for hvert eneste kald til serveren hvilket svare til et 32x32 png billed. Jeg ville nok begrænse det til 256bit og bruge base64, så er det kun 44bytes der skal sendes.

Problemet med at have random og tid i din cookie er at du så er nød til at gemme værdien på serveren og der vil være en forskellig værdi for hver gang brugeren logger ind og du ikke nødvendigvis ved hvornår et tidligere logind udløber (ved mindre det er en feature at man kun kan være logget ind på en computer af gangen)

[NickyThomassen]

De præcise detaljer om hvordan login-processen skal være, har jeg ikke fundet endnu. De kommer nok først mår jeg koder det, og man nemmere kan se fordele og ulemper.

Men jeg regnede ikke med at begrænse antallet af aktive sessioner en bruger har. Hvis de vil være logget ind flere steder fra, så burde programmet understøtter det, og så evt. have en indstilling, som forbyder det på bruger-basis og for hele programmet.

Til at understøtte det, havde jeg tænkt mig at bruge MySQL, som udover sessions-ID'et, også har oplysninger om sidste login, udløbsdato for sessions-ID og den slags. Desuden overvejer jeg at bruge reCAPTCHA, som kun bliver vist hvis man har X antal forkerte login-forsøg. RoundCube har et modul der understøtter det, og det virker ret godt der.

Selvom sessions-ID'et næsten kommer op på 1kb, så tror jeg ikke, at det er et problem for kablede computere. Min hovedregning siger, at har man en 1mbit kablet forbindelse i upload, så ligger 0.7kb cirka 1ms til for hver respons under ideelle forhold, og uden latency på netværket (hvilket selvfølgelig er umuligt).

Men det er rigtigt, at hvis et mindre sessions-ID er ligeså sikkert, så giver det ikke meget mening at bruge mere end det. Størrelsen af sessions-ID'et kan jo fx laves som en indstilling for programmet, så det er let at justere løbende.