Bjarne78

 

Du påstår at det man med grei forbrukerhardware genererer 1k passordhasher per sekund. Vanlige servere har ikke gpu, så her snakker vi i såfall om kanskje 1k passordhasher per time gitt samme kriteriet?. For å dra unna vanlig trafikk for 22k brukerinnlogginger må du da ha rundt 20 servere (åpner for max 20 innlogginger per dag per bruker), mens for å ta høyde for misbruk, noe man alltid gjør, trenger man da 2 fotballbaner med servere. Når du påstår at det går så tregt å cracke passord vil ikke metoden være forsvarlig å bruke i praksis. Derfor er tallene dine kun teoretiske og dermed også ganske så uinteressante. Skal en hashalgoritme være forsvarlig å bruke til autentisering bør minst 10% av alle brukerne kunne logge seg inn hvert minutt med hardwaren du har tilrådighet mener jeg.

 

 

Hvor mange nettsider i verden tror du har 22k innlogginger per time?

Husk at de aller fleste benytter funksjonalitet som husker brukere, og således ikke trenger å sjekke hashen/passordet med mindre brukeren sletter visse data eller logger inn fra en ny enhet.

 

Hvor mange av disse nettsidene som har såpass mange innlogginger tror du kjører på en gammel webserver i kjelleren hos eieren?

 

Dersom en hash tar ett sekund å generere på en server, så er det betydelig tid som gjør det langt vanskeligere å brute force, enn for eksempel MD5 som kan genereres på noen få millisekunder, selv om det går raskere å generere hashen på en GPU.

Selv et halvt sekund er betydelig tidsforbruk i den sammenhengen, faktisk er 0.1 sekund også betydelig, uten at det er særlig relevant.

 

Det skulle vel være unødvendig å opplyse om at det er 3600 sekunder i en time, og en hver nettside som har såpass mange unike nye innlogginger per time, hvor cookies eller andre metoder som husker brukeren ikke benyttes, kjører neppe på en enkelt server.

 

Ta med multithreading og Xeon prosessorer på 12 kjerner og oppover, som brukes på nye servere i dag, så er det nok neppe noe problem med algoritmer som bruker litt tid på generere hasher, og man trenger heller ikke fotballbaner med servere, med mindre man er Google eller Facebook. De aller fleste nettsider har ikke en gang i nærheten av 22k brukere totalt.

Så nå tar du plutselig forbehold om at din anbefalte algoritme ikke kan brukes på alle tjenester? Hvorfor er den da anbefalt? Hvorfor tror du at en nettside som ikke har i nærheten av 22k brukere burde designe løsningen sin slik at tjenesten deres vil gå ned når de passerer 22k brukere?

Vi har opp mot 5000 innlogginger per minutt peak på dagtid. Jeg anser det som lite. Hva tror du Microsoft har? Tror du at de har dedikerte fotballbaner til hashgenerering for innlogging?

 

Hvis du ønsker å sette opp en nettjeneste som krever 2 fotballbaner med servere for å dra unna innloggingsforsøk fra én iphone med 4g er du velkommen til å gjøre det, men det er liten sannsynlighet for at noen andre hadde gjort det.

 Jeg tok den ikke helt?Det at man benytter mange runder med PBKDF2 gjøres for at det skal ta litt tid å knekke hvert passord, i størrelsesorden et sekund eller noe slikt per hash på en helt vanlig server.Hvorfor dette skulle kreve fotballbaner med servere vet ikke jeg? Innloggingsforsøk har jeg ikke en gang nevnt, å har ikke noe med dette gjøre i det hele tatt, det håndterer man på andre måter, med IP logging eller lignende og begrenset antall forsøk? 

Selvsagt har saltet noe å si. Så lenge du har forskjellig salt per bruker. Hvis du gir meg en liste med 1 000 000 hasher som ikke er saltet tar det akkurat like mye tid å bruteforce dem alle som å bruteforce den vanskeligste.

