Hvordan vi beskytter passordene dine

I de forrige artiklene utforsket vi hvordan HTTPS beskytter ruten mellom appen din og vår server, og hvordan SSH sikrer selve serveren. Nå er det på tide å se inne i serveren — på hvordan Splync holder passordet ditt trygt når det har kommet dit. Hvis noen skulle få tak i passordet ditt, kunne den personen logge inn på kontoen din og få tilgang til sensitiv informasjon, inkludert dine utgiftsoppføringer. Derfor lagrer Splync aldri passord i klartekst. I stedet blir hvert passord omgjort til en hashet versjon før det lagres i databasen. Hva betyr det egentlig? Hashing er en enveiskonvertering — når det først er omgjort, kan det aldri gjøres om til det opprinnelige passordet. Denne metoden er standard over hele internett, fra banker til store skytjenester, men mange vet ikke hvordan det faktisk fungerer. La oss utforske det gjennom en enkel dagligdags analogi.

For å forstå hvordan passordbeskyttelse fungerer, la oss starte med en enkel hashingmetode kalt SHA-256. Tenk på det som en blender som alltid blander ingrediensene på nøyaktig samme måte. Hvis du legger inn det samme passordet i blenderen og trykker på knappen, vil du alltid få den samme unike smoothien — en kryptert blanding av bokstaver og tall. Hovedideen er at prosessen ikke kan reverseres. Akkurat som du ikke kan ta en smoothie og skille den tilbake til den opprinnelige bananen og melken, kan du ikke ta den krypterte hashen og gjenvinne det opprinnelige passordet.

SHA-256 er en av de mest vanlige hashing-algoritmene. For eksempel, den hasher passordet "splync1234" til “9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41”. På millisekunder, hver gang en eksisterende bruker taster inn et innloggingspassord, produserer SHA-256 alltid det samme hash-passordet. Appen hasher ganske enkelt det innskrevne passordet igjen og sjekker om det stemmer med den lagrede hashen. Systemet kjenner aldri til brukerens opprinnelige passord. Men hva om en angriper forhåndsberegner en liste over vanlige passord og deres hasher (kjent som et rainbow table-angrep) for raskt å gjette brukernes passord? Den bekymringen er svært reell. Dette er grunnen til at moderne systemer, inkludert Splync, ikke stoler på vanlig SHA-256.

Bcrypt bruker en tilfeldig salt per bruker og koder denne salten (og kostfaktoren) direkte i den lagrede hash-strengen. Tenk på bcrypt som en blender med en hemmelig krydder (salt) og en treg motor (arbeidsfaktor) — det gjør hver blanding unik og vanskeligere å kopiere. Fordi salten er 128 bits (≈3×10³⁸ muligheter), kan det samme passordet mappe til et astronomisk stort antall forskjellige lagrede hasher. Det gjør forhåndsberegnede rainbow-tabeller ubrukelige i stor skala. Under innlogging leser Splync salten og kostnaden fra den lagrede bcrypt-strengen, kjører bcrypt på nytt på det angitte passordet med disse parameterne, og sammenligner resultatet med den lagrede hashen. Hvis de stemmer, er passordet korrekt — men fordi bcrypt er med vilje langsom og saltene er unike, blir brute-force-angrep mye dyrere for en angriper.

La oss se hvordan dette ser ut i praksis. Hvis du hasher passordet "splync1234" med bcrypt (med kostnad 12), kan du få en streng som denne: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. I denne bcrypt-strengen markerer `$2b` algoritmeversjonen, `$12` viser kostfaktoren (hvor mange ganger passordet behandles), `gBeouKYdue9uvvuV0HtGgeV` er den unike tilfeldige salten, og `PymnrojMqP/wcRw28HFlGEGIQbyw7O` er det endelige hash-passordet. Fordi hashen selv inneholder salten og kostnaden, kan Splync reprodusere den samme hash-prosessen for verifisering ved å hente disse verdiene fra den lagrede strengen og sammenligne resultatet. På den annen side, hvis en angriper ikke kjenner salten og kostnaden, kan de ikke bygge en enkelt rainbow-tabell som fungerer for alle brukere.

Denne metoden har en annen viktig fordel. Fordi Splync aldri lagrer enkle passord, er brukerne ikke umiddelbart i fare selv om databasen skulle lekke eller bli stjålet. Angripere kan ikke logge inn direkte med de stjålne dataene, fordi det de har, kun er krypterte strenger. Dette designet gir brukerne et ekstra beskyttelseslag, i tillegg til de beskyttelsene som allerede finnes rundt selve serveren. Passordhashing er ikke unikt for Splync; det er standard i teknologiindustrien, brukt av giganter som Google, Apple og Amazon. Splync er bygget svært sikkert, og det vil bare bli tryggere etter hvert som vi fortsetter å forbedre sikkerheten med funksjoner som e-postbekreftelse, brute-force-beskyttelse og kontinuerlig overvåking.