Å ikke lagre saltet er dårlig råd.

Hovedformålet med et salt er at hvert brukerpassord må angripes individuelt.

Hvis du ikke lagrer saltet, , som du sa, må du prøve hver eneste saltkombinasjon for å validere passordet. Hvis du trenger å sjekke hver eneste saltkombinasjon, betyr dette at saltet ikke kan være for langt (du nevnte 12 biter i en kommentar). Hvis saltet ikke er langt, betyr det at saltet blir gjentatt for mange brukere. Hvis det gjentas for mange brukere, betyr det at angriperen vil kunne angripe mange brukere samtidig, noe som vil spare angriperens tid.

Ved å gjøre det, beseirer du nesten helt hensikten med å bruke en salt.

Et "hemmelig" salt er kjent som en pepper.

Fra Wikipedia:

En pepper kan legges til et passord i tillegg til en saltverdi. En pepper utfører en lignende rolle som et salt, men mens et salt ofte lagres ved siden av verdien som blir hash, for at noe skal defineres som en pepper, bør det oppfylle et av følgende kriterier som definerer det en mer nøye skjult 'hemmelighet' enn saltverdien:

• Pepperen holdes atskilt fra verdien som skal hashes
• Pepperen genereres tilfeldig for hver verdi som skal hasles (innenfor et begrenset sett med verdier), og lagres aldri. Når data testes mot en hash-verdi for en kamp, ​​gjøres dette ved å gjenta gjennom settet med verdier som er gyldige for paprikaen, og hver og en blir lagt til i dataene som skal testes (vanligvis ved å suffiksere dem til dataene), før den kryptografiske hashfunksjonen kjøres på den kombinerte verdien.

Fordelen med en pepper er at en angriper nå må gjette opp til antall mulige permutasjoner av en pepperverdi for hver enkelt tekstoppføring.

Paprika øker angrepslengden for en bestemt hash, mens et salt ikke gjør det.

Husk at et salt er en effektiv demping for forhåndsberegnet hasj, og det gir en angriper bruker lang tid på å angripe et sett med hashes. Imidlertid, hvis bare en hash er bekymringsfull, og ingen forhåndsberegnet hasj skal brukes, øker ikke salt angrepslengden. En paprika tvinger imidlertid angriperen til å bruke flere gjetninger for hvert enkeltpassord, selv for en enkelt hash.

På denne måten ligner en pepper på nøkkelstrekning.

De fleste implementeringer foretrekker nøkkelstrekking fremfor paprika.

Min personlige observasjon er at de fleste implementeringer foretrekker nøkkelstrekking fremfor paprika. Jeg har ikke en referanse til dette, så leserne kan gi støtte eller avvikende referanser i kommentarene. Folk pleier å foretrekke nøkkelstrekking fordi det har en kjent og forventet ytelseskostnad og sikkerhetsfordel. For å beregne den Nte runden av en hash, må N-hash beregnes. Med en pepper kan imidlertid bare forventet antall forsøk beregnes. Vurder en 1 byte pepper, angriperen trenger 256 gjetninger for å gjette alle mulige kombinasjoner, men forventet verdi er 128, og angriperen kan (i gjennomsnitt 1/256 ganger) gjette verdien på første forsøk.

Peppers og Key Stretching kan virke mot hverandre.

Key stretching er effektiv fordi du kan angi antall runder basert på hvor lang tid du vil beregne en hash til ta. Si at du vil at en enkelt sjekk skal ta et halvt sekund på gjeldende maskinvare, du bare øker rundene til det skjer.

Med en pepper, fordi du trenger å gjette flere verdier for hvert passord, må størrelsen på en pepper være omvendt relatert til antall runder for å holde beregningstiden konstant.

Praktiske råd om hasjimplementeringer

Det beste rådet for implementering av passord / hash er å bruke kjente metoder og testede biblioteker. Du bør bruke bcrypt eller pbkdf2 med et unikt salt og mange runder. Disse algoritmene har en tendens til å ha kjente implementeringer på mange språk og rammer. Hvis du tilfeldigvis finner et velkjent og testet bibliotek som inneholder paprika, i tillegg til salter og strekk i nøklene, kan det lønne deg å bruke den, men den ekstra fordelen oppveier ofte ytelseskostnadene.

Bakgrunn: Du bør bruke en langsom passordhash. (dvs. bcrypt) Med 'treg' mener jeg beregningsdyr, tar mer enn 100 ms (på maskinvaren) ^{med DoS-beskyttelse *} for å teste et enkelt passord. Dette er for å øke prosessorkraften som trengs (på angriperens maskinvare) for å finne passordet med brute force, hvis hasjen blir stjålet.

Per bruker unikt salt anbefales på det sterkeste. (i tilfelle bcrypt genereres det automatisk) Salt skal være svært unikt (dvs. langt & tilfeldig), men ikke hemmelig . Å bruke unikt salt betyr at en angriper må kjøre en egen brute force Job for hver bruker .

Hvis det ikke var noe salt, kunne angriperen umiddelbart bruke en Rainbow Table og ingen brute force i det hele tatt.