Den tok jeg heller ikke, saltet er jo kjent å lagres normalt i databasen sammen hashen.Har man fått tilgang til hashen, så har man generelt sett også saltet, det er ikke derfor man salter hashen, det er for å unngå at det er enkelt å benytte tabeller med kjente hasher og passord.Det vil jo heller ikke ta like lang tid å brute force alle, som det tar å brute force den enkleste, eller sagt på en annen måte, den første du treffer på i itereringen? 

Du hasher alt, og sammenligner det med ALLE hashene. Om det er 1000 eller en milliard passord har ikke så mye å si. Bortsett fra at i et stort sett vil du ha mange treff fort. Men hvis du klarer 1000 oppslag, så trenger du ikke 1000 ganger antall hasher. La oss si alle passordene var blandt disse første 1000 oppslagene. Om det er en milligard passord eller et spiller ingen rolle. Du bruker et sekund uansett. Skjønner ikke hvorfor du tror man må hashe flere ganger dersom det er flere hasher man sammenligner med, det er helt ulogisk.

Hæ? Jeg forstår ikke helt hva du mener?La oss si at du har noen rammer å jobbe innenfor, for eksempel et minimum av tegn passordet må inneholde, du vet at det må være ett tall og minst en stor bokstav, og du vet omtrent hvilket tegnsett som er tillat.Du starter da med strenger som matcher dette, å generer hasher av de strengene.Dersom hashen er saltet, så har du allerede saltet for hver hash, slik at dette kan du enkelt legge til strengen før den hashes, det spiller altså ingen rolle her for tiden det tar å knekke hashene.Si du klarer å generere tusen hasher i sekundet, eller for den saks skyld en million, så er det jo ikke gratis å sammenligne med en hash, den operasjonen tar også noe tid, og skal man laste inn en liste med 22 000 passord som er hashet, som hver genererte hash skal sjekkes mot, ja så tar det lengre tid, faktisk 22 000 ganger lengre tid enn sammenligningen mot en enkelt hash.Nå kan man anta at det tar lengre tid å generere en hash, enn å sammenligne hasher, slik at normalt er det tidsbesparende å sammenligne med alle 22 000 hasher for hvert genererte hash, men det tar altså fremdeles tid, og antall hasher man kan generere per sekund faller drastisk når hver hash skal sammenlignes mot 22 000 andre hasher før neste genereres osv, det sier seg vel selv?

Du påstår at det man med grei forbrukerhardware genererer 1k passordhasher per sekund. Vanlige servere har ikke gpu, så her snakker vi i såfall om kanskje 1k passordhasher per time gitt samme kriteriet?. For å dra unna vanlig trafikk for 22k brukerinnlogginger må du da ha rundt 20 servere (åpner for max 20 innlogginger per dag per bruker), mens for å ta høyde for misbruk, noe man alltid gjør, trenger man da 2 fotballbaner med servere. Når du påstår at det går så tregt å cracke passord vil ikke metoden være forsvarlig å bruke i praksis. Derfor er tallene dine kun teoretiske og dermed også ganske så uinteressante. Skal en hashalgoritme være forsvarlig å bruke til autentisering bør minst 10% av alle brukerne kunne logge seg inn hvert minutt med hardwaren du har tilrådighet mener jeg.

 

For oss som sitter med hardware fra dette årtusenet må du nok gange opp antall ops/sec med en million:)

 

 

Det kommer an på algoritmen som benyttes og hva slags hardware det er snakk om.

 

Dette er dog vanskelig å regne på, men generelt sett benyttes SSE2, som utvider instruksjonssettet for x86, og som er det samme som benyttes for bilder og video, altså noe skjermkortet ofte er optimalisert for.

 

Det relevante da, vil være å se på gigaflops, og mens en Intel I7 prosessor kommer opp i svimlende 50 GFLOPS, så kan enkelte skjermkort klare 1500-2000 GFLOPS.

 

