Forskere: Brugeres idé om et stærkt kodeord er ofte i hegnet

Illustration: leowolfert/Bigstock
Web-brugere kan ikke nødvendigvis genkende et stærkt kodeord, selvom det stirrer dem i ansigtet, viser amerikanske forskere.

Det nytter ikke meget, at brugerne vil have stærke kodeord, hvis ikke de ved, hvad der gør kodeordet stærkt. Og det gør de langtfra altid, viser et studie fra Carnegie Mellon University.

Et forsøg præsenterede 165 respondenter for 25 kodeord-par, hvorefter testpersonen skulle vurdere den relative sikkerhed i kodeordene.

Læs også: Kompliceret og usammenhængende password-politik? Så synes dine brugere nok, du er idiot

Respondenterne vurderede blandt andet, at koden ieatkale88 er omtrent lige så sikker som iloveyou88. Men ifølge forskerholdets beregninger vil det tage fire milliarder flere gæt at knække førstnævnte kode, fordi iloveyou er en ekstremt tærsket tekststreng i kodeordsammenhænge.

Ligeledes mente respondenterne, at p@ssw0rd var mere sikker end pAsswOrd, selvom sidstnævnte ifølge forskerne kræver 4.000 flere gæt.

Læs også: Sikkerhedssoftware udstiller medarbejderes svage kodeord med falske phishing-mails

»Selvom deltagerne generelt havde en god forståelse af, hvad der gør et kodeord stærkt eller svagt, så havde de også nogle kritiske misforståelser om, hvordan kodeord angriber, og de antog ukorrekt, at deres kodeord kun skulle modstå et lille antal gæt,« forklarer Blase Ur, der er ph.d-studerende ved Carnegie Mellons datalogistudium.

Forskerholdet håber, at viden om brugernes misforståede idé om kodesikkerhed kan forbedre værktøjer, der vejleder om styrken af kodeord. Holdet vil selv indarbejde resultaterne i et open source-værktøj, der giver feedback på kodeord og skal udgives i år.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Benny Jensen

Internettet er bare ikke sikkert. Sådan er det bare og det kan vi ikke lave om på.

Men problemet her er nok at brugerne har fået ind med modermælken at passwords skal opbygge bestemt for at være "sikker".
Jeg ser problemet som værende en fejl begået af os som udviklere.

Måske skulle vi vende sikkerhed helt på hovedet og starte helt forfra,med nogle nye ideer?

Jeg foreslår at vi starter med at fjerne matematik fra sikkerhed. Det vil da i det mindste tvinge os udviklere til at tænke alternativt.

Finn Thøgersen

Biometri har sine helt egne problemer, fx:
- du kan reelt ikke skifte "password" hvis det kompromiteres (du har kun 2 øjne, 10 fingre osv)
- biometriske data har det med at sprede sig overalt hvor du færdes, så hvis nogen VIL have dine fingeraftryk, gangart, ansigtsform, stemme osv er det ikke særligt svært.
Øjne er sværere, men med en tilpas telelinse, eller en skimmer på et sted hvor du bruger det...
- Biometriske kendetegn ændrer sig over tid og ved forskellige påvirkninger (temperatur, lokal irritation, aktivitet, div stimulanter og medicin osv), så der arbejdes med en meget stor margin.
Det betyder at der formodentligt vil være fx 1000 mennesker her i landet der kan åbne din iPhone fordi de tilfældigvis har et kompatibelt hash af deres fingeraftryk (tallet er hevet fra et vist sted, men konceptet holder).
- Når først du har data (fingeraftryk osv) er det overkommeligt snyde sensorerne, det kan kræve nogle eksperimenter første gang, men...

Biometri er sammenligneligt med et simpelt password, det er enkelt at gå til og er nok til at holde tilfældige fremmede, naborns unger osv ude, men hvis de professionelle virkeligt vil ind, så...

Niels Buus

Når man forlanger af sin bruger at vedkommende skal vælge et såkaldt sikkert password, så virker det som om man har ringe forståelse af sikkerhed og blot går med strømmen.

Den normale tilgang til password sikkerhed er at man skal gøre passwordet så kompliceret/langt at det kræver ufattelig mange forsøg at gætte. Formodningen er derfor at en angriber vil opgive, fordi mængden af resourcer som skal bruges for at gætte passwordet ikke står mål med gevinsten.

Den alternative tilgang, som bl.a. er standard i Ruby on Rails, er at man skal gøre et gæt så tilpas kompliceret at foretage, at selv enkle og korte passwords tager ufattelig mange resourcer at gætte.

Så i stedet for at vælge en hashing algoritme som MD5 eller SHA, hvor en almindelig computer kan lave millioner af forsøg i sekundet, så bruger Rails et bibliotek der hedder Bcrypt.

