Jeg er nybegynner for kryptografi og ønsker å forstå i veldig enkle termer hva en kryptografisk » salt » er når jeg kanskje trenger å bruke det, og hvorfor jeg skal eller ikke bør bruke det.
Kan jeg få en veldig enkel og tydelig (nybegynnernivå) forklaring?
Hvis du vet om referanser om emnet, vil de også være nyttige.
Svar
Årsaken til at salter brukes er at folk pleier å velge de samme passordene, og slett ikke tilfeldig. Mange brukte passord der ute er korte ord for å gjøre det enkelt å huske, men dette muliggjør et angrep.
Som du kanskje vet, er passord vanligvis ikke lagret i klar tekst, men heller hash. Hvis du er usikker på formålet med en hash-funksjon, kan du lese den først.
Nå, hva angriperne kan gjøre er å bare generere en liste over vanlige passord og deres tilhørende hashes. ved hasjene som et nettsted har lagret med tabellen, vil, hvis vanlige passord blir brukt, avsløre passordene for angriperen.
A salt blir ganske enkelt lagt til gjør et passord-hash-output unikt selv for brukere vedta vanlige passord . Hensikten er å gjøre forhåndsberegningsbaserte angrep lite nyttige. Hvis passordet ditt er lagret med et unikt salt, vil ikke en forhåndsberegnet passord-hash-tabell rettet mot usaltet passordhash eller målrette mot en konto med et annet salt ikke hjelpe til med å knekke kontoens passord. Et langt tilfeldig generert salt (ved bruk av /dev/urandom) forventes å være globalt unik . Dermed kan salter brukes til å lage pre -beregning angriper totalt ineffektivt.
Den enkleste måten å kombinere salt og passord på er å bare sammenkoble dem, dvs. den lagrede hashverdien er Hash(salt||password). passord password1 blir nå på magisk vis, f.eks. 6$dK,3gCA%Jpassword1 som sannsynligvis ikke blir funnet i en passordkrakkers tabell.
Saltet kan lagres helt i det klare i databasen, ved siden av hashverdien. Når angriperen har databasen og ønsker å finne passordene, må han generere den forhåndsberegnede tabellen for hvert salt hver for seg, en kostbar operasjon.
En annen måte å forsvare seg mot offline passordsprekk er å utføre passordstrekking, dvs. å gjøre et passordhash tregere å beregne for enhver person, inkludert påloggingstjenesten og passordkrakkere. En metode som brukes for å strekke passord oppnås ved å itere hash-funksjonen mange ganger, dvs. lagre Hash(Hash(Hash(Hash…(Hash(salt||password)))…).
En annen vanlig idé relatert til salting kalles en pepper . Det vil si en annen tilfeldig verdi sammenkoblet med passordet, slik at den lagrede verdien er Hash(pepper||salt||password). Pepperen blir da slett ikke lagret . Både påloggingsserveren og passordkrakkeren må tvinge den ukjente pepperverdien, noe som reduserer sammenligningen av passordhash for begge parter.
Fra 2013 til 2015 en passordhashing konkurranse ble holdt for å søke etter en bedre algoritme som strekker seg med passord. Vinneren var Argon2 algoritmen. Programmører anbefales å bruke Argon2 i stedet for å implementere sin egen algoritme .
Kommentarer
- Så egentlig, når du bare har ett eller to passord lagret i databasen, er bruk av salt effektivt ubrukelig? Det jeg forstår er at dette bare er nyttig når antall passord som er lagret i databasen ikke er lite.
- @AbhinavChoudhury: Nei, det forsvarer seg mot regnbuetabeller – dvs. forhåndsberegnede tabeller for en bestemt hash. Et eksempel: Ta et passord » passord1 «. Hvis du ikke ‘ t salt, lagrer du ‘ HASH (» passord1 «) i databasen din. Nå, hvis en angriper får dine poster, og har forhåndsberegnet HASH (*) for alle passord med 9 tegn, kan han gjenopprette passordet. Hvis du i stedet saltet passordet, HASH (‘ somesaltforyou ‘ || ‘ passord1 ‘) vil IKKE være i angriperens regnbuetabell (siden den ‘ inneholder mer enn 9 tegn).
- » Saltet kan lagres helt i det klare i databasen, ved siden av hashverdien » – – denne delen har egentlig ikke gitt mening for meg; Jeg lurte på om du kunne utvide det
- Poenget med saltet er å sørge for at hasjen ikke finnes i en forhåndsberegnet tabell. Det må lagres for å bekrefte passordet (ellers ‘ sa » pepper «). Saltet skal ikke være » hemmelig «, bare for å gjøre passordet unikt. Dette betyr selvfølgelig at hvert lagret passord må ha sitt eget, unike (og tilfeldige) salt.
Svar
Kan du hjelpe meg med å forstå hva et kryptografisk “salt” er?
I sammenheng med passord skapelse, er et «salt» data (tilfeldig eller på annen måte) lagt til en hash-funksjon for å gjøre det hash-utdataene fra et passord vanskeligere å knekke.
Når må jeg kanskje bruke det?
Alltid.
Hvorfor skal eller skal jeg ikke bruke den?
Du bør alltid bruke en saltverdi med hashfunksjonene dine, av grunner som er forklart nedenfor.
Det er generelt sant at folk velger svake passord, og det er absolutt sant at det er gigabyte med offentlig tilgjengelige regnbuetabeller full av hashverdier som representerer dem. Så når noen oppretter en konto på tjenesten din og velger et passord for å sikre identiteten deres, kan du vanligvis satse på at passordet de velger vil være 1) vanlig, 2) usikkert og 3) tilgjengelig for kryssreferanse i oppslagstabeller.
For eksempel er passordet Nowayin1 når hash via MD5 er 6f367d65bc74b88e21fb9959487ffa3a og er åpenbart ikke et godt valg. Selv om det kan se bra ut (og det ikke gjør det), det faktum at passordet MD5-hash vises i åpne databaser gjør det verdiløst.
Men det er bare 128-bit MD5. Hva med noe sterkere, som SHA1 (160-bit) eller til og med Whirlpool (512-bit)?
Samme problem.
For eksempel P @ $$ word med SHA1 er 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 og
1qazXSW @ utydeliggjort med boblebadekar 0bf7545b784665d23b9c174ca03688a405f05b048e9d6c49bfc2721a1fa872bbd6576273d002e56d7c2a9c378efe607af36eea9d708a776e6f60ecb26e081cdf .
Rotproblemet med alle disse passordene, og milliarder flere som dem, er det faktum at de ofte brukte hasjene har blitt kjent.
Et passord salt endrer det.
Hvis en tilfeldig verdi (saltet) ble lagt til brukerens valgte passord, da vil SHA1-hash 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 ikke lenger avsløre P $$ @ som brukerens passord, fordi hashverdien i regnbuetabellen ikke lenger samsvarer med den.
Og det tar ikke mye. En liten 16-bit tilfeldig verdi vil for eksempel gi 65 536 varianter av hver hashverdi i oppslagstabellene. Så en database med 15 milliarder oppføringer vil nå trenge over 983 milliarder hashes i den for å gjøre rede for saltet.
Så, det er poenget med å salte hasjene dine, for å hindre oppslag og regnbuebord. Men ikke «t heng hatten på en saltet hash, fordi hackere ikke kaster bort mye tid på å bruke regnbuebord for å finne ut passordene dine.
De vil bruke en fem-server 25-GPU klyngesystem som kjører Hashcat som kan brenne gjennom 350 milliarder gjetninger per sekund, og knekke hashes for hvert tenkelig passord med åtte tegn som inneholder store og små bokstaver, tall og spesialtegn, på litt under seks timer. (Og det var tilbake i 2012.)
Teknikker som nøkkel-stretching som gjør at hash går langsommere, kan brukes til å kompensere for hastigheten på slik maskinvare, noe som gjør ordbok- og brute-force-angrep for sakte til å lønne seg , men maskinvaren blir bare raskere og raskere.
OPPDATERING 2018:
Nåværende beste fremgangsmåter inkluderer sikker hashing av passordene dine med Argon2i (foretrukket fremfor kryptering), en minnehård funksjon som er veldig motstandsdyktig til FPGAer, GPUer med flere kjerner og dedikerte ASIC-moduler som brukes til å knekke passordfraser som ikke er strukket. I PHP7 implementeringen av Argon2 håndteres saltet internt for deg.
Svar
Jeg skal prøve å svare på en del av spørsmålet ditt som hittil har blitt neglisjert:
når jeg kanskje trenger å bruke den og hvorfor jeg ikke bør / ikke skal bruke den.
Det korte svaret er at du som amatør ikke skal bruke kryptografi på et nivå som krever håndtering av salter direkte.
For eksempel bcrypt algoritme for passordhashing bruker salter internt. Men det avslører ikke det faktum for utviklere som bruker det – du sender ganske enkelt passordet til bcrypt (og eventuelt en parameter som setter «nivå av CPU-innsats «som trengs for å generere hasjen) og den returnerer hashen. Når du trenger å validere om et passord er riktig, sender du bcrypt både passordet og den tidligere genererte hashen. Det vil indikere om passordet var det som ble brukt til å generere hash.
Ikke ikke ta rådene her og prøv å hash dine egne passord ved hjelp av salt. Det er en detalj på implementeringsnivået på lavt nivå, og hvis du finner deg selv å jobbe på et nivå der det er behov for slike ting, jobber du på altfor lavt nivå av abstraksjon. Kryptografi er veldig vanskelig å gjøre riktig, og Internett er absolutt fulle av velmenende utviklere «helt usikre hjemmelagde ordninger for passordhashing.
Svar
Sitering “ Eksamen Ref 70-486 Utvikling av ASP.NET MVC 4 Web Applications (MCSD): Utvikling av ASP.NET MVC 4 Web Applications ” av William Penberthy, Pearson Education, 15. september 2013:
Salting er en prosess som styrker filkryptering og hashes, noe som gjør dem vanskeligere å bryte. en tilfeldig streng til begynnelsen eller slutten av inndatateksten før hashing eller kryptering av verdien. Når du prøver å bryte en liste med passord, for eksempel, må hackere gjøre rede for saltet så vel som mulig passordinformasjon før de kan bryte i hver applikasjon. Hvis hver verdi som blir saltet tildeles en annen saltverdi, kan muligheten til å lage en tabell med potensielle passordverdier for en pa ssword-cracking-program blir uhåndterlig.
Svar
Et salt er et tilfeldig nummer som er nødvendig for å få tilgang til de krypterte dataene, sammen med passordet.
Hvis en angriper ikke vet passordet, og prøver å gjette det med et voldsomt angrep, så hvert passord han prøver må prøves med hver saltverdi.
Så, for et en-bits salt (0 eller 1), gjør dette krypteringen dobbelt så vanskelig å bryte på denne måten. Et to-biters salt gjør det fire ganger så hardt, et tre-biters salt åtte ganger så hardt osv. Du kan forestille deg hvor vanskelig det er å knekke passord med kryptering som bruker et 32-biters salt!
Kommentarer
- Nei. Salt antas vanligvis å være kjent for angriperen. I dette tilfellet, forbi noen lave terskler, forbedrer ikke salt sikkerheten.
- » Salt antas vanligvis å være kjent for angriperen » – > Hvem antar dette?
- @Mike: Hvem? Noen sier » Du bør alltid anta at angriperen kan saltet. «. Folk på en annen side sier » Salter er offentlige «, og sier senere » saltene er kjent, fordi at ‘ er industristandard bruk av ordet salt. » En annen sier » saltet er offentlig kjent, eller i det minste bør det behandles som offentlig kunnskap. «.