Jeg er nybegynder til kryptografi og ønsker at forstå i meget enkle vendinger, hvad en kryptografisk ” salt ” er, når jeg muligvis skal bruge det, og hvorfor jeg skal eller ikke skal bruge det.
Kan jeg få en meget enkel og klar (begynderniveau) forklaring?
Hvis du kender nogen henvisninger til emnet, ville disse også være nyttige.
Svar
Årsagen til, at der anvendes salte, er, at folk har tendens til at vælge de samme adgangskoder og slet ikke tilfældigt. Mange brugte adgangskoder derude er korte virkelige ord, for at gøre det let at huske, men dette også muliggør et angreb.
Som du måske ved, er adgangskoder generelt ikke gemt i klar tekst, men snarere hashede. Hvis du er i tvivl om formålet med en hash-funktion, skal du først læse om det.
Nu, hvad angriberne kan gøre er at generere en liste over almindelige adgangskoder og deres tilsvarende hashes. når de hashes, som et sted har gemt med tabellen, afslører adgangskoderne for angriberen, hvis almindelige adgangskoder bruges.
A salt tilføjes simpelthen til gør en adgangskodeshashoutput unik selv for brugere vedtagelse af almindelige adgangskoder . Dens formål er at gøre præberegningsbaserede angreb ikke nyttige. Hvis din adgangskode er gemt med et unikt salt, vil enhver forudberegnet kodeord-hash-tabel, der er målrettet mod usaltet adgangskodeshash eller målretning mod en konto med et andet salt, ikke hjælpe med at sprænge din kontos adgangskode. Et langt tilfældigt genereret salt (ved hjælp af /dev/urandom) forventes at være globalt unik . Således kan salte bruges til at fremstille præ -computation angriber helt ineffektivt.
Den enkleste måde at kombinere saltet og adgangskoden på er at sammenkæde dem, dvs. den gemte hashværdi er Hash(salt||password). adgangskode password1 bliver nu magisk, f.eks. 6$dK,3gCA%Jpassword1 som sandsynligvis ikke findes i en adgangskodekrakers tabel.
Saltet kan opbevares helt i det klare i databasen ved siden af den hashede værdi. Når angriberen har databasen og ønsker at finde adgangskoderne, skal han generere den forudberegnede tabel for hvert salt individuelt, en kostbar handling.
En anden måde at hjælpe med at forsvare sig mod offline adgangskodebrydning er at udføre adgangskodestrækning, dvs. gør en hash-kodeord langsommere at beregne for enhver person, inklusive login-service og adgangskodekrakere. En metode, der bruges til at strække adgangskoder, opnås ved at gentage hash-funktionen mange gange, dvs. lagring af Hash(Hash(Hash(Hash…(Hash(salt||password)))…).
En anden almindelig idé relateret til saltning kaldes en peber . Det vil sige en anden tilfældig værdi sammenkædet med adgangskoden, således at den gemte værdi er Hash(pepper||salt||password). Peber lagres derefter slet ikke . Både login-serveren og adgangskodeknækkeren har brug for at tvinge den ukendte peberværdi, hvilket nedsætter sammenligningen af adgangskodeshash for begge parter.
Fra 2013 til 2015 er en adgangskodeshash konkurrence blev afholdt for at søge efter en bedre algoritme, der strækker sig med adgangskoder. Vinderen var Argon2 algoritmen. Programmører anbefales at bruge Argon2 i stedet for at implementere deres egen algoritme .
Kommentarer
- Så når du kun har en eller to adgangskoder gemt i databasen, er brugen af salt faktisk ubrugelig? Hvad jeg forstår er, at dette kun er nyttigt, når antallet af adgangskoder, der er gemt i databasen, ikke er lille.
- @AbhinavChoudhury: Nej, det forsvarer sig mod regnbueborde – dvs. forudberegnede tabeller til en bestemt hash. Et eksempel: Tag et kodeord ” password1 “. Hvis du ikke ‘ t salt, gemmer du ‘ HASH (” password1 “) i din database. Hvis en angriber nu får dine poster og har forudberegnet HASH (*) for alle adgangskoder på 9 tegn, kan han gendanne adgangskoden. Hvis du i stedet saltede adgangskoden, HASH (‘ somesaltforyou ‘ || ‘ password1 ‘) vil IKKE være i angriberens regnbue-tabel (da den ‘ indeholder mere end 9 tegn).
- ” Saltet kan opbevares helt klart i databasen ved siden af den hashede værdi ” – – denne del har aldrig rigtig givet mening for mig; Jeg spekulerede på, om du kunne udvide det
- Saltets pointe er at sikre, at hasjen ikke findes i en forudberegnet tabel. Det skal gemmes for at bekræfte adgangskoden (ellers ‘ sa ” peber “). Saltet antages ikke at være ” hemmeligt “, kun for at gøre adgangskoden unik. Dette betyder selvfølgelig, at hver gemt adgangskode skal have sit eget, unikke (og tilfældige) salt.
Svar
Kan du hjælpe mig med at forstå, hvad et kryptografisk “salt” er?
I forbindelse med adgangskoden oprettelse, et “salt” er data (tilfældigt eller på anden måde) tilføjet til en hash-funktion for at gøre det hashede output af et kodeord sværere at knække.
Hvornår skal jeg muligvis bruge det?
Altid.
Hvorfor skal eller skal jeg ikke bruge det?
Du skal altid bruge en saltværdi med dine hash-funktioner af grunde, der er forklaret nedenfor.
Det er almindeligt, at folk vælger svage adgangskoder, og det er bestemt sandt, at der er gigabyte offentligt tilgængelige regnbue-tabeller , der er fyldt med hashværdier, der repræsenterer dem. Så når nogen opretter en konto på din tjeneste og vælger en adgangskode for at sikre deres identitet, kan du typisk satse på, at den adgangskode, de vælger, vil være 1) almindelig, 2) usikker og 3) tilgængelig til krydshenvisning i opslagstabeller.
For eksempel er adgangskoden Nowayin1 når hash via MD5 er 6f367d65bc74b88e21fb9959487ffa3a og er selvfølgelig ikke et godt valg. Selvom det måske ser okay ud (og det ikke gør det), det faktum, at adgangskodens MD5-hash vises i åbne databaser, gør det værdiløst.
Men det er bare 128-bit MD5. Hvad med noget stærkere, som SHA1 (160-bit) eller endda Whirlpool (512-bit)?
Samme problem.
For eksempel P @ $$ word med SHA1 er 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 og
1qazXSW @ hashet med Whirlpool er 0bf7545b784665d23b9c174ca03688a405f05b048e9d6c49bfc2721a1fa872bbd6576273d002e56d7c2a9c378efe607af36eea9d708a776e6f60ecb26e081cdf .
Grundproblemet med alle disse adgangskoder, og milliarder mere som dem, er det faktum, at deres hyppigt anvendte hash er blevet almindeligt kendt.
En adgangskode salt ændrer det.
Hvis en tilfældig værdi (saltet) blev føjet til brugerens valgte adgangskode, så ville SHA1-hash 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 ikke længere afsløre P $$ @ som brugerens adgangskode, fordi hashværdien i regnbuetabellen ikke længere matcher den.
Og det tager ikke meget. En lille 16-bit tilfældig værdi vil for eksempel give 65.536 varianter af hver hashværdi i opslagstabellerne. Så en database med 15 milliarder poster ville nu have brug for over 983 milliarder hash i den for at tage højde for saltet.
Så det er meningen med at salte dine hashes for at modvirke opslag og regnbue borde. Men don “t hæng din hat på en saltet hash, fordi hackere ikke spilder meget tid på at bruge regnbueborde til at finde ud af dine adgangskoder.
De vil bruge en fem-server 25-GPU klyngesystem , der kører Hashcat, der kan brænde igennem 350 milliarder gætter pr. sekund ved at knække hashes for hver tænkelig adgangskode på otte tegn, der indeholder store og små bogstaver, tal og specialtegn på lidt under seks timer. (Og det var tilbage i 2012.)
Teknikker som nøgletrækning, der får hash til at køre langsommere, kan bruges til at udligne hastigheden på sådan hardware, hvilket gør ordbog og brutale kraftangreb for langsomme til at være umagen værd. , men hardware bliver bare hurtigere og hurtigere.
UPDATE 2018:
Nuværende bedste praksis inkluderer sikker hashing af dine adgangskoder med Argon2i (foretrukket frem for scrypt), en hukommelseshård funktion, der er meget modstandsdygtig over for FPGAer, GPUer med flere kerner og dedikerede ASIC-moduler, der bruges til let at knække ikke-strakte adgangssætninger. I PHP7 implementeringen af Argon2 håndteres saltet internt for dig.
Svar
Jeg vil forsøge at besvare en del af dit spørgsmål, der indtil videre er forsømt:
når jeg muligvis har brug for det, og hvorfor jeg skal / ikke skal bruge det.
Det korte svar er, at du som amatør ikke skal bruge kryptografi på et niveau, der kræver direkte håndtering af salte.
For eksempel bcrypt algoritme til hash-adgangskode bruger salte internt. Men det udsætter ikke denne kendsgerning for udviklere, der bruger den – du sender blot adgangskoden til bcrypt (og eventuelt en parameter, der indstiller “niveau CPU-indsats “nødvendig for at generere hash), og det returnerer hash. Når du skal validere, hvis en adgangskode er korrekt, sender du bcrypt både adgangskoden og den tidligere genererede hash. Det vil angive, om adgangskoden var den, der blev brugt til at generere hash.
Tag ikke rådgivningen her og prøv at hash dine egne adgangskoder ved hjælp af et salt. Det er en implementeringsdetalje på lavt niveau, og hvis du finder dig selv at arbejde på et niveau, hvor der er brug for denne slags ting, arbejder du på et alt for lavt abstraktionsniveau. Kryptografi er meget vanskeligt at gøre korrekt, og Internettet er absolut fyldt med velmenende udviklere “helt usikre hjemmevoksede hash-ordninger med adgangskode.
Svar
Citering “ Eksamen Ref 70-486 Udvikling af ASP.NET MVC 4 webapplikationer (MCSD): Udvikling af ASP.NET MVC 4 webapplikationer ” af William Penberthy, Pearson Education, 15. september 2013:
Saltning er en proces, der styrker filkryptering og hash, hvilket gør dem sværere at bryde. Salting tilføjer en tilfældig streng til begyndelsen eller slutningen af inputteksten før hashing eller kryptering af værdien. Når man f.eks. forsøger at bryde en liste over adgangskoder, skal hackere tage højde for saltet samt mulige adgangskodeoplysninger, før de kan bryde i hver applikation. Hvis hver værdi, der saltes, tildeles en anden saltværdi, kan evnen til at oprette en tabel med potentielle adgangskodeværdier til et pa ssword-cracking-program bliver uhåndterligt.
Svar
Et salt er et tilfældigt nummer, der er nødvendigt for at få adgang til de krypterede data sammen med adgangskoden.
Hvis en angriber ikke kender adgangskoden og forsøger at gætte det med et brutalt kraftangreb, så hver adgangskode, han prøver skal prøves med hver saltværdi.
Så for et en-bit salt (0 eller 1) gør dette krypteringen dobbelt så svært at bryde på denne måde. Et to-bit salt gør det fire gange så hårdt, et tre-bit salt otte gange så hårdt osv. Du kan forestille dig, hvor svært det er at knække adgangskoder med kryptering, der bruger et 32-bit salt!
Kommentarer
- Nej Salt antages normalt at være kendt af angriberen. I dette tilfælde forbedrer salt forbi nogle lave tærskler ikke sikkerheden.
- ” Salt antages normalt at være kendt for angriberen ” – > Hvem antager dette?
- @Mike: Hvem? Nogen siger ” Du skal altid antage, at angriberen kender saltet. “. Folk på en anden side siger ” Salte er offentlige “, og senere siger ” saltene er kendt, fordi at ‘ er industristandard brug af ordet salt. ” En anden siger ” saltet er offentligt kendt eller skal i det mindste behandles som offentligt viden. “.