LinkedIn kodeord kan være lækket

Nå, men det er jo ikke så godt.
Godt man ikke bruger samme kodeord flere steder.

Mit netværk på linkedIn, min e-mail adresse med mere kan ikke være mange basseøre værd.

Info om job og uddannelse er selvfølgelig gode info til identitetstyveri, - men de fleste af oplysningerne er ikke særligt hemmelige alligevel.

Men klart, folk med samme password mange steder er udsat. Og der skal ikke meget mere til før identitetstyveri vil være oplagt for de der er inklinerede mod den slags nederdrægtigheder.

Well, det er heller ikke det smarteste i verden at bruge SHA1. Men det er jo nok heller ikke en ny beslutning.

http://www.php.net/manual/en/faq.passwords.php#faq.passwords.fasthash

Det er jo på en måde lidt skræmmende, at sådanne sider kan blive hacket (forudsat at det er rigtigt); jeg må jo nok erkende, at LinkedIn nok er en anelse bedre til sikkerhed end mig selv, så meget af det man laver står jo for skud - også selvom man tager højde for de mest gængse trusler.

Well, det er heller ikke det smarteste i verden at bruge SHA1 uden en ordentlig salt. Men det er jo nok heller ikke en ny beslutning.andy123 (#2)

FYP: SHA-1 er fin. :)

#0
Nu ved jeg godt at brugerbasen er fra 2000-og-tidligt. Men de kunne da have sikret noget så basalt som en salt i løbet af en arbejdsdag eller to.
Så kunne de selv bestemme om de ville have brugerne til at skifte kodeord (én enkelt gang) eller om de bare ville re-hashe..

Nu er det jo ikke første april, så hvis dette ikke er et hoax, virker det umådeligt uansvarligt af sådan en virksomhed.

Men det er trods alt bedre end cleartext... (Host*Sony*)

Jeg ser det ikke som nogen stor trussel, hvis nogen har en SHA1 hash af det password jeg har brugt til linkedin. Det password er stærkt nok til at de ikke kan brute force det.

Hvad jeg er mere bekymret for er at de ikke har noget bud på hvordan listen er lækket. Hvordan skulle jeg kunne føle mig sikker på at deres system ikke stadigvæk er kompromitteret? Så kunne det være nogen aflyttede både det gamle og det nye password, hvis jeg prøver på at ændre det.

Det er umuligt at vide om det er mest sikkert at ændre sit password med det samme, eller at vente til de har undersøgt systemet og bragt forholdene i orden. Vi har ganske enkelt ikke fået de nødvendige oplysninger til at foretage denne vurdering.

Har man brugt et svagt password, hvor en SHA1 værdi nu er lækket, så er det til gengæld en god idé at ændre det nu. Og har man brugt samme password til linkedin og andre sites, så bør man øjeblikkeligt ændre det password på alle de andre sites, hvor man har brugt det.

Er der nogen som ved hvor man finder listen, jeg vil da gerne se om SHA1 af mit password står på den?

