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

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.

Det forekommer mig at eksemplerne alle er med ekstremt dårlige kodeord. Hvorfor skal vi som brugere kunne kende forskellige klasser af dårlige kodeord, når vi bare kan lære at lave gode kodeord?

Allerede nu benyttes fingeraftryk og biometrisk scanningssoftware til smartphones og lign. Alle personer har et unikt mønster i deres blodkar i øjnene som nutidens smartphones allerede er gode nok til at aflæse.

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

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.

Er det ikke ligegyldigt hvor mange gæt der skal bruges hvis kodeordet bliver gættet. Det er jo ikke en person der sidder og taster ind.

Biometri er ikke egnet som password, men kun som identifikation.

Og det er ikke en identifikation, man bør give ud til højre og venstre, for den kan ikke ændres.

Kan biometriske "passwords"/"keys" hashes eller tilsvarende beskyttes i dag?

Det har været en udfordring tidligere, fordi der ikke behøvede være et 100% match mellem det i databasen og det brugeren sender ind.

Vi tager den lige én gang til: https://xkcd.com/936/

Fremragende! Jeg har nu ændret alle mine passwords til correcthorsebatterystaple.

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

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.

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.

Du gætter ikke imod et weblogin men imod et leak af den bagvedliggende database. Der har du uendeligt antal muligheder.

Lige en kommentar til fingeraftryk, da jeg for nogen siden satte glasvæv op på en nyopsat skillevæg, blev mine fingerspidser så slidte at de ikke virkede til at låse min telefon op i 4-5 dage ...

Dernæst kunne man jo også få en rift i fingeren eller lignende, så det med fingeraftryk bør være et supplement.

Tak, Kristian. Det gav mening! :)

Er det ikke ligegyldigt hvor mange gæt der skal bruges

Eeh nej? Der er ingen reel forskel på om det er en computer eller et menneske der taster ind. Computeren kan bare gøre det hurtigere og derfor kræves der større kompleksitet/mulige valide gæt for at sikre at en computer ikke kommer frem til den korrekte løsning indenfor overskuelig fremtid.

Min egen ide til et stærkt kodeord er at bruge de to første bogstaver fra hvert ord i en sætning.

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

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¢

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.