Nødvendige sikkerhetstiltak ved innloggingsscript

av Espen Andersson — 6. oktober 2006 — kategorisert i Generelt IT-stoff — 13 kommentarer

Det ble tidligere i dag på Norsk Webforum reist spørsmål om hvilke sikkerhetstiltak det er nødvendig å tenke på når man lager innloggingssystemer og informasjonen lagres i $_SESSION[]-arrayet. Det er egentlig ganske så interessant og et tema som de færreste tenker over.

Problematikken jeg ønsker å ta opp er hvilke tenkelige scenarioer som kan oppstå omkring praksisen ved å lagre brukernavn og passord i to sesjoner og om det er nødvendig å sjekke denne informasjonen opp mot databasen for hver sidevisning. Veldig mange hopper over denne ekstra sjekken fordi de tenker at informasjonen ikke kan bli lagret i sesjonene med mindre informasjonen de skrev inn ved innlogging var korrekt. Dette er både helt riktig og fryktelig galt.

«Føre var»-prinsippet gjelder like mye når det kommer til programmering og sikkerhet som det gjør med naturen. Man vet aldri hva input er og systemet må kunne ta høyde for at input kan komme fra en ondsinnet bruker som gjør alt i sin makt for å kompromittere systemet. Et tenkelig scenario kan være som følger:

1. Bruker A er administrator og innlogget.

2. Bruker B er en ondsinnet bruker som på en eller annen måte har fått tak i brukernavnet og passordet til bruker A og er nå logget inn som bruker A.

3. Bruker A finner ut at noen misbruker kontoen hans og skifter brukernavn og passord, men hva hjelper det når noen allerede har fått tak i passordet hans og kan forbli innlogget på grunn av at han ble godkjent første gang?

Som vi kan se av eksempelet over bør vi finne en løsning på denne problematikken, og om nødvendig validere input for hver sidevisning, uansett hvor unødvendig det kan virke.

RSS Kommentarer (13)

# – av Robert W. – 7. oktober 2006

Som Hellkeepa sa på NWF, så er det bare å slette alle sessions til en bruker med den ID-en når man endrer passord eller brukernavn. Da må du jo så klart ha ID-en til brukeren i sessions.

# – av Espen Andersson – 7. oktober 2006

Eller hindre at en bruker kan være innlogget fra to forskjellige IP-adresser samtidig. Det er mange metoder å løse problemet på – jeg ønsker bare å gjøre folk oppmerksom på at det er mange saker relatert til sikkerhet som brorparten av dagens programmerere ikke har kjenskap til.

# – av Robert W. – 7. oktober 2006

Den var smart! Er det flere løsninger?

# – av Ivar – 9. oktober 2006

En kan jo sette sessions til å time ut etter en periode uten aktivitet.
Evt kan en isteden for å lagre bruker navn og passord som session, kan en lagre en vilkårlig streng ved innlogging i steden for brukernavn og passord. Dersom strengen forandres… ved at en annen logger inn, blir bruker logget ut siden en ny session string blir generert, derved må en logge inn igjen, og da blir en ny streng laget…

# – av Jonas Gulliksen – 22. mars 2007

Jeg har satt meg ned og tenkt etter dette problemet da jeg utvikler versjon 2 av Radioplanet.
Jeg kom frem til en løsning som lyder slik:
- Brukeren logger inn og får lagret en key som ligger lagret i databasen i en session
- På hver sidevisning sjekkes denne keyen opp mot databasen
- Er keyen i databasen endret, noe som forekommer om en bruker skifter passord, blir brukeren sendt rett til inloggings-siden
- Brukeren må validere passordet via en link som er sendt til satte e-post-adresse. Brukeren får ikke logget inn igjen før dette passordet er validert

Dette vil altså logge ut både ondsinnet og den faktiske brukeren. Er det den onsinnende brukeren som endrer passord, blir også den logget ut, og får ikke logget inn igjen før den faktiske brukeren har godkjent passordskiftet.

Men nå tenker dere sikkert; men den ondsinnede brukeren kan jo bare skifte e-post-adresse og motta validerings-eposten på sin egen adresse?
Niks, ikke hvis også e-post-adressen må godkjennes. En e-post sendes til den opprinnelige e-post-adressen, og må godkjenne den nye adressen.

Kom gjerne med innspill på denne løsningen :)

# – av David Steinsland – 23. mars 2007

Løsningen din høres ganske bra ut Jonas Gulliksen - tror kanskje jeg kommer til å bruke denne fremover. Dog, eneste problemet er jo hvis hackeren faktisk har tilgang til epost-adressen til "offeret". Men, hva er sjansen for at det skjer?

# – av David Steinsland – 23. mars 2007

Jonas Gulliksen: Jeg må si at jeg kopierte løsningen din. Den fungerer ganske bra.

Kan du nevne litt mer konkret om hva du gjør med keyen? Hva er innholdet i den? Hva gjør du når du endrer den?

Lykke til! ;)

# – av Jonas Gulliksen – 24. mars 2007

David Steinsland:
Keyen/nøkkelen som ligger i databasen er bare enn random nøkkel. Helt urelevant innhold i forhold til noe annet.
Du kan bare generere en random nøkkel, og hashe den med sha1 eller md5.
Eneste grunnen til denne, er at hvis det oppdages en endring av den i forhold til den nøkkelen som ligger i sessionen, blir brukeren logget ut.

Forstår? ;)

# – av David Steinsland – 24. mars 2007

Ah!

Genialt.. Dette må utforskes mer av :)

Takk! :)

# – av Robert W. – 25. mars 2007

Jonas Gulliksen, kanskje har missforstått. Men man kan jo bare gjøre det sånn at, når han slemme mannen kommer å skifter passord så slettes alle sessions. Det går ikke an å logge inn med det gamle eller nye. Brukeren settes da midlertidig som inaktiv til passord er verfisert. Deretter så får han en e-post om å verifisere det nye passordet, samme med e-post. Man kan jo bare gjøre det sånn? Trenger jo ikke key?

# – av Robert W. – 25. mars 2007

Det var flaut… Robert tulla nok bare der.

# – av Fredrik Moe – 30. oktober 2007

Hei, bruker EBA news CMS'et ditt, og lurer på hvilken type hash du bruker får og decryptere passordet. jeg finner rett og slett ikke ut av det.

# – av Espen Andersson – 30. oktober 2007

Jeg bruker sha1() kombinert med unike salt på brukerbasis.



Legg til kommentar


— Ingen HTML
— [em], [b], [u]
— [quote], [quote=navn]
— [url], [url=]

 
 
Grunnet omfattende spamangep må førstegangskommentatorer godkjennes manuelt. Vennligst ikke lagre samme kommentaren flere ganger om den ikke vises umiddelbart.