Et populært udsagn i visse sikkerhedskredse er, at spørgsmålet ikke er, om man bliver hacket, men hvornår man bliver hacket. Set i det lys kan det være en god idé at forberede sig på datalæk for eksempel af brugerkonti i CMS'et.
En ikke uvæsentlig parameter i sådan et tilfælde er, hvordan brugernes kodeord er opbevarede. Som en del Version2-læsere vil vide, så skal kodeord helst ikke ligge i klartekst, men i et eller andet krypteret format.
På den måde undgår man, at en hacker uden videre får adgang til brugeres kodeord, som måske også giver adgang til andre webtjenester, da kodeord ofte bliver genbrugt. På samme vis beskytter kryptering af kodeord også umiddelbart mod, at personer internt misbruger deres adgang til en database til at nappe folks login-oplysninger. En hash-funktion er en funktion, der kan bruges til at mappe vilkårlige datastørrelser til data med en fast størrelse. Værdierne, som en hash-funktion returnerer, refereres blandt andet til som hash-værdier eller digests. Hash-funktioner bruges ofte i data-strukturer kaldet en hash-tabel til hurtigt at slå data op med. Kryptografiske hash-funktioner gør det på den ene side nemt at verificere, hvorvidt input-data - eksempelvis et kodeord - optræder i form af en given hash-værdi, og samtidig er kryptografiske hash-funktioner i udgangspunktet skruet bevidst sammen, så det er svært at gendanne det oprindelige input alene med kendskab til hash-værdien. Kilde: blandt andet WikipediaHash-funktion
Så langt så godt. Der er mange forskellige måder at kryptere kodeord på, så de ikke fremstår i klartekst. Men en del af dem er ikke særligt brugbare, hvis der sker et datalæk.
Et eksempel på sidstenævnte er den kryptografiske hash-funktion MD5. Funktionen er usikker - blandt andet fordi det er muligt bevidst at lave kollisioner, hvor hash-værdien fra et input matcher værdien fra et andet input. Sådan skal det ikke være.
Derudover er MD5 hurtig for en moderne CPU at køre. Det betyder også, at det er hurtigt for en hacker at brute-force kodeord kørt gennem MD5, eksempelvis via GPU'en i et grafikkort, der kan lave flere tusinde samtidige beregninger.
Husk lige saltet
Her tænker nogen måske, 'hvad med saltet?'
Et salt er en værdi, der kombineres med et kodeord, inden begge dele suses gennem eksempelvis en kryptografisk hash-algoritme. Det er vigtigt at salte for på den måde er det ikke muligt regne en masse værdier ud på forhånd, for så bare at slå op i en tabel for at finde et kodeord.
Version2-blogger og ophavsmand til den nu forældede kodeords-krypterings-funktion MD5Crypt, som er noget andet end MD5.
Poul-Henning Kamp eksemplificerer i en mail, som vi af hensyn til læseligheden her gengiver i en tekstboks:
I forhold til brute-force, så er MD5 - med eller uden salt - bare ikke nogen god idé og har ikke været det i flere år. Det er simpelthen for hurtigt for en hacker at køre alle mulige tegn-kombinationer gennem algoritmen og ad den vej finde frem til kodeord.
Alligevel dukker der fra tid til anden datalæk op, hvor det viser sig, at kodeord har været lagret via MD5. Det var eksempelvis tilfældet i forhold til det store datalæk, som Yahoo fortalte om i december 2016.
I den forbindelse fremgik det ikke, om kodeordene var saltede eller ej, under alle omstændigheder er MD5 en dårlig idé.
Lækket menes godt nok at stamme fra et angreb i august 2013, men heller ikke dengang var et simpelt MD5-hash smart.
Flere sikkerhedsfolk har tidligere over for The Register udtrykt deres bestyrtelse over Yahoos kodeordslagring.
Bedre løsninger
Af Yahoos december-nyhed om lækket fremgik det også, at virksomheden omkring det tidspunkt, lækket fandt sted - altså i 2013 - var ved at opgradere til den noget sikrere BCrypt-lagring af kodeord.
BCrypt er mere sikker, fordi den kræver flere beregninger, og dermed er funktionen mere brute-force-resistent end hash-værdier skabt via simple og hurtige hash-algoritmer som MD5 eller de nyere SHA-1 og SHA-2. Hvad SHA-2 angår, så er der tale om en samling af hash-funktioner, hvor en af dem hedder SHA-256. Hvad denne funktion angår bemærker Poul-Henning Kamp:
»Hvis de bruger et godt stort tilfældigt salt, er SHA256 og derover i princippet OK, men det var bedre hvis de brugte Scrypt eller tilsvarende.«
Poul-Henning Kamp forklarer, at funktioner som hans egen md5crypt(), senere Niels Provos og David Mazières bcrypt() og senest Colin Percivals scrypt() hver især har gjort det langt dyrere målt i CPU-regnekraft at udføre brute force-angreb mod kodeord lagret krypteret.
»Ulempen er naturligvis, at dit system skal lave det samme tunge arbejde for hver evig eneste bruger, der logger ind,« skriver Poul-Henning Kamp.
Nogen vil måske her frygte, at deres webserver pludseligt bliver sendt til tælling af at stå og tygge CPU-tung kodeords-kryptering, måske endda som følge af et bevidst kodeords-DoS-angreb, men den eventuelle udfordring er der flere veje uden om.
Det kan eksempelvis gøres ved at anvende en Captcha, altså en 'jeg-er-et-menneske-og-ikke-en-robot-der-står-og-fyrer-kodeord-af'-funktion, inden der sendes et kodeord til serveren. Det fortæller dette indlæg 'Salted Password Hashing - Doing it Right' hos awareness-projektet Crackstation blandt andet mere om.
Det er desuden en god idé med Captcha-funktionalitet i forhold til at undgå brute force-angreb mod kodeord ad den vej, fortæller Poul-Henning Kamp, der har flere tips, hvad lige den del angår:
»Man bør også lægge forsinkelser ind, hvis der bliver givet forkert password mere end to gange fra samme client/IP/konto.«
Svage kodeord
Han peger dog også på, at selv en god krypterings-funktion kæmper forgæves mod svage kodeord.
Det kan eksempelvis være et kodeord, der uden videre kan findes i en ordbog eller ved at kombinere to ord i en ordbog.
Poul-Henning Kamp henviser til, at gængse brugere typisk har behov for kodeord til et hav af tjenester, og at brugerne i den forbindelse har en tendens til at vælge kodeord, der kan huskes, men som også kan knækkes.
Han fortæller, at han selv har et program, der genererer tilfældige kodeord af 'af en svær kaliber', som er gemt i en krypteret fil.
»Men de fleste almindelige mennesker ryster bare på hovedet og vælger passwordet "MisseTand", som ingen hash-funktion, saltet eller usaltet, kan beskytte mod angreb.«
Har man ikke lige evnerne til at kode sit eget program til at generere gode kodeord med, så kan en løsning være en af de udbredte programmer til den slags.
Et populært et af slagsen er LastPass, der fungerer som plugin i flere browsere, hvor det kan spytte lange kodeord ud med en mere eller mindre tilfældig tegn-sammensætning. Herefter husker Lastpass så til hvilke sites og brugernavne, de forskellige kodeord hører hjemme. Programmet kan desuden synkronisere logins på tværs af maskiner.
I forhold til den slags programmer generelt bemærker Poul-Henning Kamp, at han »har svært ved at se, hvorledes man skulle kunne stole på dem,« med henvisning til, at al kodeords-håndtering er lagt helt og holdent i hænderne på tredjepart, eksempelvis LastPass.
Vejledninger
I forhold til sikker opbevaring af kodeord, så har The Open Web Application Security Project (OWASP) udgivet en grundig og overskuelig guide kaldet ‘Password Storage Cheat Sheet,’ som flere sikkerhedsfolk har henvist Version2 til i forbindelse med research af emnet.
Her kan man blandt andet læse om, hvordan salts skal håndteres. Salts skal kort fortalt være kryptografisk tilfældige og oprettes hver gang et bruger-credential oprettes, så ikke noget med samme salt for alle brugere på sitet.
Derudover anbefaler OWASP alt efter situationen forskellige algoritmer til kryptering af kodeord. Organisationen fremhæver således PBKDF2, Scrypt, BCrypt og Argon2.
Om Argon2 skriver OWASP, at algoritmen bør være første valg, når den bliver tilgængelig i en stabil implementering.
Argon2 blev i 2015 udpeget som vinder af konkurrencen med det sigende navn Password Hashing Competition. Her var Poul-Henning Kamp en af dommerne.
Han erindrer i den forbindelse, at »det ret nedslående resultat var, at der ikke var ret meget, der kunne gøres væsentlig bedre end Scrypt.«
I forhold til Scrypt anbefaler OWAPS, at man bruger algoritmen til kodeords-kryptering, »where resisting any/all hardware accelerated attacks is necessary but support isn’t.«
...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.
