Kuinka suojaamme salasanasi

Aiemmissa artikkeleissa käsittelimme, kuinka HTTPS suojaa yhteyden sovelluksesi ja palvelimemme välillä ja kuinka SSH turvaa itse palvelimen. Nyt on aika katsoa palvelimen sisälle — kuinka Splync turvaa salasanasi sen saavuttua sinne. Jos joku saisi salasanasi haltuunsa, hän voisi kirjautua tilillesi ja päästä käsiksi arkaluontoisiin tietoihin, kuten kulutustietoihisi. Siksi Splync ei koskaan tallenna salasanoja suoraan. Sen sijaan jokainen salasana muunnetaan hajautetuksi versioksi ennen tallennusta tietokantaan. Mitä tämä tarkalleen tarkoittaa? Hajautus on yksisuuntainen muunnos — kun se on muunneltu, sitä ei voi koskaan palauttaa alkuperäiseksi salasanaksi. Tämä menetelmä on standardi koko internetissä, pankeista suuriin pilvipalveluihin, mutta monet eivät tiedä, kuinka se oikeasti toimii. Perehdytään siihen yksinkertaisen arkipäiväisen vertauksen kautta.

Jotta voimme ymmärtää, miten salasanojen suojaus toimii, aloitetaan yksinkertaisesta hajautusmenetelmästä nimeltä SHA-256. Ajattele sitä tehosekoittimena, joka sekoittaa ainekset aina täsmälleen samalla tavalla. Jos laitat saman salasanan sekoittimeen ja painat nappia, saat aina samanlaisen ainutlaatuisen smoothien — kirjain- ja numerosekoituksen. Tärkeintä on, ettei prosessia voi kääntää. Aivan kuten et voi ottaa smoothieta ja erottaa siitä alkuperäisiä banaaneja ja maitoa, et voi ottaa hajautettua sekoitusta ja palauttaa alkuperäistä salasanaa.

SHA-256 on yksi yleisimmistä hajautusalgoritmeista. Esimerkiksi se hajauttaa salasanan "splync1234" muotoon “9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41”. Millisekunneissa, aina kun olemassaoleva käyttäjä syöttää kirjautumissalasanan, SHA-256 tuottaa aina saman hajautetun salasanan. Sovellus yksinkertaisesti hajauttaa syötetyn salasanan uudelleen ja tarkistaa, vastaako se tallennettua hajautetta. Järjestelmä ei missään vaiheessa tiedä käyttäjän alkuperäistä salasanaa. Mutta entä jos hyökkääjä esilaskisi listan yleisistä salasanoista ja niiden hajautuksista (tunnetaan nimellä rainbow table -hyökkäys) arvaten nopeasti käyttäjien salasanoja? Tämä huoli on hyvin todellinen. Siksi modernit järjestelmät, mukaan lukien Splync, eivät luota pelkkään SHA-256:een.

Bcrypt käyttää satunnaista käyttäjäkohtaista suolaa ja koodaa sen (ja kustannustekijän) suoraan tallennettuun hajautteeseen. Ajattele bcryptiä tehosekoittimena, jossa on salainen mauste (suola) ja hidas moottori (työkerroin) — se tekee jokaisesta sekoituksesta ainutlaatuisen ja vaikeamman kopioida. Koska suola on 128 bittiä (≈3×10³⁸ mahdollisuutta), sama salasana voi kartoitua valtavaan määrään erilaisia tallennettuja hajautuksia. Tämä tekee esilasketuista rainbow tableista käyttökelvottomia suuressa mittakaavassa. Kirjautumisen yhteydessä Splync lukee suolan ja kustannukset tallennetusta bcrypt-merkkijonosta, ajaa bcryptin uudelleen syötetyn salasanan kanssa näillä parametreilla ja vertaa tulosta tallennettuun hajautteeseen. Jos ne täsmäävät, salasana on oikea — mutta koska bcrypt on tarkoituksella hidas ja suolat ovat ainutlaatuisia, bruteforce-hyökkäykset tulevat paljon kalliimmiksi hyökkääjälle.

Katsotaan, miltä tämä näyttää käytännössä. Jos hajautat salasanan "splync1234" bcryptillä (käyttäen kustannusta 12), saatat saada esimerkiksi tällaisen merkkijonon: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. Tässä bcrypt-merkkijonossa `$2b` merkitsee algoritmin versiota, `$12` näyttää kustannustekijän (kuinka monta kertaa salasana prosessoidaan), `gBeouKYdue9uvvuV0HtGgeV` on ainutlaatuinen satunnainen suola, ja `PymnrojMqP/wcRw28HFlGEGIQbyw7O` on lopullinen hajautettu salasana. Koska hajautteessa itsessään on suola ja kustannukset, Splync voi toistaa saman hajautusprosessin tarkistusta varten vetämällä nämä arvot tallennetusta merkkijonosta ja vertaamalla tulosta. Toisaalta, jos hyökkääjä ei tunne suolaa ja kustannuksia, he eivät voi rakentaa yhtä rainbow tablea, joka toimisi kaikille käyttäjille.

Tällä lähestymistavalla on toinenkin tärkeä etu. Koska Splync ei koskaan tallenna suoria salasanoja, vaikka tietokanta vuotaisi tai varastettaisiin, käyttäjät eivät ole välittömässä vaarassa. Hyökkääjät eivät voi kirjautua suoraan varastetuilla tiedoilla, koska heillä on vain sekavia merkkijonoja. Tämä suunnittelu antaa käyttäjille ylimääräisen suojakerroksen palvelimen ympärillä jo olevien turvatoimien lisäksi. Salasanojen hajautus ei ole ainutlaatuista Splyncille; se on standardi teknologiateollisuudessa, ja sitä käyttävät jättiläiset kuten Google, Apple ja Amazon. Splync on rakennettu erittäin turvallisesti, ja se tulee vain turvallisemmaksi, kun jatkamme turvallisuuden parantamista sähköpostivarmennuksella, bruteforce-suojauksella ja jatkuvalla valvonnalla.