Med andre ord, en CPU klarer ikke særlig mange iterasjoner, mens skjermkortet generelt sett klarer langt flere.

Har man også flere skjermkort, så kan man selvfølgelig gange opp enda mer.

 

Så er det slik at det er enorme forskjeller når det kommer til skjermkort og denne typen arbeid, noe for eksempel bitcoinmiljøet har oppdaget, hvor enkelte skjermkort er langt raskere enn andre, det finnes en liste, samt at Wikipedia har liste over skjermkort og GFLOPS

 

Antar man at de fleste sitter med en helt vanlig maskin, med et skjermkort som klarer et par hundre gigaflops, og en gigaflops er en milliard flops, så kan man gjøre et par hundre milliarder instruksjoner opp mot GPU'en i sekundet.

 

Så blir jo spørsmålet hvor mange instruksjoner (flops) hver algoritme krever, for en algoritme krever jo også datakraft for å utføres, samt hvor mange ganger algoritmen skal kjøres..

 

Algoritmer som PBKDF2 har jo mulighet til at man selv setter antall iterasjoner algoritmen skal kjøres.

For noen år siden var det for eksempel vanlig med noen få tusen iterasjoner, mens i dag, grunnet ny hardware og raskere maskiner, så benyttes langt flere iterasjoner, nettopp for å unngå at det er enkelt å brute force hashene. Man legger altså til "mer tid".

 

I 2012 anbefalte man 64k iterasjoner, og en dobling annethvert år, slik at noen hundre tusen runder med PBKDF2 algoritmen bør nok benyttes for å sikre seg.

 

Så er det jo flaskehalser i bussen, PCI, ingenting som kjører maks gigafops over tid osv.

Regner man dette sammen, kommer man neppe opp i noe særlig mer enn 1000 ops/sec på en riktig utført PBKDF2 og et standard skjermkort.

Hvis du ønsker å sette opp en nettjeneste som krever 2 fotballbaner med servere for å dra unna innloggingsforsøk fra én iphone med 4g er du velkommen til å gjøre det, men det er liten sannsynlighet for at noen andre hadde gjort det.

 

Dette gjelder kun hvis det er saltet.

 

Hvis det ikke er saltet tar det jo bare 4891 sekunder, hvis man kun klarer 1000 iterasjoner per sekund, noe som er latterlig lavt for mange av hashene som brukes i dag.

 

Saltet har i utgangspunktet ingen betydning for tiden det tar å brute force hashene, og anses ikke en gang som hemmelig, det lagres gjerne sammen med hashen.

 

Saltet er der primært for å unngå tabelloppslag, slik som regnbuetabeller.

 

Når hemmelig.com ble lekker prøvde jeg å cracke passordene, det tok ikke lang tid med bruteforce før de begynte å dukke opp. Og da hadde jeg ikke engang brukt passordreglene deres for å begrense entropien.

 

 

Hemmelig dott com benyttet kun MD5 hashing, noe som gjør at regnbuetabeller kan benyttes.

 

MD5 er også en rask algoritme. På en maskin som kanskje kun klarer 1000 ops/sec med en treg algoritme som PBKDF2, så kan man oppnå 15-20 000 ops/sec med MD5, noe som gjør det mye raskere å knekke passordene.

 

Med regnbuetabeller ble 24 289 av de totalt 24 559 hashene som lekket fra Hemmelig cracket i løpet av noen få timer.

For oss som sitter med hardware fra dette årtusenet må du nok gange opp antall ops/sec med en million:)

 

Du setter fortsatt forutsetninger som ikke stemmer med virkeligheten. Folk bruker ungen sin eller kona si som passord, fødselsdatoen og 123. Det finnes ikke i nærheten av 208 milliarder passordvarianter på disse brukerne.

 

Det er korrekt, men med mindre alle brukere har benyttet konas navn som passord, å du vet dette, så hjelper det jo veldig lite.

 