Hvis du bare bruker et "delt salt", kan en angriper knekke passord for alle brukere med en single brute tving Job. (ikke så raskt som et regnbuebord, men likevel mye lettere enn en egen brute force Job for hver enkelt)

Svar: Hvis du ikke skulle "lagre" salt ('brute force the hash at runtime' som professoren din antyder)

• de mulige saltene må være veldig få
• hashen må være ganske mye raskere

Dette ville fullstendig beseire formålet med Salt, og ødelegger sterkt fordelen med en langsom hash. Det er en stor designfeil fra professoren din. I utgangspunktet rullerer han sitt eget passordlagringsskjema, der han skal bruke den velprøvde bcrypt -algoritmen (eller scrypt eller PBKDF2) slik det var ment å bli brukt .

_{* Som @Navin kommenterte, ville dette være en potensiell DoS-angrepsvektor. En løsning er å begrense antall timeforsøk per IP og per brukernavn. Det er også mulig at du reduserer tregheten til hasjen din til bare å ta 10 ms. Dette er ikke så godt som 100 ms fra et "stjålet hash" -perspektiv, men fortsatt mye bedre enn "mikrosekunder".}

Professoren din stemmer ikke. Poenget med et salt er å øke entropien til de hashede passordene for å forhindre enhver form for pre-beregningsangrep på dem, samt forhindre at det samme passordet fra forskjellige brukere har samme hashverdien.

Å kunne prøve alle mulige saltverdier betyr at du må ha en veldig liten mengde entropi i saltet, noe som betyr at en forhåndsberegning via regnbuetabeller er mulig.

Du kan bruke saltet på denne måten. Det ville være en slags hasj-stretching prosess. Vanligvis strekker du en hasj ved å gjenta algoritmen flere tusen ganger, noe som reduserer angripere og brukere 1000 ganger, men brukere har vanligvis ikke noe imot nedgangen. Å bruke et salt på denne måten vil ha en effekt av å utføre en hash-strekkingsalgoritme ved å måtte gjenta den for mange ukjente hasjer.

Dette er imidlertid en ekstremt uvanlig tilnærming. De tradisjonelle måtene å gjøre salt på, gjør det saltene skal gjøre langt bedre (gjør det slik at ingen kan forhåndsberegne en passordtabell). De tradisjonelle måtene å gjøre hasj-stretching gjør det som hasj-stretching skal gjøre langt bedre (gjør det slik at det tar lengre tid for angripere å beregne passord). Å bruke et salt på denne måten er en slags musking av de to sammen. Resultatet er en slags slags arbeid, men de renere tilnærmingene gjør begge løsningene langt bedre enn den stygge misforståelsen av teknikker.

I stedet for å tenke på salt i termer av tøffing, liker jeg å tenke på det når det gjelder å si at det gjør det umulig å fortelle noe om et passord, inkludert dets forhold til andre passord, ved å se på det. Hvis systemet ikke bruker salting, vil det å se på to brukeres hashed-passord indikere om deres virkelige passord samsvarte. Hvis et system saltes bare med brukernavn, men ikke noe tilfeldig, tidsspesifikt eller systemspesifikt, vil det å se på brukerens hashpassord på to maskiner som bruker samme tilnærming, indikere om brukerens passord på de to maskinene samsvarer. Hvis systemet saltes ved hjelp av system-ID og brukernavn, men ikke noe tilfeldig eller tidsspesifikt, kan noen med tilgang til to forskjellige passordhasher av samme bruker fortelle om de tilknyttede passordene stemmer overens.

Effekten av tilfeldig salting er å gjøre det slik at det ikke er sannsynlig at to hashes med samme passord vil matche, selv om de involverer samme bruker på samme system. Mens man kunne oppnå en lignende effekt uten å lagre saltene hvis påloggingsforsøk skulle tvinge dem, vil en slik tilnærming begrense den praktiske lengden på salt man kan bruke, og dermed øke sannsynligheten for at passord som brukes i to sammenhenger samme salt og dermed være gjenkjennelig som samsvarende.

Hva gir salting deg? Angripere har forhåndsberegnede databaser med hashverdier for passord, vanlige og ikke. Hvis de fanger databasen din og har hash av passordene for hver bruker, er det enkelt å sjekke hashene deres mot disse verdiene uten salt.

Med et tilfeldig salt som lagres sammen med passordet, er dette sinnsykt rask metode er ikke lenger mulig. Men hvis angriperen har salt så vel som hasj, er det fortsatt mulig å bruke ordbokangrep for svake passord eller brute-forcing for korte. Alt angriperen trenger å gjøre er å bruke saltet og prøve forskjellige passord ved hjelp av en ordbok eller brute-force-angrep.

La oss si at når passordet endres, har du det med en tilfeldig 12-biters verdi som ikke er lagres ikke sammen med saltet. Så hver gang du sjekker passordet, må du prøve alle 4096 verdiene. På datamaskinen min tar dette omtrent 3,5 ms, så 284 passord kan sjekkes hvert sekund. Litt mer CPU-bruk på serveren når noen logger på, men for noen som prøver ordbok eller brute-force-angrep, gjorde du jobben deres mye vanskeligere, selv om de har hasj og salt.

