La oss si at du oppretter en konto på VerySecureWebsite.com. Du skriver inn e-postadressen og passordet ditt og konfigurerer kontoen. En liten stund senere mottar du en e-post som informerer deg om at, ironisk nok, nettstedet er blitt hacket, og brukernavnene og passordene til hver bruker, som ble lagret i ren tekst, nå er til salgs på det mørke nettet. Mens du begynner å endre passordet på alle kontoene dine (du bruker bare ett, du monster), lurer du på, “Er det ikke en dårlig idé? Bør ikke passordet mitt være i en slags hemmelig kode, slik at hackere ikke bare kan lese det?”
Du har rett. Enhver webapp eller tjeneste som bruker et brukernavn / passord påloggingssystem, bør lagre brukernes passord ved hjelp av en saltet hash, muligens til og med en saltet sakte hash, kanskje med en pepper. Hvis dette begynner å høres mer ut som frokost enn kryptografi, ikke bekymre deg: i motsetning til passordet ditt (forhåpentligvis), er sikker lagring av passord ikke så vanskelig for et emne å knekke.
Vanlig tekst og grunnleggende kryptering
| Brukernavn | Angitt passord | Lagret form |
|---|---|---|
| UnwittingUser | Svakt passord | Svakt passord |
Å lagre passord med ren tekst i en Internett-tilkoblet database er en ganske dårlig idé: hvis databasen blir hacket, er nå noen som har brukt et av disse passordene i fare. Og fortsatt et urovekkende antall nettsteder gjør det fortsatt, sannsynligvis fordi sikkerhetsoppgraderinger er mer for kunden enn selskapet. Hvis du vil teste om et nettsted gjør dette, kan du prøve å velge alternativet «glemt passord». Hvis de bare sender deg passordet ditt i stedet for en tilbakestillingskobling, blir det lagret i ren tekst.
| Brukernavn | Oppgitt passord | Kryptert med AES-128 Key: WeakKey |
|---|---|---|
| UnwittingUser | Svakt passord | 38MkoXVXoKe01uAOROBLpQ == |
Kryptering kan høres ut som en sterk måte å lagre passord på, men det er egentlig bare et trinn over ren tekst. Et kryptert passord kan vanligvis dekodes med en nøkkel, og hvis hackerne kan finne eller gjette det, er krypteringen ubrukelig.
Hashing> kryptering
| Brukernavn | Oppgitt passord | Streng som skal hases | Hashed med SHA-256 |
|---|---|---|---|
| UnwittingUser | Svakt passord | Svakt passord | 252E2406732308F9A7 B378ED94E78467D14 077D19C8282443FCD 3D6190FCABFA |
En hash-funksjon er i utgangspunktet bare enveiskryptering: du konverterer vanlig tekstpassord til en hemmelig kode, men det er ingen nøkkel til å konvertere det tilbake, noe som betyr at du aldri kan utlede det faktiske passordet fra den hashede versjonen.
Slik administrerer de fleste sikre nettsteder passordene sine:
- Brukeren oppretter en konto
- Brukerens passord kjøres gjennom hash-funksjonen og lagres i databasen
- Hver gang brukeren logger på, hash databasen passordet de skrev inn og sjekker om den angitte hashen samsvarer med hashen de har på filen.
- Hvis ja, kan brukeren logge på
Med en hash lagrer appen / nettstedet aldri ditt faktiske passord hvor som helst, og en hacker som bryter inn vil bare få en liste over bokstaver og tall som ikke kan dekodes. Avhengig av hvor sterk algoritmen er, kan disse hashene være ganske vanskelig å knekke.
Hashes er ikke hacktett, skjønt. Alt en angriper må gjøre er å kjøre en ordbok med potensielle passord gjennom hash-funksjonen, og deretter sammenligne disse hasjene med hasjene i databasen. Når to hashes samsvarer, kan hackeren bare se på hvilket passord som genereres som hash.
For å spare tid og datakraft, bruker mange angripere bare en oppslagstabell (eller et «regnbuetabell», en plassbesparende versjon av oppslagstabeller), en forhåndsgenerert tabell full av potensielle passord og deres hashes. Du kan faktisk prøve hashing et ord med ren tekst og så bruk et oppslagstabell på hasjen deg selv; det er ikke så vanskelig. I hovedsak, hvis passordet ditt i det hele tatt er vanlig, er hash av passordet sannsynligvis allerede i en oppslagstabell. Dette er en god grunn til ikke å bruke vanlige passord.
Saltede hasjer> hasjer
| Brukernavn | Angitt passord | Streng som skal hases | Hashed med SHA-256, salt = XcyKn42, prepended |
|---|---|---|---|
| UnwittingUser | Svakt passord | XcyKn42WeakPassword | 13EB660FF7FBD29A728FC5 92297D78DF19AFF8797363 15FBF1F1C4B7123BD10C |
I motsetning til snegler gjør salt hash sterkere. Siden hele hash endres, selv om bare en bokstav i ordet klartekst endres, trenger alt et nettsted å gjøre for å folie oppslagstabeller, å legge til litt ekstra ren tekst i passordet før det er hash. Angriperen vil kunne lese saltet i ren tekst siden det er lagret i databasen, men det tvinger dem til å beregne alle mulige kombinasjoner av potensielle passord og salter.
Selvfølgelig kan saltede hasjer fortsatt knekkes. Hackere kan bare tilsette saltet i passordet de gjetter på, hash kombinasjonen og vente på at kampene dukker opp – et standard ordbokangrep. Siden moderne GPUer kan gi milliarder gjetninger per sekund, er dette ikke mulig, men det gjør prosessen mye mer irriterende. Hvis det ikke lykkes, er brute-force-angrep sakte, men veldig effektive.
Gjør hashes enda sterkere: annen taktikk
| Brukernavn | Oppgitt passord | Streng som skal hases | Hashed med Bcrypt, salt = XcyKn42, prepended, 12 runder |
|---|---|---|---|
| UnwittingUser | Svakt passord | XcyKn42WeakPassword | $ 2y $ 12 $ 6OleutQBO2iPoNvg pyDndOU26Lqt9Y34f6PLEOx mCELP5GoswrJT. |
Langsomme hashingalgoritmer, som PBKDF2 eller bcrypt, bruker en teknikk kjent som «nøkkelstrekking» for å bremse ordbok og brute force-angrep. Dette innebærer egentlig å sette hash-funksjonen til å gjenta et visst antall ganger (selv om det er litt mer komplisert enn å bare kjøre det samme om og om igjen), slik at du må bruke mye databehandling for å nå riktig hash makt. Hvis et nettsted gjør alt dette, er sikkerheten deres ganske god.
| Brukernavn | Angitt passord | Streng som skal hases | Hashed med Bcrypt, salt = XcyKn42, prepended, 12 runder, pepper = | 4 | / | @ p3pp3r, vedlagt |
|---|---|---|---|
| UnwittingUser | Svakt passord | XcyKn42WeakPassword | 4 | / | @ p3pp3r | $ 2y $ 12 $ njmWr5UMydCzdCE44ElW / OIfYp2PH9sgonCATyVY.OVKSpmoSaZlu |
For ekstra sikkerhet kan du også «pepper» hasjene dine – som forhåpentligvis allerede er saltet. En pepper, som et salt, er et sett med verdier som er knyttet til passordet før det blir hash. I motsetning til et salt er det imidlertid bare en pepperverdi, og den holdes hemmelig, atskilt fra saltene og hasjene. Det legger til et nytt sikkerhetslag til den saltede hasjen, men hvis angriperen klarer å finne den, er den ikke lenger veldig nyttig siden angriperen bare kan bruke den til å beregne nye oppslagstabeller.
Ikke lag en hasj av hasjen din
Passordsikkerhet har gjort noen store fremskritt – og det samme har kunsten å knekke den sikkerheten. Dessverre er mennesker fortsatt dårlige i passordadministrasjon, og databaser oppgraderer ikke sikkerheten så ofte som de burde. Anta generelt at når du oppretter en konto, blir passordet lagret med relativt svak sikkerhet. Hvis passordet ditt er vanlig eller et ordboksord, har det ganske stor risiko for å bli sprukket. Gjør passordene dine lange, blander bokstaver, tall og symboler, så hjelper du hashfunksjoner med å gjøre sitt beste.
Bildekreditter: Hash-funksjon