Vi gjør oppmerksom på at informasjonen gitt i denne bloggen er ferskvare og således kan inneholde feil. Aksjoner som gjøres på grunnlag av denne er på eget ansvar. Telenor tar ikke ansvar for innhold gitt i eksterne lenker.

tirsdag 17. november 2009

Passordskifte i utide

SANS Handler's Diary skrev for en tid tilbake en blogpost angående passordbytte, der vi i Telenor SOC er enig:

Veldig mange driftsorganisasjoner praktiserer en policy om at brukere må bytte passord flere ganger i året, typisk 4 ganger i året. Men hvorfor?

De vanlige måtene for å lure til seg et passord fra en bruker er enten å spørre etter det (phishing eller social engineering), bruteforce av forskjellige slag eller keylogging. Men hvilke av disse metodene blir mindre vellykket om man skifter passord ofte?

Ingen!

Har en bruker lagd et passord som er svakt, vil han mest sannsynlig lage et like svakt passord neste gang. Har derimot en bruker laget et godt passord, så vil han bli irritert over å måtte lage et like bra passord neste gang. Og da vil enten passordet blir en variant av forrige passord eller rett og slett et dårligere passord.

I tillegg blir det da lett for brukere å benytte seg av det samme passordet flere steder, noe som gjør det lettere for en angriper å få tak i passordet.

Hvorfor praktiserer så mange denne regelen angående passordbytte? Vel, den har hengt med fra tidenes morgen, da passord var et lite kort ord som lett kunne knekkes. Nå er derimot ikke dette tilfellet lengre, men regelen er her fortsatt. Én positiv ting med passordbytte er hvis noen allerede har fått tak i passordet ditt og har tilgang, så vil jo de stenges ute (for en viss tid i alle fall).

Spørsmålet er derimot om det er bedre med et godt og langt passord som er tilnærmet umulig å bryte, enn et passord som en angriper knekker og dermed får tilgang til systemer inntil brukeren må bytte passord igjen..

2 kommentarer:

Unknown sa...

Gode poenger!

Jeg er selvfølglig helt enig i at passordbytte ofte har en negativ innvirkning på sikkerhetsnivået. Det øker sannsynligheten for at dårlige passord velges og at brukerene sliter med å huske passordet og må bruke et støttesystem (PostIt-lapp-trikset). Og selv med krav til passord-kompleksitet vil brukeren da bare lage et passord som er godt nok, men med en teller el. (Vansk3ligPW#1, Vansk3ligPW#2 osv.). Som angriper trenger man da bare å knekke et passord og deretter lett følge brukerens endringer.

Jeg synes sog dere glemmer et viktig poeng. Noe som kanskje er enda viktigere i en passordpolicy enn selve kompleksiteten i passordet eller krav til passordbytte - er kravet til at man holder passordet personlig og ikke gjenbrukes. Her svikter nesten alle. Man gjenbruker samme passord på tvers av forskjellige løsninger eller sikkerhetsregimer. Enda værre er at man helt frivillig gir bort brukernavnet og passordet til en tjeneste til andre tjenesteleverandører. Et eksempel på dette er brukere som benytter tredjepartsløsninger for å få tilgang til sine "sky"-tjenester (eks. , eller brukere som opplyser om gyldige credentials til eks. Hotmail for å slurpe inn kontaktene sine til LinkedIn.

Og dette er under vanlig bruk av standard tjenester. Vi som jobber med dette vet at brukere desverre også finner på å dele ut passordet sitt til vilkårlige fremmede som spør om det ;) . Når da samme passord benyttes til msn, facebook og annet - så er det fort gjort å miste kontrollen over egne data.

Og hvis samme passordet benyttes på bedriftens nettverk, så kan det ha litt negative innvirkninger der også.....

itinsecurity sa...

Poenget er godt.. hyppig passordbytte er neppe særlig formålstjenlig. Men å aldri bytte det? Det har jeg heller ingen tro på.

Hele argumentasjonen kan like gjerne snus på hodet: Det er uhyre vanskelig å få alle, eller mange nok, brukere til å lage disse uknekkelige passordene. Og som Erik Alexander påpeker: du kan lage enkle systemer i dem også.

Derfor blir passordbytte fortsatt viktig, både for å hindre at de "ganske gode" passordene rekker å knekkes og fordi man får byttet et passord som kanskje allerede er knekt.

 
>