- 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-hasher . Det er et av de konseptene som nevnes mye, men ofte bare delvis forstått: det høres teknisk ut, men i virkeligheten utgjør det forskjellen mellom et system som er lett å knekke og et som er mye mer motstandsdyktig mot angrep.
Kort sagt, saltet er en nøkkelkomponent i å gjøre passord-hasher uforutsigbare . Det innebærer å legge til tilfeldige data før hashing-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 skal utforske i detalj.
Hva er egentlig saltet i en passord-hash?
I kryptografi er et salt 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 salt , kombinerer det med passordet (før, etter eller i et bestemt format avhengig av skjemaet), og bruker en hash-algoritme, for eksempel SHA-256 eller SHA-512 , på denne kombinasjonen . Databasen lagrer ikke selve passordet, men snarere hashen til (password + salt) , og i de fleste skjemaer lagres også saltet sammen med hashen.
Denne teknikken gjør mange angrepsteknikker basert på forhåndsberegnede hasher , som regnbuetabell, ubrukelige, og kompliserer storskala ordbok- og brute-force-angrep i stor grad. En angriper kan ikke lenger utnytte det faktum at flere brukere deler et passord, fordi hver bruker vil ha en annen hash.
Det er viktig å forstå at saltet ikke er en hemmelighet i seg selv: det er verken et passord eller en privat nøkkel . Funksjonen er å introdusere tilfeldighet og unikhet i hashingprosessen. Sikkerhet avhenger fortsatt av bruk av sterke passord og passende hashingalgoritmer , helst designet spesielt 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 rekke ganske enkle trinn, men med stor innvirkning på sikkerheten :
For det første, når en bruker registrerer eller endrer passordet sitt, genererer systemet et unikt, tilfeldig salt for den påloggingsinformasjonen. Dette saltet er vanligvis av tilstrekkelig lengde (for eksempel 16 byte eller mer) og hentes fra en kryptografisk sikker tilfeldig tallgenerator.
Deretter kombineres brukerens valgte passord med salt-tegnet for å danne en mellomliggende streng . Denne 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.
Deretter brukes en enveis hash-algoritme på den kombinasjonen . Resultatet er en tilsynelatende tilfeldig streng, hashen, med fast lengde, som lagres i databasen sammen med saltet. I moderne systemer søkes det etter algoritmer som produserer lange og komplekse resultater , noe som øker søkeområdet og gjør brute-force-angrep dyrere.
Til slutt, når brukeren logger seg inn, henter systemet det oppgitte passordet igjen, henter det tilhørende saltet fra databasen, gjentar nøyaktig den samme kombinerings- og hashprosessen, og sammenligner resultatet med den lagrede hashen. Hvis de samsvarer, vet systemet at passordet er riktig uten å måtte se klarteksten.
Denne mekanismen betyr at selv om databasen lekker, vil angriperen bare se individuelle hasher med sine egne salts , i stedet for et sett med sammenlignbare hasher. Å stoppe et angrep er ikke magi, men det blir betydelig dyrere beregningsmessig.
Fordeler med å bruke salt i passord-hasher
Hovedgrunnen til å bruke salting er at det styrker sikkerheten til lagrede passord mot en rekke angrep. Men det er verdt å detaljere de spesifikke fordelene.
For det første gir salting motstand mot ordbokangrep . Uten salt kan en angriper lage en enorm liste over vanlige passord og deres hasher, og ganske enkelt sammenligne dem med den stjålne databasen. Med et unikt salt per bruker blir disse forhåndsberegnede hashene ubrukelige, fordi hver passord + salt-kombinasjon genererer en annen verdi.
For det andre ødelegger bruken av salt effektiviteten til regnbuetabeller , som rett og slett er forhåndsberegnede databaser med hasher av populære passord designet for å fremskynde gjenoppretting. Igjen, siden resultatet avhenger av det spesifikke saltet, blir disse tabellene, som er ment for usaltede hasher, ubrukelige eller i det minste svært ineffektive.
En annen klar fordel er forbedret personvern i tilfelle datainnbrudd . Selv om en inntrenger får tilgang til brukertabellen med hash og salt, vil de ikke raskt kunne identifisere hvem som deler samme passord eller enkelt iverksette masseangrep. Hver konto krever individuell oppmerksomhet, noe som ofte er upraktisk i stor skala.
Videre gjør salting brute-force-angrep mer komplekse . I stedet for å kunne teste et kandidatpassord mot alle hash-koder samtidig, blir angriperen tvunget til å vurdere hver brukers salt-kode, og dermed multiplisere den totale innsatsen. 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, opprettholder kombinasjonen av en robust hash og et unikt salt et høyt og skalerbart vanskelighetsnivå: saltlengden kan økes, algoritmen styrkes, beregningskostnaden økes og så videre.
Hvordan Linux implementerer passordsalting (/etc/shadow)
I Linux-systemer og andre *NIX-varianter lagres ikke brukerpassord i /etc/passwd, men i /etc/shadow- filen . Denne filen, som kun er tilgjengelig for superbrukeren, lagrer passord-hasher sammen med tilleggsinformasjon, og det er der bruken av salt og hashing-algoritmen tydelig sees.
Linjene i /etc/shadow har en struktur som ligner på:
bruker:$id$sal$hash:ekstra_felt…
Dollartegnet ($) skiller de ulike delene. Den første delen etter brukernavnet indikerer typen algoritme som brukes. For eksempel representerer $1$ 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 algoritmidentifikatoren kommer saltet , etterfulgt av den resulterende hashen . Alt dette finnes i samme felt. Når et passord valideres, leser systemet denne identifikatoren og saltet, bruker algoritmen som tilsvarer det angitte passordet, og sammenligner den beregnede hashen med den lagrede.
For raskt å sjekke hvilke brukere som har krypterte passord og hvilken algoritme som brukes, kan du bruke en kommando som `grep '\$' /etc/shadow` . I 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 slutten på en linje.
Passordløse eller låste kontoer viser vanligvis en verdi som ! eller * i det feltet i stedet for en hash med dollartegn, noe som indikerer at autentisering med et standardpassord ikke er mulig. Denne strukturen gjør én ting klar: Linux integrerer salting i sitt passordlagringsformat.
Forskjellen mellom passord-hashing og salting
Det er viktig å skille mellom to konsepter som noen ganger forveksles: hashing og salting . Passordhashing 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 det produserer den samme hashen.
Problemet er at hvis to passord er identiske, vil også de usaltede hashene deres være identiske . Dette lar en angriper sammenligne dem, gruppere brukere etter passord eller bruke forhåndsberegnede tabeller. Videre, 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 denne svakheten: det innebærer å legge til tilfeldige data til passordet før det hashes. Resultatet er at selv om to brukere velger "casa" som passord, vil hashene i databasen være helt forskjellige, fordi den ene vil ha for eksempel "casa+7Ko#" og den andre "casa8p?M" som forhåndshashet streng.
Dermed konkurrerer ikke hashing og salting, men utfyller hverandre. Hashing gir egenskapen unidireksjonalitet og enkel verifisering, mens salting gir unikhet og motstand mot masseangrep . En sikker implementering av passordlagring kombinerer begge teknikkene, ideelt sett ved hjelp av en algoritme designet for dette formålet, med en konfigurerbar kostnad.
Bruke salt i Linux med mkpasswd
I GNU/Linux-miljøer og andre Unix -lignende systemer er en veldig praktisk måte å eksperimentere med passordsalting med verktøyet mkpasswd . Denne kommandoen brukes til å generere sikre , krypterte passord og er ofte integrert i brukeropprettelsesprosesser, administrasjonsskript og så videre.
Den grunnleggende syntaksen til `mkpasswd` lar deg spesifisere passordet som skal krypteres og en rekke alternativer, som algoritmetypen (for eksempel `des`, `md5`, `sha-256`, `sha-512`) ved å bruke `-m`- alternativet . På moderne systemer anbefales det å velge minst SHA-512 , eller enda mer robuste ordninger hvis distribusjonen støtter dem.
Det spesielt interessante alternativet i forbindelse med salting er -S , som lar deg legge til et salt til passordet før det krypteres. Hvis ikke spesifisert manuelt, kan mkpasswd generere et tilfeldig salt ved hver utførelse , så selv om du bruker samme inputpassord, vil den resulterende hashen være 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 å forberede saltede krypterte passord for å 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.