MD5, SHA-1 eller Scrypt: Er dine brugeres kodeord (forsvarligt) krypteret?

Der er mange måder at opbevare kodeord på, og en del af dem er uforsvarlige i tilfælde af datalæk.

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.

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:

Fidusen ved saltning er, at selvom Alice og Bob begge har passwordet "12345", så bliver Alices hashede password til:
 
        "120934243234" + hash("120934243234" + "12345")
 
Mens bobs hashede password bliver til:
 
        "989486945684" + hash("989486945684" + "12345")
 
På den måde kan man ikke bare lave en database ("rainbowtable") af krypterede passwords: Man bliver nødt til at brute-force hver enkelt brugers password.

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.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Følg forløbet

Kommentarer (40)

Jason Chinedu

Nu er det selvfølgelig svært at vide hvad der præcist menes med "den slags programmer", men tilliden kan vel øges ved at bruge gennemlæst open-source og vælge programmer der ikke ligger det ud i skyen?

Uden at bede folk om at sætte ord på præcist hvilken løsning de benytter, hvad karakteriserer så jeres løsninger?

Kim Aarnfup

@Casper Olsen

V2 artiklerne handler om data-at-rest.

Krypterede hashes i bruger-databaser, som stjæles og crackes.

Troy Hunts tweet om Berlingske handler om data-in-motion.

Man opsnapper Berlingske password-hashes fra UUUUUkrypteret http-traffik (mitm-attack) og replayer hashet.

Tænk pass-the-hash, hvor du ikke behøver at kende password eller cracke det for at logge ind på Berlingske

KH
Kimse a.k.a. Danmarks bedste hacker :-)

Esben Bjerre

Der er flere danske virksomheder der på ingen måde tager denne type sikkerhed seriøst.
Har set flere eksempler på brugen af både MD5, rå klartekst og base64 (som lige så godt kunne være klartekst) i databaser.

Claus Andersen

Jeg skulle lige læse det sidste afsnit 3 gange:

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.«

Den gav først mening efter jeg læste OWASP Password Storage Cheat Sheet og så linien før:

PBKDF2 when FIPS certification or enterprise support on many platforms is required

Dvs. scrypt er foretrukken hvis den er understøttet på din platform (altså platform support). Har man ikke scrypt, så vil PBKDF2 være acceptabelt.

Det er også værd at nævne at scrypt er lige så nem at bruge som md5 eller egne hjemmestrikkede funktioner, så der er ikke så mange undskyldninger.

Thomas Jensen

