Et kodeord, der umiddelbart er svært at gætte, kan i praksis være et rigtigt dårligt kodeord. For det øger risikoen for, at brugeren omgår sikkerheden for at huske kodeordet. Det er et velkendt dilemma, og nu tager den britiske efterretningstjeneste GCHQ derfor et opgør med flere af de etablerede gode råd til password-sikkerhed.
Det er eksempelvis en udbredt praksis, at brugerne skal skifte deres kodeord med jævne mellemrum, der kan spænde fra 14 til 90 dage. Tanken bag denne politik er, at sandsynligheden stiger som en funktion af tiden for, at kodeordet er kompromitteret. Ved at skifte det hyppigt, får en hacker et kort tidsinterval til at udnytte kodeordet i.
Denne taktik kan især være nyttig, hvis brugeren har genbrugt det samme kodeord flere steder. Men det er bedre at hjælpe brugeren med at have et godt beskyttet kodeord, lyder det fra GCHQ's it-sikkerhedsafdeling CESG.
Problemet med at tvinge brugeren til at skifte kodeord hyppigt er, at det øger risikoen for, at brugeren sænker sikkerheden omkring kodeordet ved eksempelvis at skrive det ned eller vælge et nyt kodeord, der blot er en iteration af det gamle kodeord. Som eksempelvis 'nuskaljegskiftekodeordigen0915'.
Hos Center for Cybersikkerhed i Danmark, er man enig med den britiske anbefaling:
»Center for Cybersikkerhed er enig i, at man ikke skal bede brugere om at skifte password for tit. Hvis der er et krav om hyppig skift af password, er der større sandsynlig for, at brugerne skriver det ned på en seddel, og at de ikke ændrer det ret meget i forhold til det forrige password. De militære bestemmelser på området angiver 180 dage som passende. CFCS er også enig i, at passwords skal være lette at huske, for det er ikke ensbetydende med, at de er lette at gætte,« skriver Center for Cybersikkerhed i et e-mailsvar til Version2.
I stedet for hyppige kodeordsskift kan organisationen i stedet implementere overvågning af login-forsøg. Det kan bruges til at opdage usædvanlige login-mønstre og eventuelt give brugeren besked om alle login-forsøg, så brugeren kan gøre indsigelse, hvis der sker login, som brugeren ikke selv har foretaget.
Denne praksis bruges eksempelvis af Google, Facebook og Microsoft, hvor brugeren får besked, hvis der logges ind via en ny enhed eller fra en IP-adresse i et andet land.
Her kan det så i øvrigt være en god idé at sørge for, at det er relativt let for brugeren at skifte kodeordet, hvis der er blot den mindste mistanke om misbrug.
Tanken bag er den samme som det rutinemæssige skift af kodeordet, nemlig at kodeordet kan være kompromitteret, uden brugeren eller systemadministratoren ved det.
Hjælp brugeren med kodeordsadministration
Et andet problem, GCHQ tager fat i, er mængden af adgangskoder, som brugeren skal bruge. Selv inden for den samme organisation kan det være nødvendigt for brugeren at have adgangskoder til forskellige systemer.
Det kan afhjælpes med single-sign-on-løsninger, men kan også klares med password-managers som eksempelvis Lastpass. Her er det imidlertid vigtigt, at it-afdelingen stiller et redskab til password-administration til rådighed.
Alternativt risikerer man, at brugerne benytter de samme koder på flere systemer, eller skriver kodeordene ned på lapper på skrivebordet eller gemmer dem i tekstfiler.
Mange kodeord kan også få brugerne til at vælge dårlige adgangskoder, som er lette at knække, hvis en hacker eksempelvis får fat i en database med hashværdier af kodeordene.
Talrige eksempler fra hacking af systemer fra alt fra banker til dating-sider viser, at en stor del af brugerne vælger kodeord, som er overordentligt lette at gætte med moderne metoder.
Modtrækket har traditionelt været at opstille krav til kodeordene. Det kan være et mindste antal tegn, brug af både store og små bogstaver, tal og specialtegn.
Men nyere eksempler på lækkede kodeordsfiler viser, at det ofte fører til, at brugerne ikke skaber et stærkt kodeord ud fra det opstillede krav, men derimod konstruerer noget, de kan huske, som blot formelt opfylder kravene.
Det resulterer i kodeord som 'p@s5WorD777!', som vil opfylde de formelle krav og vil kategoriseres som 'stærkt' af de automatiske kodeordstjekkere, som mange tjenester anvender. Kodeordet består imidlertid af det meget anvendte 'password' med nogle meget almindelige udskiftninger af tegn, kombineret med en meget populær talrække og det mest populære specialtegn til slut.
Derfor vil sådan et kodeord være i risikozonen for at blive knækket i et dictionary-angreb med substitutionsregler, hvis hackeren har mulighed for det.
Giv 10 forsøg med forkert kodeord
Kodeord, der består af tilfældige tegn, skulle på papiret give den bedste sikkerhed, men i praksis resulterer sådanne kodeord i, at brugerne enten skriver dem ned eller glemmer dem.
For at være tilfældige bliver denne type kodeord genereret af software, men for at undgå usikker opbevaring eller opkald til supportafdelingen, så bør man benytte de varianter, der genererer kodeord, som består af eksempelvis fire tilfældige ord eller kombinerer tilfældige vrøvlestavelser til kodeord som 'akaytiobu'.
Disse er mindre sikre end et helt tilfældigt kodeord, men kan kombineres med overvågning af loginforsøg for at højne sikkerheden.
Overvågningen kan så bruges til eksempelvis at indsætte en forsinkelse mellem loginforsøg efter et antal fejlslagne forsøg.
En udbredt praksis er stadig at låse brugeren ude efter tre fejlslagne forsøg. Det er imidlertid en praksis, som kan føre til, at både supporten og brugeren skal bruge tid på at nulstille kodeord.
At låse brugeren ude efter blot tre forsøg er unødvendigt i forhold til eksempelvis at gøre det efter 10 forsøg, hvor brugeren har haft bedre chancer for på egen hånd at finde frem til, hvad brugeren taster forkert.
Opbevar kodeordene sikkert
De store overskrifter om millioner af knækkede kodeord kommer alle fra de tilfælde, hvor hackere har fået adgang til password-filen eller en database med kodeordene.
Kodeordene bør altid lagres som en hashværdi, og her lyder anbefalingen, at man anvender standardimplementeringer af anerkendte algoritmer. Det kan eksempelvis være bcrypt eller PBKDF2.
Mange af disse hash-funktioner giver mulighed for at anvende et 'salt', der er en ekstra tekststreng, som føjes til kodeordet, inden det sendes gennem hash-funktionen. Her bør man benytte et unikt salt til hver brugers kodeord, anfører professor og krypteringsekspert Ivan Damgaard, Aarhus Universitet.
»Hvis man får fat i filen med hashede passwords, kan man gennemprøve en række sandsynlige passwords, hashe dem alle sammen, og se om man får et match med det, der er i filen,« skriver Ivan Damgaard i en e-mail til Version2.
Ved at tilføje et unikt salt for hver bruger, så skal en hacker starte forfra for hvert kodeord i stedet for blot at kunne begynde fra en ende af og gætte alle kodeord i én gennemkørsel.
Visse hash-algoritmer som eksempelvis MD5 og SHA1 anvendes stadig til eksempelvis tjek af filer, der overføres i storagesystemer, men det er algoritmer, hvor det er muligt med en enkelt kraftig arbejdsstation udstyret med flere grafikkort at gennemløbe over en milliard kodeord pr. sekund.
Derfor bør man anvende nyere algoritmer, hvor hvert gennemløb tager længere tid og ikke kan deles op i parallelle udregninger. Sådanne algoritmer bruges som standard i platforme som eksempelvis PHP, og man bør altid anvende disse implementeringer fremfor ældre eller hjemmestrikkede hashfunktioner.

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.