Dersom du skal brute force de passordene, så vet du sannsynligvis kun hvilke krav prisjakt stiller til passord, å må jobbe innenfor de rammene, for eksempel minimum 8 tegn, små og store bokstaver, spesielle tegn osv.

 

Med mindre du vet hvordan du skal begrense antallet muligheter ytterligere, så må du jo kjøre gjennom alle kombinasjoner med det tegnsettet som benyttes.

 

Du kan selvfølgelig ta en sjanse å forsøke en liste med kvinnenavn opp mot et par millioner hasher, å satse på at noen treffer, men sannsynligheten for det er nok mindre enn du tror.

 

Det er pussig at man tror dette er så enkelt at man kan finne hundrevis av passord på noen minutter.

Det er en grunn til at hashing og salting med en adekvat algoritme anses som relativt trygt, det tar så lang tid å finne passordene at det anses som lite hensiktsmessig.

Hvis vi tar kvinnenavneksempelet med alle kvinnenavn som det finnes mer enn 200 av i Norge samt alle fødselsdager under 67 år vil det ta ca 5,5 dager å cracke alle 22000 passord med ett av de sterkere mest brukte hashene og salt med ok hardware. Kjøper en skytjenester til dette kan det ta et par minutter.

Hver gang et større selskap er hacket ser jeg en økning av sikkerhetsbrudd 3-12 måneder etterpå mot andre tjenester. Man trenger ikke være rakettforsker for å skjønne hvorfor.

 

Det er ikke helt korrekt. Gitt at ingen passord er like klarer man langt flere på den tiden.

Man tar jo ikke for seg et og et passord, men prøver hashen på alle man har.

 

 

Det spiller jo egentlig liten rolle, utover at det vil ta særdeles lang tid å sjekke en generert hash opp mot en liste bestående av millioner av passord.

 

Du vil selvfølgelig finne de passordene som krever minst antall iterasjoner først, men du må samtidig iterere noen millioner ganger ekstra for hver hash.

 

 

Og ekstremt mange bruker ett enkelt ord som passord etterfulgt av 123, så entropien er ekstremt lav i mange tilfeller.

 

 

Entropi i ren brute force består i utgangspunktet av antall tegn i passordet opphøyet i antall tegn i tegnsettet, og et slikt angrep har ingen anelse hvor enkelt et passord er å gjette.

 

Selv om passord er "password" så vil det ikke være noe enklere å gjette med brute force, da måtte man i så fall hatt passordlister, eventuelt ordlister for å redusere antallet muligheter osv.

 

 

Du setter fortsatt forutsetninger som ikke stemmer med virkeligheten. Folk bruker ungen sin eller kona si som passord, fødselsdatoen og 123. Det finnes ikke i nærheten av 208 milliarder passordvarianter på disse brukerne.

 

Jeg tør påstå at minst 500 av passordene fra prisjakt kan crackes i løpet av 24 timer med vanlig tilgjengelig forbrukerhardware uansett hashalgoritme de bruker:)

 

 

Slikt går det jo an å regne på.

 

Dersom man benytter en vanlig PC med en vanlig prosessor så tar det evigheter, men ved å bruke skjermkortets GPU kan man gjøre dette raskere, for eksempel med Hashcat.

 

En vanlig PC med et forholdsvis vanlig skjermkort som kjører Hashcat klarer et par tusen kombinasjoner i sekundet.

Dersom man har valgt et passord med 8 tegn, og vi regner med kun små bokstaver, altså 26 tegn, så får vi 26⁸, som er 208 827 064 576 iterasjoner.

 

La oss si at en median ligger midt i , og det tar rundt 100 000 000 000 forsøk for å finne hvert passord, så blir det 50 000 000 sekunder, og det er 86 400 sekunder i en dag, slik at det vil ta deg rund seks hundre dager, eller rundt regnet to år å knekke ett eneste passord. Legger du til store bokstaver, tall og diverse andre tegn, slik at du har et tegnsett på rundt 260 i stedet, så blir det 260⁸, som blir 20 882 706 457 600 000 000 iterasjoner, så kan du jo regne ut hvor mange tiår det tar?

 