Et godt password skal være nemt at huske for brugeren. MisseTand er således bedre end jH74Re3£u [, hvis resultatet er at det sidste skrives ned på papirlapper eller opbevares hos tredjepart.

Personligt opbygger jeg mine password på en måde så de er nemme at huske, og samtidig er unikke i forhold til det sted jeg bruger dem. Det kunne være (men er det ikke):

"Misse + site + Tand", altså fx MisseNetflixTand eller MisseVersion2Tand.

Det kan udbygges med forskellige regler, fx. indsættelse af specialtegn osv. Hovedsagen er at man vælger noget der er nemt at huske, og man med få og enkle regler gør det unikt, og at man ender med et laaaaaangt password.

Kristian Rastrup

Drop det med at huske passwords.
Det er direkte i modstrid med hjernens kognitive evner.
Brug unikke passwords gemt i en password manager og slå 2-faktor autentifikation til hvor det er muligt.
For computer illiterate folk som ens gamle mor virker en notesbog fint som password manager, så længe den bliver liggende på skrivebordet ved siden af computeren. Trusselbilledet om at nogen bryder ind hos hende for at stjæle bogen så de har adgang til hendes gmail er meget lille.

Thomas Jensen

Brug unikke passwords gemt i en password manager

Enten uploader du dine password til en tredjepart, så du kan dele dem på tværs af enheder, eller også har du ikke adgang til dem fra alle dine enheder. Begge dele synes jeg er uhensigtsmæssigt.

og slå 2-faktor autentifikation til hvor det er muligt.

Det er selvfølgelig en god løsning, de steder det er vigtigt nok. Men det er jo ikke noget der højner brugervenligheden.

Beklager, jeg kan ikke se problemet. Et (halv-)langt password, bygget op af ting der er nemme at huske, som er gjort unikt i forhold til der hvor det bruges, og som kan rummes i hovedet, er altså en langt bedre løsning end noget man ikke selv kan huske.

Kristian Rastrup

Enten uploader du dine password til en tredjepart, så du kan dele dem på tværs af enheder, eller også har du ikke adgang til dem fra alle dine enheder. Begge dele synes jeg er uhensigtsmæssigt.

Hvis dit primære trusselsbillede er NSA, så sandt. Hvis dit primære trusselsbillede er site breaches hos 3. part så nej. Hvis site a bliver breachet og dit kodeord knækket pga. svag kryptering, kan man regne mønstret ud nemt.

Det er selvfølgelig en god løsning, de steder det er vigtigt nok. Men det er jo ikke noget der højner brugervenligheden.

At skrive en kode hver gang man logger ind på en ny enhed er til at leve med og forstå. Folk er vandt til NemId. Og det er den ting der højner din sikkerhed mest.

Poul-Henning Kamp Blogger

Det er også værd at nævne at scrypt er lige så nem at bruge som md5 eller egne hjemmestrikkede funktioner, så der er ikke så mange undskyldninger.

Frem for alt er scrypt designet og skrevet af Colin Percival, der gentagne gange har gjort sig meget positivt bemærket ved at være en af de bedste til at oversætte kryptografisk teori til kode man kan bruge til noget.

(Jeg kan også varmt anbefale hans "tarsnap" backupservice.)

Poul-Henning Kamp Blogger
Henning Wangerin

Et godt password skal være nemt at huske for brugeren. MisseTand er således bedre end jH74Re3£u [, hvis resultatet er at det sidste skrives ned på papirlapper eller opbevares hos tredjepart.

Med mindre jH74Re3£u bygger på en algoritme som gør brugeren i stand til at huske den.

Jeg plejer at bruge eksemplet "I1kssk,adn" som er yderst nemt at huske hvis man ved hvordan.

De fleste kender sikkert begyndelsen på denne sang "I en kælder sort som kul, aldre dybest nede".

Find din egen tekst som du kan huske, og som måske endda har en eller anden forbindelse til sitet, så har du en huskbar kode der er lidt sværere at knække.

Thomas Jensen

Det vil formodentlig tage omkring 3 minuter længere at brute-force et sådant password, end blot "MisseTand".

Indrømmet, det er ikke noget stærkt password... Men hvad med

42Oligakkens...jordbærformede_[]Lampeskærm

(måske med lidt flere specialtegn)

som bliver til

42Oligakkens...Version2Jordbærformede_Danmark[]Lampeskærm

eller

42Oligakkens...AmazonJordbærformede_Amerika[]Lampeskærm

Nemt at huske, når man har brugt det et par gange, og nemt at lave nye passwords, som er lette at huske.

Thomas Jensen

Genbrug af passwords er roden til hele problematikken sådan at breach af site a giver login til site b.

Jeg argumenterer ikke for genbrug af passwords. Jeg argumenterer for passwords der er så nemme at huske (for dig) at du ikke har brug for passwordmanagers.

Meningen er at man netop ikke skal genbruge sine passwords, fordi det er svært at huske en masse forskellige, men at man skal gøre dem forskellige, men på en systematisk måde, så man kan huske dem.

Brian Vraamark

I artiklen står der flere steder at man skal kryptere sit kodeord. Man krypter ikke adgangskoder. En kryptering er en reversibel handling, det er hashing ikke.

En anden ting er PBKDF2 (samt scrypt o.l.). Dette er ikke en hash funktion i sig selv. Det er en "Key stretching" metode som benytter en hash funktion i en løkke for at gøre udregningen langsommere (beskyttelse mod brute force).
I OpenSSL implementeringen, angives hash funktionen (message digest function) som en parameter. Det kunne i teorien godt være MD5 (ikke en god ide). Ofte er PBKDF2 implementeret med SHA1, men da denne ikke længere betragtes som sikker, bør SHA-256 benyttes istedet for. Vær opmærksom på dette, hvis du hente koden til en PBKDF2 implementering fundet på nettet.

Husk at antallet af anbefalede iterationer brugt i PBKDF2 ændre sig hvert år (hvilket er et problem i sig selv, da du jo har en database med gamle adgangskoder der ikke kan "opgraderes"). Personligt synes jeg at alt under 10.000 ikke bør anvendes.

Jonas Høgh

Meningen er at man netop ikke skal genbruge sine passwords, fordi det er svært at huske en masse forskellige, men at man skal gøre dem forskellige, men på en systematisk måde, så man kan huske dem.

Det er meget fint at sætte sine passwords til MisseVersion2Tand og MisseGmailTand i stedet for MisseTand begge steder, men hvis nogen løber med Version2s password database og cracker den, hvad skal så forhindre dem i at lave s/Version2/Gmail/g på resultaterne, hvis de får lyst til at se om passwords kan bruges hos Gmail?

Kim Aarenfup

@ Thomas Jensen - Sikke noget bavl. Hvis du kender lidt til hybrid cracking og masks i hashcat eller "johnnyboy"

Fra et statistisk synspunkt (som hybrid og bruteforce cracking handler om) gør dine råd at udfaldrummet falder fra fantasillioner, der ikke kan brutefoces til milliarder, der kan crackes.

Entropy is king! Selv "random" passwords du taster ind via keyboard er ikke random. Har du valgt tast "X" er det mere sandsynligt du vælger tast "Y" end tast "Z" fordi din hjerne er vant til at skrive nogle bogstavkombinationer mere end andre. Samt den fysiske placing på keyboard.

Det er også mere sandsynligt at du starter et password med et kapitaliseret bogstav. Fordi du er vant til at starte en sætning med et kapitaliseret bogstav.

Alle disse sandsynligheder er indarbejdet i mange moderne custom bruteforce-scripts. Helt ned på sprogområde og keyboardtype. F.eks. qwerty hos linkedin og phone keyboards som T9 hos instagram - Kan du regne ud hvorfor?

Thomas Jensen

hvad skal så forhindre dem i at lave s/Version2/Gmail/g på resultaterne, hvis de får lyst til at se om passwords kan bruges hos Gmail?

Men de skal først lige laves til klartekst, før du kan køre regex!

Hvis man følger nogle af de råd vi har fået gennem tiden, dvs. laver passwords med både store og små bogstaver, tal og specialtegn OG laver nogle rimeligt lange passwords OG disse passwords bliver opbevaret nogenlunde forsvarligt, dvs. hashed og salted, så burde det ikke være trivielt at lave dem til klartekst.

Hvis du oveni tilføjer nogle ekstra tegn - fx. 'Version2' eller 'Amazon' - så forstærker du dit password ved at gøre det længere.

Ebbe Hansen

sæt ikke 2 men 3 Bussemænd under Tastaturet

Hvis man insisterer på selv at huske sine adgangskoder, så er vrøvlesætninger ikke helt af vejen.
I perioder har jeg det med blot at skrue på (an)tallet. Og i vore dage vrøvler jeg nok lidt længere

Poul-Henning Kamp Blogger

Hvis man følger nogle af de råd vi har fået gennem tiden, dvs. laver passwords med både store og små bogstaver, tal og specialtegn OG laver nogle rimeligt lange passwords OG disse passwords bliver opbevaret nogenlunde forsvarligt, dvs. hashed og salted, så burde det ikke være trivielt at lave dem til klartekst.

Tilfældige passwords der bruger de ca. 70 "safe" tegn og som er screenet af en kompetent person for indlysende svagheder ("kokkenkomfarende"), skal som et absolut minimum være 10 tegn lange for en blot nogenlunde troværdig brute-force resistens (>2**60)

Hvis det er et menneske der vælger passwordet, skal det uanset hvem det er og uanset hvilket "system" der bliver brugt, være mindst 20 tegn langt som ikke kan være et citat med indlysende substitutioner.

Dermed er vi gået fra 'rimelig lange' til 'urimeligt lange' passwords.

Thomas Jensen

Dermed er vi gået fra 'rimelig lange' til 'urimeligt lange' passwords.

Jo, men fx. 10 tilfældige tegn kan føles langt, hvor 20 tegn der er lette at huske kan føles okay i hverdagen. Og min pointe er, at hvis man kan få folk til at bruge 20 tegn, så er det bedre, selvom entropien ikke er helt så høj som i et 100% tilfældigt password. Og hvis man oveni tilføjer 'Version2' (eller noget mindre oplagt) så opnår du både at man ikke genbruger passwords og at man forstærker det, ved at tilføre ekstra tegn.

Med mindre man vil gøre som dig og opbevare sine højkvalitets-passwords selv i en krypteret fil, og selv stå for at holde den opdateret på sine forskellige enheder, så er man nød til enten at have passwords man kan huske eller bruge en passwordmanager. Jeg er tilhænger af det første.

Kim Aarenfup

@Peter

Om du bruger 20 tegn eller 500 tegn er lidt ligegyldigt, hvis der er korrelation mellem dine passwords.

Det her er ikke religion eller politik, hvor en mening er ligeså valid som en anden og kan vindes via retorik.

Problemet er, at du udtaler dig om noget du mangler basisindsigt i at vurdere.

Hvis jeg tager fejl, så skitser din arbejdgang efter du har database-dumpet.

Hvilke metoder starter du med. Hvilke statistiske modeller bruger du? Eller svar mig på et simpelt spørgsmål - ved hvilken temperatur sætter din GPU-type ud?

Kimse: LinkedIn 93.2% (cont), Yahoo 87.6% (cont), Adultfriend 89.7% (cont)
vs.
Peter: Crackede skærmen på sin Doro, da han tabte den i Bilka.

Kim Aarenfup

Det var @ Thomas. Min hjerne er hardwired til at debat med Peter. Det kan misbruges til phising mod mig. Eller til at svare på spørgsmålet om min barndomsven, hvis i ikke kan cracke mine passwords. Lolz

Dave Pencroof

Vil det være særligt brugbart at benytte æøå på udenlandske sites ?
De er jo ikke en del af specialtegn sættene ?

BTW så er der virkeligt mange sites der ikke tillader at man bruger specialtegn, og ligeledes mange der har nogen markante begrænsninger på antallet af tilladte tegn, jeg er stødt på sider der ikke tillader mere end 10 tegn i adgangskoden OG ingen specialtegn, oven i det er der MANGE sites der INGEN regler har eller IKKE skriver hvilke regler de har, og så famler man jo i blinde, Apple er en af de få der er helt klare i spyttet med deres adgangskode krav !
Der er dog INTET site der kræver at man regelmæssigt ændre sit/sine adgangskoder, hvilket dog er aldeles nødvendigt når vi kikker på mængden af adgangskoder og brugernavne div sites verden over er blevet lænset for over de seneste år, men det hænger vel sammen med at, hvis vi stiller krav til vores kunder så kunne de måske finde på at smutte !
Og så er vi tilbage på absolut laveste fællesnævner !

Kristian Rastrup
Thomas Jensen

Problemet er, at du udtaler dig om noget du mangler basisindsigt i at vurdere.

Jeg må med skam give dig ret!

http://security.stackexchange.com/questions/62832/is-the-oft-cited-xkcd-...

Jeg har aldrig påstået jeg var sikkerhedsekspert, men omvendt synes jeg heller ikke jeg har levet under en sten de sidste 5 år, så jeg er noget forundret over at jeg ikke har hørt denne kritik før.

Og det irriterer mig grænseløst! Jeg synes det er virkelig trist, at det bedste råd ikke er at kunne sit password i hovedet. Jeg synes password managers er en virkelig dårlig løsning, fordi det ikke er specielt brugervenligt, og fordi det involverer tredjepart.

Et eller sted vil jeg dog gerne fastholde min pointe. Alt andet lige må et langt password, som man kan huske, være bedre end et kort, som er svært at huske, hvis man som 90% af befolkningen ikke bruger en password manager.

Måske er det bedste råd at bruge password managers, men hvis man ikke kan få folk til det, så er det næstbedste råd måske - som jeg foreslog - at lave lange passwords, som man kan huske.

Flemming Hansen

Jeg er ikke så teknisk vidende omkring kryptering.
Som jeg kan læse det ud af artiklen så ligger en del af svagheden i MD5 at det er relativt hurtigt at lave brute force på, men har mange websites ikke netop en begrænsning på hvor ofte man kan forsøge at logge ind, så brute force ikke fungerer i praksis?

Morten Friberg
Mikal Schacht Jensen

Enten uploader du dine password til en tredjepart, så du kan dele dem på tværs af enheder, eller også har du ikke adgang til dem fra alle dine enheder. Begge dele synes jeg er uhensigtsmæssigt.

Du kan jo vælge en password manager hvor du bestemmer hvordan du deler den tilhørende (stærkt krypterede) password fil. Enten på en filservice (dropbox, g-drive, osv.) du stoler på, eller på din egen server. Ulempen er selvfølgelig at du skal have to "master passwords". Et til at autorisere din password manager app på dele-servicen, og et til den krypterede fil.

Beklager, jeg kan ikke se problemet. Et (halv-)langt password, bygget op af ting der er nemme at huske, som er gjort unikt i forhold til der hvor det bruges, og som kan rummes i hovedet, er altså en langt bedre løsning end noget man ikke selv kan huske.


Problemet er, at lige så snart du skal huske koder selv, er du nødt til at lægge nogle regler eller mønstre på. Og de begrænser potentielle gyldige koder fra et nært uendeligt antal, til nogle få millioner muligheder. En potentiel hacker, skal blot gennemskue mønstret, så bliver det trivielt at knække koderne. Og som et menneske blandt milliarder af mennesker, er de password-mønstre du kan finde på, slet ikke så unikke som du tror.

Når der sker et kæmpe læk af bruger konti fra en eller anden services. Så er det 12345, og p4ssw0rd folket der for knækket deres koder først. Derefter er det jer der er sikre på, at i har fundet "Den ultimative måde at hitte på sikre koder der er nemme at huske". Og så gives der som regel op på dem der har 100% unikke, 100% tilfældige koder på 40 tegn. Fordi der har skurkene allerede høstet rigeligt med brugernavn/kodeord-sæt til at det har været udgifterne og besværet værd.

Så jo, en lang "skør" kode man kan huske er da bedre end en man ikke kan huske. Men du bedrager dig selv hvis du mener det er sikkert at huske dine koder selv. En password manager er, uden sammenligning, den sikreste model.

Morten Brørup

I nogle systemer er man nødt til at kunne genskabe brugerens password, fx når man bruger RADIUS WPA2-Enterprise med EAP-PEAP-MSCHAPv2 til at logge på fx et trådløst netværk.

Her handler det så om at benytte industristandarder!

Det gør vi selvfølgelig også selv: Vores egenudviklede RADIUS med UNI•Login-løsning, hvormed skoleelever kan logge på skolens wifi med deres UNI•Login, opbevarer elevernes (og lærernes) passwords krypteret med AES-256-CBC, hvor vi benytter en 256 bit nøgle (der naturligvis er fast, men blev produceret som en kryptografisk tilfældig værdi) og salter hvert enkelt password med en unik 128 bit initialiseringsvektor, der ved hver eneste passwordændring bliver produceret som en ny kryptografisk tilfældig værdi.

Og den faste nøgle ligger naturligvis ikke sammen med password-databasen, så hvis SQL-serveren skulle blive kompromitteret, kan man ikke bare finde nøglen i en anden tabel eller lignende.

NB: Ironisk nok er der p.t. certifikatfejl på STILs website, men linket er altså godt nok.

mvh
Morten Brørup
CTO, SmartShare Systems

Log ind eller opret en konto for at skrive kommentarer

Partnernyheder

Welcome to a seminar on tools that help you become GDPR compliant!

Getting GDPR compliant by May 2018 implies a lot of activities covering the legal aspects, internal business processes, data management, and security technology.
28. feb 2017

Maja Rosendahl Larsen ansat hos Affecto

24. jan 2017

Introduction to Jedox – Affecto Seminar, Copenhagen

12. jan 2017