Datainnbrudd hos Prisjakt - mengder av brukernavn og epostadresser på avveie

[Mr. Spaceworld]

 

Ble rammet selv, men jeg gidder ikke skifte passord. Hva kan de gjøre?

Hvis du har samme passord der som andre steder, kan de logge seg inn som deg andre steder.

 

Det er derfor jeg ikke har et eneste identisk passord på noen side. Så slipper jeg å uroe meg for passord på avveie

[0laf]

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.

 

Derimot, har man en rigg med 6-10 skjermkort av rette modellen, samt jobber med MD5, så kan man knekke trillioner av hasher i sekundet.

[Bjarne78]

 

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.

[amativeReflection]

 

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.

 

 

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. Tenk at ALLE de 1 000 000 var "hunter2", jeg trenger bare å treffe "hunter2" en gang. Jeg trenger ikke å gjenta arbeidet en million ganger. 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.

[0laf]

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?

[amativeReflection]

 

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?

 

 

Det tar ubetydelig med tid i forhold til alt annet. Så lenge alle hashene har plass i minnet tar det minimalt med tid å sjekke en generert hash opp mot flere andre. 

[0laf]

Det tar ubetydelig med tid i forhold til alt annet. Så lenge alle hashene har plass i minnet tar det minimalt med tid å sjekke en generert hash opp mot flere andre.

Det er klart, dersom man får 22 000 passord i minnet, så tar det lite tid å sammenligne i forhold til å generere hashen, og jeg forstår hva du mener med unike salt også, for dersom hvert passord har unike salt, så unngår man jo forsåvidt det problemet, ettersom hver hash uansett må genereres på nytt for hvert passord, ettersom det unike saltet må legges til osv.

[Bjarne78]

 

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.

[0laf]

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.

Endret 20. mars 2017 av adeneo

[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?

[Sokkalf™]

Ett sekund per hash er helt urealistisk, skyter godt over 22k innlogginger i timen ved peak her også, og det er mange i Norge som er større. Og det er Norge, tenk på løsninger for Kina.

[0laf]

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?

 

Jeg tar ikke forbehold om noe om helst, man lager forhåpentligvis tjenesten slik at den passer til trafikken, og med PBKDF2 så setter man jo selv antall runder, og angir omtrent hvor lang tid det vil ta å generere en hash, jo lengre tid, desto sikrere mot brute force.

 

Dette er jo nettopp det jeg skrev til å begynne med, hvorpå du hevdet det ville ta fotballbaner med servere?

 

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.

 

 

Dette er altså OWASP anbefalinger, du svarer med

 

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. 

 

Men jeg forstår ikke helt hvorfor det skal kreve fotballbaner med servere, og svarer med

 

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.

 

 

Hvor lang tid et par hundre tusen runder med PBKDF2 tar på din server, vet ikke jeg, men det er altså det som anbefales.

At du mener at det skulle kreve fotballbaner med servere å ta unna innlogginger fra en iPhone, får du selv stå inne for.

 

 

 

Ett sekund per hash er helt urealistisk, skyter godt over 22k innlogginger i timen ved peak her også, og det er mange i Norge som er større. Og det er Norge, tenk på løsninger for Kina.

 

Jeg vil påstå at dere da er ganske store, Finn har i overkant av 2 millioner unike brukere i uken, det er halve Norge, og dersom man ikke regner peak, men gjennomsnitt, så er det rundt 13000 i timen. 

 

Sannsynligvis er 99% av disse allerede logget inn med "husk meg" funksjonalitet, eller lar være å logge inn.

Samtidig har jo faktisk Schibstedt fotballbaner med servere, så det er neppe noe problem.

 

Har man 22 000 innlogginger som må bekreftes med brukernavn og passord i timen, og ikke driver spesielle tjenester som krever spesiell autorisasjon, slik som nettbank eller lignende, så bør man vel også ha infrastruktur til å håndtere minst  50 millioner unike brukere i uken, og rundt 1-2 millioner unike brukere samtidig.

Endret 21. mars 2017 av adeneo