Selv om enkelte av brukerne har benyttet ord, og du kjører ordbøker mot passordene, vil det ta deg måneder og år å finne noen få passord som er hashet med noe slikt som PBKDF2, og legger man til at det kan være en tidsfaktor i forhold til hvor mange ganger hashen er kryptert, så kan du komme ned i bare noen titalls iterasjoner i sekundet, selv på en kapabel maskin, noe som gjør at det vil ta deg århundrer.

Du forutsetter at folk bruker passord med høy entropi. Det er feil.

Det er ikke helt korrekt. Gitt at ingen passord er like klarer man langt flere på den tiden.

Man tar jo ikke for seg et og et passord, men prøver hashen på alle man har.

Og ekstremt mange bruker ett enkelt ord som passord etterfulgt av 123, så entropien er ekstremt lav i mange tilfeller.

 

Det er svært viktig å påpeke at det å lagre passord i hash eller kryptert medfører kun at en ofte men ikke alltid har litt bedre tid avhengig av hvor viktig infoen din er for hackeren. Passordet ditt er uansett på avveie.

 

Det er jo i for seg sant, dersom man med "litt" bedre tid mener et par tiår?

 

SHA-1 ble sluppet i 1995, og kollisjoner ble først funnet i 2005, SHA-2 tok også rundt et tiår før man fant kollisjoner, men regnes fremdeles som relativt trygt dersom det er implementert korrekt.

 

PBKDF2 er også fremdeles relativt trygt, og er en av de algoritmene som bør foretrekkes i dag.

 

Det er verdt å merke seg at for å knekke de fleste av de algoritmene som benyttes i dag så trenger man store mengder datakraft.

En vanlig PC ville bruke flere hundre år på å knekke ett eneste passord hashet i PBKDF2, og nye salt for hvert passord gjør regnbuetabeller umulig å benytte.

 

Så nei, egentlig er ikke passordet på avveie, det er en hash som er på avveie, en hash som bør være særdeles vanskelig å knekke, dersom alt er utført riktig, derav poenget med å hashe og salte passord.

 

Yahoo sine passord var ikke lagret i klartekst de heller.

Nå benyttet Yahoo MD5 uten salting til å hashe sine passord, en algoritme som i dag er totalt usikker, og som gjør at hvert passord kan knekkes på et under ett sekund med en vanlig PC.

 

Man får vel håpe Prisjakt har gjort en bedre jobb, men de burde kanskje opplyse om hvordan disse passordene er hashet for å berolige kundene sine ?

Jeg tør påstå at minst 500 av passordene fra prisjakt kan crackes i løpet av 24 timer med vanlig tilgjengelig forbrukerhardware uansett hashalgoritme de bruker:)

Vi lagrer ingen passord i klartekst, og våre undersøkelser viser ingen tegn til at det har blitt gjort forsøk på å få tilgang til denne krypterte informasjonen.

/Prisjakt support

Yahoo sine passord var ikke lagret i klartekst de heller.

Aldri lagre passord som klartekst. Bruk alltid en saltet hash så man ikke kan bruke oppslagstabeller og løse det trivielt.

Det er svært viktig å påpeke at det å lagre passord i hash eller kryptert medfører kun at en ofte men ikke alltid har litt bedre tid avhengig av hvor viktig infoen din er for hackeren. Passordet ditt er uansett på avveie.

Hvorfor bruker ikke sånne tjenester utelukkende anerkjente tredjepartsløsninger for innlogging?

 

Hva hjelper det for? Er man hacket kan man endre på hva som helst, inkludert om en bruker tredjeparter for innlogging.

Og en annen ting: Hvor mye bedre er en anerkjent tredjepart? Alle disse har jo også vært hacket (facebook flere ganger). Problemet blir bare enda større hvis det samme skjer.