Det ser ut til å være noen fordeler med ideen om ikke å lagre noe kontrollert antall biter av saltet, som er uavhengig konfigurert og uavhengig av saltstørrelsen.

Anta at vi har 32-bits salter. Vi kunne velge å lagre bare 22 bits, og brute-force gjennom de resterende 10 når vi autentiserer. Effekten av dette er som om flere runder ble lagt til hashing-funksjonen. Ikke så mange som legitim autentisering påvirkes, men nok til å øke vanskeligheten med brute-force cracking.

Neste år blir maskiner raskere. Så vi sveiper gjennom passorddatabasen og slår av litt fra hvert salt: nå lagrer vi bare 21 biter, og må brute kraft gjennom 11.

Det er som om vi doblet hasjstyrken, men uten forstyrrelse av å erstatte algoritmen og få brukerne til å hash passordene sine på nytt (som er opp til den vanlige policyen for utløp av passord).

Denne "progressive salt-kassering" -tilnærmingen kan forlenge levetiden for hashing-funksjoner.

Imidlertid reduserer denne typen tilnærminger den legitime autentiseringen og brute force-angrepet med en like faktor, så i beste fall gir de et mindre sikkerhetslag. Vårt fokus bør plasseres i forbedringer som bare gir en konstant mengde ekstra tid til legitim bruk, samtidig som vanskeligheten med å knekke multipliseres. En forbedring som har denne egenskapen øker selvfølgelig mengden entropi i passordfrasen! Hver bit av entropi som legges til passordet, tilfører de legitime brukerne en konstant kostnad, men dobler den brutale kraften. Et passord med lengden N tar O (N) til hash (og type), men O (2 ** N) for brute force. Å legge til 12 biter entropi i et passord slår å skjule 12 biter salt.

Ut i naturen har vi en brukertabell. En brukertabell er vanligvis

  ID | brukernavn | salt | kryptert_passord | horridly_insecure_reset_key ===================================================== ============================ 1 | bruker1 | foo | 09b6d39aa22fcb8698687e1af09a3af9 | NULL2 | bruker2 | bar | 6c07c60f4b02c644ea1037575eb40005 | NULL3 | bruker3 | baz | 09b6d39aa22fcb8698687e1af09a3af9 | reset  

Da vil en autentiseringsmetode se ut som

  def authenticate (user, password) u = User.find (user: user) return u. encrypted_password == kryptere (passord + u.salt) slutt  

Ved å ha salt per bruker sørger det for at selv om passordet for bruker1 er kjent, kan du ikke finne ut passordet for bruker2 eller bruker3 uten salt.

Du sørger også for at du ikke kan finne ut saltet ved å ha et sett med krypterte passord og prøve noen få krypterte passord.

I utgangspunktet, alle angrep mot en brukeren må startes fra bunnen av.

Selv om en angriper har en liste over brukere og salter, må de fremdeles knekke mot hver bruker for å se om de har et passord. Hvis du hadde en saltsamling, eller ett statisk salt, kunne jeg vite at bruker1s passord er passord og så bare finne alle de krypterte passordene som samsvarer. Så denne måten reduserer dem i det minste litt mer.

Nå når vi ser på salter, vil vi redusere saltbruk. To identiske salter vil gjøre det lettere for angripere. Hvis to personer deler det samme saltet og det samme passordet, bryter den ene brukeren den andre.

Så la oss si at vi bare bruker disse tre saltene. Og vi har 3000 brukere. det betyr at 1000 mennesker har samme salt. Hvis 1% av dem har passordet "passord", kan disse menneskene knekkes samtidig. 10 kontoer blir hacket samtidig. Fordi vi kjenner de tre saltene. Det er en veldig enkel strekning for å få angrepet 30 personer samtidig.

Nå, hvis hvert salt er unikt. Og vi vet at bruker1 passord er passord, det gjør ikke noe bra for deg. Du har fortsatt bare knekt 1 bruker. Du må fremdeles gjøre "gjør passord + salt = kryptert passord" for alle andre 2999 brukere.

En veldig viktig merknad.

Sikkerhet gjennom uklarhet er ikke sikkerhet. Det betyr ikke at du bør legge ut brukerbordet ditt på google fordi det er dumt. Men når du måler sikkerhet, bør du anta at angriperen har alt. Du kan ikke si, "Men de vet ikke applikasjonssaltet, fordi de ikke har kildekoden". Fordi de kunne. Betyr ikke å gi bort saltene dine, det betyr bare at det ikke er reell sikkerhet. Anta at de har brukernavnet og saltet, og prøv å gjøre det vanskeligere for dem å få passordet.

SUPER VIKTIG MERKNAD

kode og tabell som brukes her er omtrent 9 000 ganger for enkle til reell bruk. Passordet er ikke kryptert, saltene er for korte, metoden er litt forenklet, kort sagt å gjøre noe som dette i produksjonen er ikke noe som skal betraktes som sikkert. Jeg valgte disse sakene der for demonstrasjonspoenget, ikke fordi de er sikre.