Spørsmål:
Hvor ille ville en delvis hasjlekkasje være, realistisk?
MechMK1
2019-05-31 18:11:28 UTC
view on stackexchange narkive permalink

Selv om den nåværende anbefalingen for lagring av passord er bruken av en langsom nøkkel-avledningsfunksjon som Argon2, scrypt, PBKDF2 eller bcrypt 1 , bruker mange nettsteder fremdeles den tradisjonelle -hashen (passord + salt) -metoden, med MD5, SHA-1 og SHA-256 som de mest brukte hashfunksjonene.

SHA-1-hash av mySuperSecretPassword123 med salt ! 8 (L-_20hs er E5D0BEE0300BF17508CABA842084753685781907.

Anta at en angriper ville stjele saltet og den første halvdelen av hasjen, så E5D0BEE0300BF17508CA . Vi antar også at angriperen er klar over at SHA-1 blir brukt og hvordan saltet og passordet sammenkobles.

Hvor vanskelig ville det være for en angriper å gjenopprette originalen passord?

1 bcrypt teknisk er ikke en nøkkelavledningsfunksjon, men i forbindelse med dette spørsmålet fungerer den identisk .

Dette kan avhenge mye av hva inngangsverdiene kan være - jeg har sett et system som bruker MD5 med de tre første tegnene fjernet, der inngangsverdiene var 4-sifrede koder.Det var trivielt å gjenopprette innspillene, selv om de var saltet og hadde en 30 sekunders utløp.
@Matthew Av hensyn til dette eksemplet er det bare vanlige gamle passord.
FWIW, verken MySuperSecretPassword123 eller MySuperSecretPassword er funnet på https://haveibeenpwned.com/Passwords.Imidlertid har mysupersecretpassword blitt funnet av kjeks.Det er vanskelig å gi deg et reelt svar på "hvor lang tid det vil ta", siden det bare er for mange faktorer involvert.Men jeg vil si gitt at noen allerede har funnet en SVÆRT lignende versjon i faktisk bruk, på et reelt sett med ekte passord, at dette er et dårlig passord som kan, og nesten har blitt knekt av ekte angripere.
Hvorfor skulle de bare stjele halvparten av hasjen?Hvis de får tilgang til halvparten av det, hva kan muligens hindre dem i å stjele hele greia?Tvert imot, siden full hash er lagret som en enkelt enhet (sannsynligvis en kolonne i DB), er det sannsynligvis * mindre * å stjele hele greia.
Hvis det var et problem, ville [haveibeenpwned ikke ha en passorddel] (https://haveibeenpwned.com/Passwords), selv om det å lekke en delvis hash ville være et problem.
@jpmc26 Det eneste tilfellet vil være hvis hashen på en eller annen måte lagres i to separate databaser, spesielt for å skape denne situasjonen.
@jpmc26 Det er ikke et praktisk scenario på noen måte.Jeg prøver ikke å bygge "MySuperSecureAuthenticationSystem" basert på splittede hashes.Jeg syntes det var veldig interessant.
Tre svar:
Benoit Esnard
2019-05-31 22:39:58 UTC
view on stackexchange narkive permalink

Egentlig er det like ille som en full hasjlekkasje .

Hash-cracking gjøres ved:

  1. Generering av passord kandidater
  2. Hashing dem
  3. Sammenligning av resulterende hashes med hash du vil knekke

Ingen av disse trinnene vil være tregere i tilfelle en delvis hasjlekkasje, så dette ligner veldig på full hasjlekkasje hastighetsmessig.

Vær oppmerksom på at hvis partiell hashoutgang ikke er lang nok, vil mange passordkandidater matche. I det scenariet kan du ikke vite hvilken kandidat som var det virkelige passordet.

Dette er riktig svar.Selv om passordinngangene var jevnt tilfeldige, ville dette være et effektivt fullstendig kompromiss.Det er ytterst usannsynlig at to kandidatpassord vil generere en kollisjon i en gitt 80 bit.Selv etter en billion gjetninger har du mindre enn 50% sjanse for å finne to passord som kolliderer i de 80 bitene.Men passord er ikke jevnt tilfeldige;de er overveldende alfanumeriske og har veldig lav entropi per bit.En billion gjetninger vil generere treff for opptil 95% av passorddatabasen din.
@StephenTouset Siden passordene det er snakk om er saltet, ville det ikke kreve trillion gjetninger per passord?Ikke at det betyr noe i praksis siden brute force-metoden er rimelig rask uansett, men det er fortsatt et viktig skille, tror jeg.
@jpmc26 OP antar at saltet er stjålet ved siden av (delvis) hasjen, så jeg tenker ikke at skillet ditt gjelder.
Jeg antar at det er en slags terskel skjønt?F.eks.hva om du bare har det første _kvartalet_ av hasjen?Hva om du bare har første bokstav?
@RaphaelSchmitz Til slutt vil det gi deg så mange kandidater at det ville være nesten like ille som å måtte gjette hasjen fra starten, antar jeg.Men selv en liten delvis hasj bør begrense feltet litt vil jeg gjette.
@Mast Vel, når de skriver at halvparten av hasjen er "like ille som en full hasjlekkasje", kommer jeg ikke til å klage hvis den bare er 98,3% så ille som en full hash.Imidlertid antar jeg at bare det å ha første bokstav ikke ville hjelpe nesten like mye, det er sannsynligvis en slags logaritmisk nedfall.I så fall har jeg lyst til å nevne et punkt der det _ begynner å gjøre en forskjell_ ville forbedre svaret.
@RaphaelSchmitz: poenget er faktisk nevnt på slutten av svaret!
@BenoitEsnard Det er faktisk nevnt, men ikke noe tall.Kanskje jeg tar feil når jeg ber om et (grovt) tall her.Jeg tenker bare, _ noe_ fikk deg til å tro at halvparten av hasjen ikke gjør noen reell forskjell, men "ikke lenge nok" _ gjør_.Så det må være et punkt der det "ikke er lenge nok".Eller kanskje det er unødvendig matematikk, jeg er ingen ekspert.
@TripeHound Skillet er en av hvilke angrepsmetoder som er tilgjengelige for angriperen.Hvis du ikke bruker salter, vil de bety at de kan angripe hele databasen i ett pass, mens angriperen med salter må prøve å knekke hvert passord hver for seg.
"* Vær oppmerksom på at hvis den delvise hash-utgangen ikke er lang nok, vil mange passordkandidater matche *" Men også, du kan aldri bruke denne verdien til å validere brukerens passord, siden det faktisk vil være "mange" passord sommatche hasjen.Du vet det, men jeg er ikke sikker på at dette fremgår av svaret.Kanskje avklare poenget før en utvikler får den gode ideen om å lagre bare som 10 hex-tegn og kaller det sikrere ...: P
@Luc: Etter min mening handler spørsmålet om en lekkasje delvis hasj, ikke om lagring av hashen, så jeg føler at svaret ikke skal anta noe om hvordan passord lagres.: o
@RaphaelSchmitz: det er virkelig et logaritmisk falloff, så det avhenger virkelig av antall passordkandidater angriperen vil prøve: En n-lengde heksadesimal utgang tilsvarer `2 ** (4 * n)` mulige hashes.Også, en enkelt bokstav "delvis hasjlekkasje" gir ingen mening for meg.
Til det punktet lekker heller ikke en halv hash.For hver bit som lekkes, er imidlertid innsatsen en angriper må bruke på å teste passord online mot, halvert.Dette er * helt uavhengig * av utgangsstørrelsen til selve hash-funksjonen.En enkelt heksesifret lekkasje vil tillate en angriper å sende 1/16 av påloggingsforespørslene som kreves for et brutalt kraftforsøk, siden de forebyggende kan filtrere ut kjente gale feil.Hvis du har lekket 80 bits (20 heksesifre), må en angriper bare prøve 1 av hver 1.2e24-kandidat, noe som er nok til å identifisere nesten ethvert passord fra den virkelige verden.
AndrolGenhald
2019-05-31 22:53:07 UTC
view on stackexchange narkive permalink

Det kommer an på hvor godt passordet er, og størrelsen på hash-prefikset.

Stort prefiks / dårlig passord

Hvis vi antar at dette er en hash av en gjennomsnittlig Joe passord som inneholder si 30 biter entropi ("mySuperSecretPassword123" inneholder nesten helt sikkert mindre entropi enn dette), og for å være konservativ følger vi Kerckhoffs prinsipp og antar at angriperen vet hvordan passordet ble generert, så er det bare 2 30 mulige passord. Hvis prefikset som lekkes er 80 bits fra en SHA-1-hash, er det ekstremt sannsynlig at det bare vil være en passordkandidat som samsvarer med hash-prefikset.

I utgangspunktet, hvis log2 (passordplass ) er mindre enn det lekkede prefikset, du kan like gjerne vurdere at hele hash har lekket.

Lite prefiks / godt passord

Hva om prefikset er lite eller passordet er bra (ish)? Si for eksempel at du har en passordplass på 2 50 , og du har lekket et 40-biters prefiks. En angriper kan ikke bare knekke passordet, siden det vil være rundt 2 10 passord som samsvarer med hashen, men dette er fortsatt et problem. 2 50 er altfor stort til å starte et online angrep, selv uten hastighetsbegrensning. Men hvis en angriper kan forhåndsfiltrere gjetningene sine til de som samsvarer med prefikset i et frakoblet angrep, trenger de bare å prøve 2 10 i onlineangrepet, noe som kan være mulig.

Hvis log2 (passordplass) - prefiksstørrelse > 0 , vil angriperen sannsynligvis ikke kunne knekke det nøyaktige passordet, men hvis det er lite nok, kan de generere en pool med passordkandidater til bruk i et online angrep.

Veldig bra passord

Selvfølgelig, hvis du tilfeldig velger fra et passordområde større enn 2 100 (for å være konservativ ) med ensartet sannsynlighet, så er det irrelevant å lekke en delvis eller full hash, ettersom det aldri kommer til å bli knekt uansett.

Som referanse har et engelsk alfanumerisk passord (små bokstaver, store bokstaver og sifre) på 17 tegn et passordområde på over 2 ^ 101,2.
@jpmc26 Forutsatt at det er helt tilfeldig (noe som burde være åpenbart, men det er kanskje ikke for noen mennesker).
?Passordplass påvirkes ikke av tilfeldighet.Det er entropi.Jeg hadde bare problemer med å finne ut hvor stor 2 ^ 100 faktisk er, siden vi vanligvis ikke konstruerer passord av et alfabet med to tegn, så jeg ønsket å si det mer relatert.
@jpmc26 Passordplass påvirkes hvis passordet ikke blir valgt på en vilkårlig måte.Når du sier passordplass, antar du alltid at passordene velges jevnt tilfeldig og ikke, si fra en liste som inneholder et delsett av passordområdet.
@Nobody Med mindre jeg tar feil, er "passordplass" bare settet med alle mulige passord gitt et alfabet og en lengde.Jeg antar at plassen kan være begrenset på andre måter, og eliminere noen passord fra den, men selve plassen er ikke relatert til valget av et enkelt passord fra den.Tilfeldighet er derfor irrelevant da det ikke er noe valg involvert i å spesifisere rommet.Hvis du mener noe annet enn tilfeldig valg av et passord fra rommet, vennligst bruk de riktige begrepene.
@jpmc26 Dette ville være en annen fornuftig definisjon, bortsett fra at de fleste standardberegninger avhengig av "passordplassstørrelse" ikke fungerer hvis du bruker den.
@Nobody Da er det svaret som trenger avklaring, ikke min kommentar.Jeg ga bare en mer intuitiv beskrivelse av hvordan passordstørrelsen på 2 ^ 100 ser ut.Det er svaret som gir påstander om hvor vanskelig det er å knekke passordet med et mellomrom av den størrelsen, ikke min kommentar.
@jpmc26 Som svareren opprinnelig uttalte, trenger ikke den opprinnelige kommentaren din strengt tatt avklaring, men hvis du ikke kan håndtere konverteringen selv, kan det også hende du må bli fortalt hva svareren la til i kommentaren din, dvs. hvordan du velger passordet dittfra rommet.Den andre kommentaren din derimot, som jeg svarte, er litt misvisende.
@jpmc26 Helt korrekt, da jeg så 2 ^ 101.2, antok jeg av en eller annen grunn umiddelbart at du snakket om entropi, selv om du faktisk sa "passordplass"."passordplass" betyr settet med alle passord som blir vurdert, akkurat som "nøkkelplass" betyr settet med alle mulige taster.
Passordet mitt er i passordområdet på 17 tegn (så 2 ^ 101.2 valg);det skjer tilfeldigvis "hallo123".Er jeg trygg?:-P (Oversettelse: Et passord mellomrom med 5 tegn er en delmengde av 17-tegnsområdet; et angrep kan starte med frukten med lav henging og gradvis prøve de ytterligere områdene av passordområdet.)
RedBorg
2019-05-31 21:04:56 UTC
view on stackexchange narkive permalink

Hvis du bare har en halv 160 bit hash, betyr det at du har 80 ukjente bits. Dette resulterer i $ 2 ^ 80 = 1.2089258196146292e + 24 $ mulige hashes igjen.

Det betyr at passordet ditt kan hases til en av disse, og det reduserer eksponentielt antall mulige passord (2 ^ 80 ganger mindre), men en angriper KAN IKKE finne passordet ditt bare basert på dette, hvis vi antar at passordet ditt er helt tilfeldig.

Det er åpenbart sjelden tilfelle, så hvis noen skulle bruke et moderne ordbokangrep som genererer passordet, vil de sannsynligvis ende opp med en relativt liten liste over sannsynlig passord. Den lille listen med passord kan da testes mot den virkelige autentiseringstjenesten for å få det nøyaktige passordet.

TLDR:

  • hvis passordet er tilfeldig: Skal være ok
  • hvis passord kan genereres med et moderne ordbokangrep (f.eks. smolbanana73): Vil anbefale å endre det.

Merk: Have I been Pwned gjør be deg om de første bitene av passordet ditt for å sjekke om det er i listene, men det er lite nok til at det er ubetydelig.



ⓘ
Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 4.0-lisensen den distribueres under.
Loading...