- Saltet er en tilfeldig streng som legges til passordet før hashen for å oppnå unike hasher per bruker.
- Linux Den lagrer hash, salt og algoritme i /etc/shadow, noe som styrker sikkerheten mot ordbokangrep og regnbuetabell.
- God praksis krever lange, tilfeldige og unike salter, sammen med robuste hashalgoritmer og databaser godt beskyttet.
- Passordsalting bør integreres i bredere sikkerhetspolicyer som inkluderer sterke passord, MFA og passordadministratorer.
Hvis du jobber med GNU/Linux-systemer eller bare er bekymret for sikkerheten til kontoene dine, har du sannsynligvis hørt om salt i passord-hashenDet er et av de konseptene som nevnes mye, men ofte bare er halvveis forstått: det høres teknisk ut, men i virkeligheten utgjør det forskjellen mellom et system som er lett å bryte og et som er mye mer motstandsdyktig mot angrep.
Kort sagt, salt er en Nøkkelelement for å gjøre passord-hasher uforutsigbareDet fungerer ved å legge til tilfeldige data før hash-algoritmen brukes, slik at selv om to brukere har samme passord, vil resultatet som er lagret i databasen være forskjellig. Derfra er den spesifikke implementeringen i Linux, forholdet til /etc/shadow, verktøy som mkpasswd og moderne sikkerhetspraksis en hel verden i seg selv, som vi vil utforske i detalj.
Hva er egentlig saltet i en passord-hash?
I kryptografi, en salt (salt) er en tilfeldig tegnstreng som legges til brukerens passord før en hash-funksjon brukes. Målet er at den resulterende hashen skal være unik selv om passordet i klartekst er det samme for flere brukere.
Når en bruker oppretter eller endrer passordet sitt, genererer systemet et tilfeldig saltDen kombinerer det med passordet (før, etter eller i et bestemt format avhengig av skjemaet) og bruker en hash-algoritme på den kombinasjonen, for eksempel SHA-256 o SHA-512Passordet lagres ikke i databasen, men snarere hash av (passord + salt), og i de fleste ordninger lagres også selve saltet sammen med hasj.
Denne teknikken gjengir mange av angrepsteknikker basert på forhåndsberegnede hasher, som regnbuetabell, og kompliserer ordbok- og brute-force-angrep i stor skala. En angriper kan ikke lenger utnytte det faktum at flere brukere deler et passord, fordi hver enkelt vil ha en annen hash.
Det er viktig å forstå at salt ikke er en hemmelighet i seg selv: Det er ikke et passord eller en privat nøkkelFunksjonen er å introdusere tilfeldighet og unikhet i hashprosessen. Sikkerhet avhenger fortsatt av bruken av sterke passord y passende hash-algoritmer, helst spesielt utviklet for passord (som bcrypt, scrypt, Argon2), selv om mange klassiske Linux-systemer bruker varianter av SHA-256 eller SHA-512.
Slik fungerer passordsalting trinn for trinn
Saltingsprosessen kan oppsummeres i en serie ganske enkle trinn, men med en enorm innvirkning på sikkerheten:
For det første, når en bruker registrerer eller endrer passordet sitt, genererer systemet en unikt og tilfeldig salt for den legitimasjonen. Dette saltet er vanligvis av tilstrekkelig lengde (for eksempel 16 byte eller mer) og hentes fra en kryptografisk sikker tilfeldig tallgenerator.
Deretter kombineres passordet som brukeren har valgt med saltet for å danne en mellomkjedeDenne kombinasjonen kan være så enkel som å sette sammen salt + passord, eller den kan ha et mer komplekst format definert av hash-skjemaet. Det viktigste er at hver bruker ender opp med en annen kombinasjon.
Så, en enveis hash-algoritmeResultatet er en tilsynelatende tilfeldig streng, hashen, med fast lengde, som vil bli lagret i databasen sammen med saltet. I moderne systemer søkes det etter algoritmer som produserer lange og komplekse utgangerDette øker søkeområdet og gjør brute-force-angrep dyrere.
Til slutt, når brukeren logger inn, henter systemet det oppgitte passordet på nytt. assosiert salt Fra databasen gjentar den nøyaktig samme kombinerings- og hashingsprosessen og sammenligner resultatet med den lagrede hashen. Hvis de samsvarer, vet den at passordet er riktig uten å måtte vite klarteksten.
Denne mekanismen sikrer at selv om databasen lekker, vil angriperen bare se individuelle hasher med sine egne salterI stedet for et sett med sammenlignbare hasher, er det ikke magisk å stoppe et angrep, men det blir betydelig dyrere beregningsmessig.
Fordeler med å bruke salt i passord-hasher
Hovedgrunnen til å bruke salting er at styrker sikkerheten til lagrede passord mot et bredt spekter av angrep. Men det er verdt å spesifisere de spesifikke fordelene.
For det første gir salting motstand mot ordbokangrepUten salt kan en angriper lage en enorm liste over vanlige passord og deres hash-verdier, og ganske enkelt sammenligne dem med den stjålne databasen. Med en unik salt-verdi per bruker blir disse forhåndsberegnede hash-verdiene ubrukelige, fordi hver kombinasjon av passord og salt genererer en annen verdi.
For det andre bryter bruken av salt ned effektiviteten til regnbuebordDette er rett og slett forhåndsberegnede databaser med hasher for populære passord for å fremskynde gjenoppretting. Igjen, siden resultatet avhenger av det spesifikke saltet, blir disse tabellene som er designet for usaltede hasher ubrukelige eller i det minste svært ineffektive.
En annen klar fordel er at det forbedrer personvern i tilfelle lekkasjeSelv om en inntrenger får tilgang til brukertabellen med hash og salt, vil de ikke raskt kunne identifisere hvem som har samme passord som andre eller enkelt iverksette masseangrep. Hver konto krever individuell oppmerksomhet, noe som vanligvis er upraktisk i stor skala.
Dessuten gjør salting det mer komplisert brute force-angrepI stedet for å kunne teste et kandidatpassord mot alle hash-koder samtidig, blir angriperen tvunget til å vurdere hver brukers salt, og dermed multiplisere den totale arbeidsmengden. Hvis dette kombineres med en langsom og parameteriserbar hash-algoritme (som bcrypt eller Argon2), øker angrepskostnadene ytterligere.
Til slutt er salting en teknikk som tilpasser seg godt til teknologisk utvikling. Selv om datautstyret forbedres og nye angrep dukker opp, kombinasjonen av robust hasj og unikt salt Den opprettholder et høyt og skalerbart vanskelighetsnivå: du kan øke lengden på saltet, styrke algoritmen, øke beregningskostnadene osv.
Hvordan Linux implementerer passordsalting (/etc/shadow)
I Linux-systemer og andre *NIX-varianter lagres ikke brukerpassord i /etc/passwd, men i filen / etc / skyggeDenne filen, som kun er tilgjengelig for superbrukeren, lagrer passord-hashene sammen med tilleggsinformasjon, og det er der bruken av salt og hash-algoritmen tydelig sees.
Linjene i /etc/shadow har en struktur som ligner på:
bruker:$id$sal$hash:ekstra_felt…
Symbolet $ Skill de ulike delene. Den første delen etter brukernavnet angir type algoritme brukt. For eksempel, $ 1 $ representerer vanligvis MD5, $ 5 $ SHA-256 og $ 6 $ SHA-512, som er den vanligste algoritmen i moderne distribusjoner fordi den tilbyr større sikkerhet enn eldre ordninger basert på DES eller MD5.
Etter at algoritmeidentifikatoren vises salog så den resulterende hashAlt dette er innenfor samme felt. Når et passord valideres, leser systemet identifikatoren, saltet, bruker algoritmen som tilsvarer det angitte passordet, og sammenligner den beregnede hashen med den lagrede.
Hvis du raskt vil sjekke hvilke brukere som har krypterte passord og hvilken algoritme som brukes, kan du bruke en kommando som grep '\$' /etc/shadowI denne sammenhengen brukes dollartegnet ($) for å finne linjer med hasher i moderne format. Symbolet må escapes med en omvendt skråstrek fordi det i regulære uttrykk betyr "slutt på linje".
Kontoer uten passord eller låste kontoer viser vanligvis en verdi som denne i det feltet. ! o * i stedet for en hash med dollar, som indikerer at den ikke kan autentiseres med et standardpassord. Denne strukturen gjør én ting klar: Linux integrerer salting i formatet sitt av lagring passord innfødt.
Forskjellen mellom passord-hashing og salting
Det er viktig å skille tydelig mellom to konsepter som noen ganger blandes sammen: hashing y saltingPassord-hashing er prosessen der et passord transformeres til en ugjenkjennelig verdi ved hjelp av en enveisalgoritme. Serveren trenger aldri å vite det opprinnelige passordet, bare for å bekrefte at brukeren vet riktig passord fordi den produserer den samme hashen.
Problemet er at hvis to passord er identiske, Usaltet hasj vil også være identiskDette lar en angriper sammenligne og gruppere brukere etter passord eller bruke forhåndsberegnede tabeller. Dessuten, hvis hash-algoritmen er rask og designet for dataintegritet (som enkel SHA-256), blir den mer sårbar for massive brute-force-angrep.
Salting kommer nettopp inn for å løse den svakheten: det handler om legg til tilfeldige data i passordet før den hashes. Resultatet er at selv om to brukere velger «casa» som passord, vil hash-verdiene i databasen være helt forskjellige, fordi den ene vil ha for eksempel «casa+7Ko#» og den andre «casa8p?M» som pre-hash-streng.
Dermed konkurrerer ikke hashing og salting, men utfyller hverandre. Hashing gir ensrettethetsegenskap og enkel verifisering; saltet gir unikhet og motstandskraft mot massive angrepEn implementering av sikker passordlagring kombinerer begge teknikkene, ideelt sett ved bruk av en algoritme designet for dette formålet, med konfigurerbare kostnader.
Bruke salt i Linux med mkpasswd
I GNU/Linux-miljøer og andre systemer UnixEn veldig praktisk måte å eksperimentere med salting på er verktøyet mkpasswdDenne kommandoen brukes til å generere krypterte passord sikkert, og er vanligvis integrert i brukeropprettelsesprosesser, administrasjonsskript osv.
Den grunnleggende syntaksen til mkpasswd lar deg spesifisere passordet som skal krypteres og en rekke alternativer, som for eksempel algoritmetypen (for eksempel des, md5, sha-256, sha-512) ved å bruke alternativet -mI moderne systemer er det fornuftige å velge SHA-512 som et minimum, eller ved enda mer robuste ordninger hvis distribusjonen støtter dem.
Det spesielt interessante alternativet i forbindelse med salting er -S, som tillater tilsett salt til passordet før det krypteres. Hvis det ikke spesifiseres manuelt, kan mkpasswd generere en tilfeldig salt i hver utførelseslik at selv om du bruker samme innloggingspassord, er den resulterende hashen forskjellig hver gang.
Dette kan enkelt bekreftes: hvis du krypterer «password123» flere ganger med mkpasswd, bruker SHA-512 og et tilfeldig salt, vil du få helt forskjellige hasher. Men hvis du sender den samme saltverdien med -S, vil hashen alltid være identisk, fordi kombinasjonen av passord + salt ikke endres.
Takket være dette verktøyet er det veldig enkelt Klargjør passord kryptert med salt å legge til i konfigurasjonsfiler, administrere brukere manuelt eller teste saltingsatferd uten å måtte programmere noe.
Lidenskapelig forfatter om verden av bytes og teknologi generelt. Jeg elsker å dele kunnskapen min gjennom å skrive, og det er det jeg skal gjøre i denne bloggen, vise deg alle de mest interessante tingene om dingser, programvare, maskinvare, teknologiske trender og mer. Målet mitt er å hjelpe deg med å navigere i den digitale verden på en enkel og underholdende måte.