det er heller ikke det smarteste i verden at bruge SHA1.andy123 (#2)

Selvom SHA1 nok ikke holder evigt, så er den mig bekendt ikke brudt endnu. Selv en MD5 hash af et password uden brug af nogen form for salt er der stadigvæk ingen, der har brudt mere effektivt end ved brute force.

Har man et stærkt password er der ingen grund til at bekymre sig om sites der gemmer en usaltet MD5 eller SHA1 hash.

Har man et ultrasvagt password er det ligegyldigt hvad sitet har gjort for at beskytte det, så kan det stadigvæk brydes.

Hvis man bruger et middelstærkt password (40-50 bits entropi), så har det til gengæld stor betydning hvordan det gemmes. En salt værdi gør i den sammenhæng en kæmpe forskel. Et password i den klasse er bedre beskyttet, hvis man bruger MD5 med salt end ved at bruge SHA1 uden salt.

Så kunne de selv bestemme om de ville have brugerne til at skifte kodeord (én enkelt gang) eller om de bare ville re-hashe.. ISCS (#3)

Er passwords gemt med en dårlig hash i første omgang, så kan de rehashes næste gang brugeren logger ind. Det kræver ikke at passwords skal ændres.

Hvad jeg savner er en mere sikker måde at håndtere passwords, hvor websitet aldrig ser passwordet. Jeg forestiller mig en løsning hvor password bruges som seed til en pseudotilfældigtalsgenerator, som så bruges til at generere et asymmetrisk nøglepar. Webserveren skal kun se den offentlige nøgle. Derudover skal en challenge-response protokol ved login verificiere at klienten har den hemmelige nøgle. Der kan evt. saltes med ved at inkludere tre andre værdier i seedet: hostnavn, brugernavn, og en kort bitstreng som serveren vælger.

Hvis et sådan system blev designet rigtigt, så ville et website aldrig kunne lække passwordet. Ulempen er at det vil kræve en revision af HTTP protokollen.

Er der nogen som ved hvor man finder listen, jeg vil da gerne se om SHA1 af mit password står på den?kasperd (#4)

I den oprindelig nyhed siger de at du kan tjekke det på http://www.leakedin.org/ (Update 3)

Hvad der står på siden og om den er pålidelig ved jeg ikke, da den lader til at være nede p.t.

#5 Lol, jeg checket lige 12345 og den er tydeligvis ikke cracket :D

Looks like your password was not leaked. Hooray!leakedin.org

Tilføjelse til #5 (kan ikke edit den):
Fik et kort glimt af leakedin.org.

Jeg ville nok ikke bruge den da det fungere sådan at man enten indtaster sit password (som SHA1 hashes via Javascript) eller en SHA1 hash af sit password og så tjekker de om passwordet står på listen. Virker ikke som en god måde at gøre det på...

Hvad der står på siden og om den er pålidelig ved jeg ikkeHekatombe (#5)

Ved hjælp af Google fandt jeg et screenshot. Og måden siden fungerer på er ikke pålidelig.

Man sender en SHA1 værdi til dem, og de svarer tilbage med om den står i listen eller ej. Det beviser intet. Til gengæld kan de opsamle en liste af SHA1 værdier.

Hvis de skulle gøre den slags troværdigt uden at offentliggøre hele listen, så kræver det lidt mere omtanke i hvordan man bruger kryptografi til det.

For det første skal jeg ikke fortælle dem den SHA1 værdi, som de skal bevise at de kender. De kan jo umuligt bevise at de kendte værdien inden jeg fortalte det.

En anden måde er at jeg hasher værdien igen med SHA1 eller en anden hash funktion og sender det. Nu kan de bevise at de kender værdien ved at svare med et input der hasher til den hashværdi jeg sendte.

Altså jeg kender mit password. De kender SHA1(password), for en lang række passwords, som måske inkluderer mit. De beregner SHA1(SHA1(password)) for alle på listen og sorterer en liste bestående af par af formen: SHA1(SHA1(password)),SHA1(password)

Jeg sender til dem SHA1(SHA1(password)), de slår op i deres sorterede liste, og hvis de finder det svarer de med SHA1(password).

Hvis de samtidigt vil vise noget om hvor mange de har, så kan de lave et hashtræ af alle værdierne og publicere roden af det hashtræ. Så kan de bevise at en værdi var i hashtræet ved at svare med hashen på den anden side af hver forgrening. Det er dog af begrænset brugbarhed da de uden videre kunne tilføje meningsløse hashværdier til træet og dermed få det til at se ud som om der er lækket flere hashværdier end i virkeligheden. Og hvis de vil lade som om der er færre, så kan de jo bare lade være med at inkludere dem alle.

Og den popupreklame senere stopper jeg hermed at tjekke newz.dk. Håber at vende tilbage en gang, men ikke før den forsvinder..

#4:
Det du beskriver er jo netop public-private-key-protokollen, som også anvendes mange steder, fx ved SSL. Alternativt kan du jo bruge OpenID. Her behøver du kun give udbyderen (Google i mit tilfælde) dit password, hvorefter du logger ind på andre tjenester via din Google-konto. Derved får de andre sites heller ikke dit password. Det er også muligt her på Newz.dk.

#9:
Mon ikke du bare skulle få fjernet dit malware - Newz.dk har ingen popupreklamer.

FYP: SHA-1 er fin. :)ISCS (#3)

Jeg kan godt lide, at han rent faktisk kommer med en link der beskriver at SHA1 og MD5 er ikke egnede til passwords, på grund at de er hurtige og kan nemt brute forces og du så påstår den er fint. Seems legit.

uden en ordentlig saltISCS (#3)

Er alle hash funktioner ikke usikre uden en salt (såfremt man har valgt en svag password)? Hvilken forskel gør det at man bruger rainbowtables til SHA1 eller SHA-512?

Mon ikke du bare skulle få fjernet dit malware - Newz.dk har ingen popupreklamer.kba (#10)

Fuldsides Microsoft popup reklame på newz?

"En russisk hacker har på et forum oplyst, at han har skaffet sig adgang til en liste på godt 6,5 millioner hashede kodeord, som han har gjort tilgængelig for alle."

Hmm, har Newz set dette? Eller er dette en forkert måde at skrive at en russisk hacker har "udgivet" en liste på 6.5 mio hashede kodeord? (men vi ikke aner om han har hashede kodeord på 150 mio brugere)

"eftersom ordet linkedin tit dukker op"
Nej, man kan ikke "reverse" et hash, men man kan gætte på en værdi som giver et bestemt hash. P.t. har man gættet på en masse ord som indeholder "linkedin" (som har vist sig at findes i hashed form), men derfor kan der jo sagtens være dobbelt så mange hashede værdier med "firma2" som vi ikke kender endnu.

#4: Både MD5 og SHA1 er (kryptografisk set) brudt. Og ingen af dem er designet til håndtering af passwords, så der er ingen undskyldning for at have brugt det (og især ingen undskyldning for ikke at havde saltet koderne!).

#5 Lol, jeg checket lige 12345 og den er tydeligvis ikke cracket :Dastor (#6)

Jeg prøvede også lige med 123456 og "password" - Begge to er på listen!

Hvordan ved vi at det ikke bare er 'hjemmelavede' passwords de har hashed og udgivet?

På Ingeniørens artikel om samme har flere forsøgt sig med ordbogsopslag i den zipfil de har hentet.

Og der er bl.a. ord som:
badedyr, badevand, ..., dagblade, dagbladet, damour, dadaist, dadel, daggert, ..., kattekilling, kattemad, katten, kattepine, ...

For mig at se ligner det mere at de har fundet diverse ordbøger og hashet dem og så påstået at det er lækkede kodeord fra LI

Fuck it, kan se det var det samme password som jeg havde brugt ved Sony, så det var måske også på tide at få det ændret.

Det du beskriver er jo netop public-private-key-protokollen, som også anvendes mange steder, fx ved SSL.kba (#10)

Med SSL er autentifikation af websitet obligatorisk, mens autentifikation af brugeren er valgfrit. Det jeg beskriver er en autentifikation af brugeren som skal kunne bruges uanset om serveren er autentificeret eller ej.

Det ville selvfølgelig være værd at undersøge om den autentifikation af brugeren, som man kan lave med SSL kunne foretages vha. password som jeg beskrev, men jeg tvivler. Desuden er der ikke mange sites som understøtter det.

Alternativt kan du jo bruge OpenID.kba (#10)

Så bringes der en tredjepart ind i billedet. Det system jeg beskrev ville opnå sikkerhed uden at involvere en tredjepart. Kunne en openid provider bygges direkte ind i en browser? Eller kræver det at sitet man logger på kan kontakte provideren?

Newz.dk har ingen popupreklamer.kba (#10)

Jeg er ligeglad med hvad du kalder det. Det som newz havde i går var i hvert fald noget

Er alle hash funktioner ikke usikre uden en salt (såfremt man har valgt en svag password)?Mr_Mo (#11)

Et svagt password er altid usikkert. Brugen af salt flytter lidt på grænsen for hvor stærkt et password behøver at være. Værdien afhænger af hvor målrettede angrebet er. Hvis angrebet ikke er målrettet hjælper salt nok sådan ca. svarende til fire ekstra tegn i passwordet.

Hvilken forskel gør det at man bruger rainbowtables til SHA1 eller SHA-512?Mr_Mo (#11)

Du skal bruge ca. 10 gange så mange computere til at lave rainbowtables til SHA512.

Sikkerheden af MD5 er brudt. Der kendes effektive metoder til at konstruere kollisioner for MD5. På trods af det kendes der endnu ikke til nogen svaghed i MD5, som udgør et problem for password hashing.

Skulle jeg lave et nyt system i dag ville jeg vælge SHA512. Men i praksis er forskellen på sikkerheden af MD5 og SHA512 mindre end forskellen på at bruge salt og ikke gøre det.

En enkelt iteration af MD5 med salt formoder jeg er mere sikker end 100 iterationer af SHA512 uden salt.

Jeg fandt frem til denne zip fil: http://www.tozz.nl/temp/combo_not.zip

Jeg kan bekræfte at den fil indeholder en SHA1 hash af det password jeg har brugt på linkedin og ingen andre steder.

For mig er det et definitivt bevis på at linkedin har haft et læk.

Der er 6458020 linier i filen. Hver linie er en 160 bits hexadecimal værdi. Men ikke alle sammen er SHA1 hashes af linkedin passwords.

Nogen har prøvet at sammenligne med ordbøger og fundet frem til at hvis de hasher ord fra ordbøger så finder de sådan ca. den værdi i tekstfilen. De første fem cifre af hashværdien er blevet udskiftet med nuller.

Jeg har selv verificeret et af eksemplerne. Og jeg fandt frem til at 3521180 af linierne i filen starter med fem nuller. Givet filens størrelse burde der kun have været ca. 6 linier der starter med fem nuller.

Hvis de fem nuller i starten stemmer overens med hvilke linier der er fra ordbøger, så betyder det at antallet af lækkede passwords kommer ned under tre millioner.

Vi ved stadigvæk ikke om de alle stammer fra linkedin eller om der er andre kilder. Og det er også muligt at hvem der end har konstrueret filen har udeladt nogle hashes som vedkommende havde fået fat i og måske har tilføjet andre værdier som er mere eller mindre tilfældigt genereret.

Rækkefølgen på linierne i filen følger et mærkeligt system. Måske kan den rækkefølge fortælle os noget mere, hvis man kan gennemskue systemet.

Såfremt andre har en fil og vil vide om de har fået fat i den samme er her sha1sum af filerne:

#5 Lol, jeg checket lige 12345 og den er tydeligvis ikke cracket :Dastor (#6)

Men det er 123456 - :P

Kloge åger, LinkedIn kræver at alle passwords er minimum 6 karakterer. Så sjovt nok er der ikke lækket nogle password på 5 eller derunder.... what a surprise.

Jeg fandt nogle linier med alt for mange nuller til at det kan være SHA1 hashes.

Her er resultatet da jeg undersøgte fordelingen af antal nuller per linie:

Statistisk set burde der være 2.5 nuller per linie. Så det er helt naturligt at frekvensen vokser indtil 2 og så aftager. Den vokser lidt igen når man når op omkring 7 nuller som følge af de 5 nuller i starten af halvdelen af linierne plus de 2.5 der statistisk set skulle være på linie. Derefter aftager frekvensen igen indtil den når fem styks med 17 nuller. Men så er der også fem linier med 29 eller flere nuller. Det er så usandsynligt at jeg med sikkerhed kan sige at de fem linier ikke er SHA1 hashes.

Hvis man kigger på alle linier i filen og fjerner de første fem tegn, så finder man 670781 dubletter. Der er ganske enkelt mange tilfælde hvor samme værdi findes hhv. i en komplet udgave og med de første 5 tegn erstattet af nuller.

Såfremt det ene eksemplar i en dublet er fra linkedin og det andet er fra ordbogen, så betyder det at 670781 personer har valgt passwords der var så svage at de nu er brudt.

Jeg fandt også nogle tilfælde af linier der ligner hinanden usandsynligt meget. Jeg har fundet tre par af værdier hvor de sidste 24 cifre af værdierne er identiske. Havde alle linierne været SHA1 hashes burde de have været tilfældigt fordelt. Med knap 7 millioner hashværdier er det ikke sandsynligt at se så ens værdier. Det burde man først se når man når op omkring 100 billioner hashværdier.

LinkedIn kræver at alle passwords er minimum 6 karakterer. Så sjovt nok er der ikke lækket nogle password på 5 eller derunder....MadiZone (#20)

Filen indeholder meget andet end lækkede passwords, så der kunne sagtens have været hashværdier af strenge på under 5 tegn deri.

Læste inde på Ekstrabladet(ved ikke om man må linke til artiklen??), at der var lavet en ny nyhed omkring det. og der bliver diskuteret lidt om siden LeakedIn.org hvor man kunne se om ens password var leaked... jeg har godt nok tastet koden, men vil i tro det vil være et problem, mere med at den så gemmer dine cookies fra tidliger login.steder? Har ikke selv forstand på sådan noget.
Forbes har også lavet en artikel omkring det

Læste inde på Ekstrabladet(ved ikke om man må linke til artiklen??), at der var lavet en ny nyhed omkring det. og der bliver diskuteret lidt om siden LeakedIn.org hvor man kunne se om ens password var leaked... jeg har godt nok tastet koden, men vil i tro det vil være et problem, mere med at den så gemmer dine cookies fra tidliger login.steder? Har ikke selv forstand på sådan noget.
Forbes har også lavet en artikel omkring detSTIVAN (#22)

SÅ længe du ændrede dit passsword inden du gav det gamle væk går det nok. :)

Du skal bruge ca. 10 gange så mange computere til at lave rainbowtables til SHA512.kasperd (#17)

Stadig, hvilken forskel gør det og slå op i rainbowtables for SHA1 vs SHA512? Vi snakker ikke om at lave dem først og derefter bruge dem.

Et svagt password er altid usikkert. Brugen af salt flytter lidt på grænsen for hvor stærkt et password behøver at være. Værdien afhænger af hvor målrettede angrebet er. Hvis angrebet ikke er målrettet hjælper salt nok sådan ca. svarende til fire ekstra tegn i passwordet.kasperd (#17)

Bruger man egentlig et nyt salt til hver password, eller det samme?

Stadig, hvilken forskel gør det og slå op i rainbowtables for SHA1 vs SHA512?Mr_Mo (#24)

Det tager også 10 gange så lang tid at slå op. Men det er jo et kompromis mellem hastighed og diskplads. Hvis du vælger at bruge 10 gange så meget diskplads i stedet for, så kan du nok slå op lige så hurtigt. Eller du kunne bruge ca. 3 gange så meget displads på SHA512 og så ville det kun blive ca. 3 gange så langsomt.

Men det ville kun kræve fire bits salt at opnå samme effekt som man opnår ved at skifte fra SHA1 til SHA512.

Bruger man egentlig et nyt salt til hver password, eller det samme?Mr_Mo (#24)

Det normale er at bruge nyt salt til hvert eneste password. Jeg har hørt at nogle systemer kun bruger brugernavnet som salt. At bruge brugernavn som salt er ikke lige så sikkert som at bruge en tilfældig værdi, men det er stadig langt bedre end slet ikke at bruge salt.

Lettere relateret har jeg hørt at kryptering af WIFI bruger SSID som salt (sådan ca.), og det er derfor det er bedre for sikkerheden at vælge et tilfældigt navn.

Fnis. En eller anden bruger "tissemand" som kodeord. :)

Jeg kan godt lide, at han rent faktisk kommer med en link der beskriver at SHA1 og MD5 er ikke egnede til passwords, på grund at de er hurtige og kan nemt brute forces og du så påstår den er fint. Seems legit. Mr_Mo (#11)

Han kommer med et link der beskriver at hashes skal bruges sammen med salts, eller laves på andre finurlige måder der øger computational expense.

Jeg tilføjer bare at det ikke siger noget om hvorvidt det er klogt eller dumt at bruge SHA-1 eller MD5. Men at det siger noget om at det er dumt at bruge hashes, uden forbehold.

En eller anden bruger "tissemand" som kodeordDrHouseDK (#26)

Hvis den hypotese jeg fremsatte i #21 er korrekt, så er det ikke tilfældet. Filen indeholder tilsyneladende både en ordbog og kodeord fra linkedin. Det du fandt var i ordbogen men ikke blandt kodeordene fra linkedin.

Jeg tilføjer bare at det ikke siger noget om hvorvidt det er klogt eller dumt at bruge SHA-1 eller MD5. Men at det siger noget om at det er dumt at bruge hashes, uden forbehold.ISCS (#27)

Hvis man i dag designer et nyt system, der har brug for en kryptografisk hashfunktion, så er det dumt at vælge MD5. Men der er andre aspekter som er vigtigere end valget af hashfunktion. Ved verifikation af passwords er performance af hashfunktionen ikke vigtig og det er blandt andet derfor jeg tidligere sagde:

Skulle jeg lave et nyt system i dag ville jeg vælge SHA512.kasperd (#17)

Har man passwords gemt med MD5 bør de ændres til noget stærkere ved førstkommende lejlighed, der er ingen grund til hastværk. Har man passwords gemt uden salt bør man til gengæld gå i gang med at rette op på det øjeblikkeligt.

Man kan behøver faktisk ikke engang vente på at brugerne kommer forbi og indtaster deres passwords før man begynder at tilføje salt. Man kan anvende et midlertidigt format til overgangen. Hvis man f.eks. i dag gemmer SHA1(password), så kan man skifte til at gemme tre oplysninger: format, salt, hash. Til det midlertidige format kunne man så anvende SHA512(salt || SHA1(password)) og til et mere permanent format kunne man anvende SHA512(salt || password).

Han kommer med et link der beskriver at hashes skal bruges sammen med salts eller laves på andre finurlige måder der øger computational expense.ISCS (#27)

Hvor ser du ordet salt?

Why are common hashing functions such as md5() and sha1() unsuitable for passwords?
Hashing algorithms such as MD5, SHA1 and SHA256 are designed to be very fast and efficient. With modern techniques and computer equipment, it has become trivial to "brute force" the output of these algorithms, in order to determine the original input.

Because of how quickly a modern computer can "reverse" these hashing algorithms, many security professionals strongly suggest against their use for password hashing.

Han kommer med en link der beskriver hvorfor md5 og sha1 er uegnet til kodeord. Prøv at læse det stedet for at antage noget.

finurlige måder der øger computational expenseISCS (#27)

Men det øger jo netop ikke computational expense, salt beskytter mod rainbowtables, ikke bruteforce. De separerer salt og computational expense i artiklen og beskriver computational expense:

When hashing passwords, the two most important considerations are the computational expense, and the salt. The more computationally expensive the hashing algorithm, the longer it will take to brute force its output.

Jeg tilføjer bare at det ikke siger noget om hvorvidt det er klogt eller dumt at bruge SHA-1 eller MD5. Men at det siger noget om at det er dumt at bruge hashes, uden forbehold.ISCS (#27)

Nej, du ændrer det til at SHA1 er egnet til kodeord, modsat anbefalingen fra artiklen som modsiger dig.

Men det øger jo netop ikke computational expense, salt beskytter mod rainbowtables, ikke bruteforce.Mr_Mo (#29)

Jo salt beskytter imod brute force angreb. Rainbowtables kræver enormt tunge beregninger på forhånd, men kan til gengæld hurtigt bryde de strenge man har været igennem da man konstruerede sine tabeller.

Har man en specifik samling hashværdier man ønsker at bryde er der ingen pointe i at lave rainbowtables. Man beregner bare hashværdier af de passwords man ønsker at afprøve og søger efter hvert beregnet hashværdi i en sorteret udgave af den liste af hashværdier man ønsker at bryde. Ganske simpelt brute force angreb som kan forhindres ved brug af salt.

#30
Du snakker om at afprøve på forhånd definerede kodeord, som fx i en ordbog, ikke? Altså en dictionary attack...

For øger salt computational expense? Hvis den ikke gør, så beskytter den ikke mod en klassisk brute force angreb hvor samtlige kodeord bliver systematisk afprøvet indtil en der passer findes. Du må gerne komme med en link der understøtter din påstand. Jeg er ingen ekspert i kryptologi, så jeg baserer det på #2's link og det du siger, stemmer ikke helt overens med #2...

Har man en specifik samling hashværdier man ønsker at bryde er der ingen pointe i at lave rainbowtables. kasperd (#30)

Som du selv siger:

Rainbowtables kræver enormt tunge beregninger på forhånd,

Hvis man har dem rainbowtables på forhånd, hvorfor så gå i gang med at bruteforce? Er det ikke lidt dumt? Hvorfor bruge så mange kræfter og plads på at lave og lagre dem?

Why Not {MD5, SHA1, SHA256, SHA512, SHA-3, etc}?

These are all general purpose hash functions, designed to calculate a digest of huge amounts of data in as short a time as possible. This means that they are fantastic for ensuring the integrity of data and utterly rubbish for storing passwords.

A modern server can calculate the MD5 hash of about 330MB every second. If your users have passwords which are lowercase, alphanumeric, and 6 characters long, you can try every single possible password of that size in around 40 seconds.

And that’s without investing anything.

If you’re willing to spend about 2,000 USD and a week or two picking up CUDA, you can put together your own little supercomputer cluster which will let you try around 700,000,000 passwords a second. And that rate you’ll be cracking those passwords at the rate of more than one per second.

Salts Will Not Help You

It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database.

Salt or no, if you’re using a general-purpose hash function designed for speed you’re well and truly effed.Kilde

Uenig?

Du snakker om at afprøve på forhånd definerede kodeord, som fx i en ordbog, ikke? Altså en dictionary attack...Mr_Mo (#31)

Man kan ikke trække en klar linje mellem brute force og dictionary attack. Det er mere et spørgsmål om hvilken rækkefølge man afprøver mulighederne i. Der er metoder som bruger både en ordbog og manipulationer på ordbogen samt kombinerer med alle strenge af en given længde. Det drejer sig om at afprøve passwords i en rækkefølge startende med de mest sandsynlige. Når man vælger et password gælder det om at være så langt nede på listen som muligt.

For øger salt computational expense? Hvis den ikke gør, så beskytter den ikke mod en klassisk brute force angreb hvor samtlige kodeord bliver systematisk afprøvet indtil en der passer findes.Mr_Mo (#31)

Forskellen er at hvis der er salt skal du gøre dette for passwords enkeltvis. Når ikke der er salt kan du for en ganske beskeden pris undersøge det ord du er i gang med imod alle brugere på én gang. Det vil sige at hvis der er 6 millioner brugere, så vil salt sløve angrebet ned med en faktor på 6 millioner.

Hvis man har dem rainbowtables på forhånd, hvorfor så gå i gang med at bruteforce? Er det ikke lidt dumt?Mr_Mo (#31)

Det er et spørgsmål om hvorvidt du har de rainbowtables på forhånd. Hvis ikke du har dem, så er det i hvert fald komplet spild at gå i gang med at lave dem, hvis målet er at bryde en helt konkret liste af hashes.

Om det kan betale sig at bruge rainbowtables som du allerede har konstrueret afhænger af antallet af hashes, størrelsen af ordbogen og de kompromiser du valgte da du konstruerede rainbowtables.

Hvis det drejer sig om at bryde et lille antal hashværdier, så er prægenererede rainbowtables en effektiv metode. Men arbejdet per hashværdi er langt større ved brug af rainbowtables.

Efterhånden som listen af hashværdier bliver lang falder værdien af en rainbowtable. På et tidspunkt bliver det simpelthen billigere at ignorere dine rainbowtables og i stedet løbe din ordbog igennem igen.

Hvorfor bruge så mange kræfter og plads på at lave og lagre dem?Mr_Mo (#31)

Pointen er at de beregninger kan du begynde på før du har de lækkede hashværdier. Det er praktisk til mere målrettede angreb. Hvis du f.eks. har brugt en måned på at lave rainbowtables kan du når hashværdier er lækket i løbet af få minutter bryde hashværdierne til de 20 mest interessante logins, hvis du ellers har dækket dem med din rainbowtable.

Men hvis du aldrig har lavet en rainbowtable og først starter på at bryde passwords når du har de lækkede hashes, så er det hurtigere at blot udføre et konventionelt angreb.

Forskellen er at hvis der er salt skal du gøre dette for passwords enkeltvis. Når ikke der er salt kan du for en ganske beskeden pris undersøge det ord du er i gang med imod alle brugere på én gang. Det vil sige at hvis der er 6 millioner brugere, så vil salt sløve angrebet ned med en faktor på 6 millioner.kasperd (#33)

Ah, så det sløver angrebet på den måde. Nu er jeg med :)

Uenig?Mr_Mo (#32)

Fuldstændigt.

A modern server can calculate the MD5 hash of about 330MB every second. If your users have passwords which are lowercase, alphanumeric, and 6 characters long, you can try every single possible password of that size in around 40 seconds.Kilde

Den udregning er så en faktor 10 ved siden af. MD5 har en blokstørrelse på 64 bytes. Det vil sgie at 330MB per sekund betyder 5406720 blokke i sekundet.

Med 36 mulige tegn og passwords der er 6 tegn lange er der 36^6 mulige passwords. Det vil sige 2176782336 passwords. Hvert password kræver en enkelt MD5 blok, altså er der tale om 5406720 passwords i sekundet.

Hvis vi dividerer de to tal med hinanden får vi 402 sekunder.

Jeg gætter på at manden ikke ved hvordan MD5 virker og har antaget at et password hvis længde kun er en tiendedel af længden på en MD5 blok kan hashes på en tiendedel af den tid det tager at hashe en MD5 blok. Sådan virker hashfunktioner ikke.

It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database.Kilde

Han antager at hashværdier lækkes enkeltvis. Sådan hænger det bare ikke sammen i praksis. Når hashværdierne lækkes, så lækkes som regel oplysninger om et meget stort antal brugere samtidigt.

Basically, it’s slow as hell. It uses a variant of the Blowfish encryption algorithm’s keying schedule, and introduces a work factor, which allows you to determine how expensive the hash function will be.Kilde

Jeg tror på at blowfish er et udmærket valg, hvis man har brug for en blokcipher med en blokstørrelse på 64 bits. Men den har næppe været udsat for samme grad af kryptoanalyse som alle de hashfunktioner der nævnes. Derudover er der tale om at bruge keyschedule derfra til en anvendelse den ikke var tiltænkt, og ligefrem bruge en modificeret version.

Sikkerheden af den konstruktion har intet at gøre med sikkerheden af den oprindelige blowfish kryptering. Der er tale om et nyt kryptografisk primitiv, som ikke har været udsat for samme grad af review som de hashfunktioner han fraråder.

At anbefale et obskurt kryptografisk primitv fremfor anerkendte hashfunktioner kan jeg ikke tage seriøst.

Og så er der lige det problem med beregningsoverheadet. Den faktor som introduceres er den samme for både legitim brug og for angreb. Det er ikke den rigtige vej at gå. Det øger beregningsoverhead for servere som bruger systemet og gør dem sårbare overfor DoS angreb.

I den konkrete sag kunne salt have gjort brute force af hashværdierne 6000000 gange langsommere. Skulle man have opnået samme effekt ved at gøre hashfunktionen langsommere villle det have været et stort problem for serveren. Jeg testede lige SHA1 performance på en af mine computere og kom frem til 112MB/s på en enkelt CPU core det svarer til 1835008 passwords i sekundet. Ønsker man at sløve det ned med en faktor 6000000 ved at gøre beregningen langsommere betyder det at den skal gøres så langsom at serveren skal bruge ca. 3 CPU sekunder på at verificere hver brugers password.

Det vil sige at under normale omstændigheder kommer brugeren til at vente 3 sekunder på at logge ind. Men det vil kun kræve 5 requests i sekundet at udføre et DoS angreb imod en 16-core server med tilsvarende hastighed per core.

Det er simpelthen urealistisk at opnå samme sikkerhed uden brug af salt fordi man enten har passwords der er for hurtige at bryde eller er for langsomme at verificere for serveren.

Nogen har stillet det interessante spørgsmål om hvorvidt man kan offloade noget af en beregning af den slags til klienten vha. javascript. Det ville være en interessant fremgangsmåde. Det vil være besværligt at gøre sikkert, men der er potentiale i idéen.

Indtil nogle kryptologer har undersøgt det er mine råd: Brug en anerkendt hashfunktion. Brug et tilpas stort salt. Og iterer evt. hashfunktionen et par gange. Iterering har i den sammenhæng ikke til formål at gøre hashfunktionen langsommere, men derimod at gøre den mere sikker. Hashfunktioner er ganske rigtigt designet efter at være hurtigere, og derfor er antallet af runder sat til det laveste hvor man stadigvæk stoler på at de er tilpas sikre. Til passwords er hastigheden af hashfunktionen ikke helt så vigtig, og derfor ville det have givet mening med lidt flere runder. Man opnår lidt af det samme sikkerhed ved at iterere den.

Nogen har stillet det interessante spørgsmål om hvorvidt man kan offloade noget af en beregning af den slags til klienten vha. javascript.kasperd (#35)

Jeg har en idé til en løsning. Jeg ved blot ikke hvad der findes af kryptografiske funktioner i standard javascript. At implementere dem selv i javascript er problematisk fordi det betyder at legitim brug kommer til at bruge en fortolket version hvorimod angreb naturligvis bruger optimeret native kode. For ikke at give angriberne en fordel har jeg altså brug for noget som javascript gør native.

Til gengæld har den del af mit design der foregår i javascript ikke særligt store krav til sikkerheden af de kryptografiske primitiver. Med andre ord ville MD5 eller SHA1 som native funktioner i javascript være rigeligt til min idé. De udregninger jeg har brug for at få lavet med stærkere funktioner som f.eks. SHA512 foregår på serversiden.

Nogen har stillet det interessante spørgsmål om hvorvidt man kan offloade noget af en beregning af den slags til klienten vha. javascript.kasperd (#35)

Proof of concept