Bcrypt er designet til at være langsomt. Og det er designet til at være lige så langsomt som den applikation som bruger Bcrypt ønsker det - det styres med en såkaldt kostfaktor som lader hashing-tiden stige eksponentielt. Så kan du selv styre om passwordet må tage 5 millisekunder eller 5 sekunder at beregne.

Ved at sikre at det tager f.eks. et halvt sekund at beregne et password hash på din server, så gør du at legitime brugere kan logge ind og få deres sessionscookie på acceptabel tid - det er ikke så vigtigt om login-operationen tager 50 ms eller 550 ms.

Men den lange beregningstid på dine hashes gør at din webserver er meget svær at bruteforce, da hvert loginforsøg vil tage et halvt sekund.

Det gør også at en databasetyv vil have meget svært ved at angribe dine brugeres passwords, da det vil tage flere dage bare at prøve alle kombinationer med 4 tegn.

Bcrypt er endda så snedigt designet at det udstiller et API som lader dig øge kompleksiteten i takt med at hardwaren bliver hurtigere. Dermed kan du øge din kostfaktor (fordi din/angriberens hardware er blevet hurtigere) og så vil Bcrypt gør det nemt for dig at erstatte de relativt svage hashes med nye og dyrere hashes, i takt med at brugerne logger ind igen.

Det er både mere sikkert og langt mere brugervenligt end at kræve specialtegn og store bogstaver ad libitum.

Torben Mogensen Blogger

At det ene skulle kræve flere gæt end det andet må skyldes algoritmen. I begge tilfælde er enkelte bogstaver i et almindeligt ord substitueret med oplagte substitutioner. At @ skulle være mere oplagt end A som substitution for a og ditto for 0/O for o, kan jeg ikke se. Det må skyldes, at algoritmen prøver substitutionerne i ASCII-orden og ikke efter, hvor oplagte, de er.

Martin Hoffmann

Jeg har tænkt dette mange gange, men ikke turde spørge, men nu må jeg udstille min uvidenhed.

Har de fleste loginrequesters ikke en funktion der disabler kontoen (permanent eller midlertidigt) ved tre eller fem forkerte gæt?
Jeg mener, hvis jeg glemte mit eget Windows password, så ville det tage mig ret lang tid at forsøge med 4000 yderligere kombinationer for at finde den afart af ordet "Password" jeg havde brugt, for jeg ville skulle have fat i Helpdesk efter hvert femte forsøg for at lukke kontoen op igen.

Det er naturligvis ikke et argument for ikke at lave gode passwords, men jeg kan bare ikke forstå (rent teknisk) hvorfor det netop i denne sammenhæng overhovedet er et problem.

Kristian Rastrup

At det ene skulle kræve flere gæt end det andet må skyldes algoritmen. I begge tilfælde er enkelte bogstaver i et almindeligt ord substitueret med oplagte substitutioner. At @ skulle være mere oplagt end A som substitution for a og ditto for 0/O for o, kan jeg ikke se. Det må skyldes, at algoritmen prøver substitutionerne i ASCII-orden og ikke efter, hvor oplagte, de er.

Jeg gætter på at a->@ og o->0 (og nok også l ->1) er normale substitutter når man bliver tvunget til at bruge cifre og specialtegn.
Hvis man skal tjekke for store bogstaver er det lidt mere komplekst for så skal man tjekke både PassworD, pASSword, pAsswOrd mv.
Endnu et naivt gæt er at de fleste passwords er skrevet med små bogstaver i så høj grad det er muligt plus et eventuelt stort begyndelsesbogstav (som i egennavne) baseret på det er det nemmeste for brugeren både at taste og huske og så og det er algoritmen opdateret efter.

Jesper Mørch

F.eks. bliver "jeg plukker frugter med en brugt frugtplukker" til "JePlFrMeEnBrFr".


Du kan også udvide dit princip lidt, og vende store-små til små-store afhængig af ord-klassen. Hvis f.eks. tillægsord og navneord havde omvendt størrelse i bogstav-rækkefølgen, ville ovenstående password blive til:

"JePlfRMeEnbRfR" vs. "JePlFrMeEnBrFr"

På den måde ville hvert andet bogstav ikke nødvendigvis være hhv. stort og lille, men blandet "tilfældigt" mellem store og små bogstaver.

Just my 2¢

Jesper Kjær

Det ville måske synd at kalde det dovne software udviklere, men måske nærmere uvidende. "Key stretching", som konceptet hedder, er en gammel ide, men den løser ikke alt. Hvis man fx kører mod en database med de 100.000 mest brugt passwords og bruger et halvt sekund på hver, tager det 13 timer at teste alle muligheder. Det er overskueligt.
Derudover ja, key stretching bør være den obligatoriske teknik for password hashing, i stedet for bare at køre mod en simpel SHA256 eller det der er værre.

Log ind eller Opret konto for at kommentere
Brugerundersøgelse Version2
maximize minimize