Miltä salasanan hajautus oikeasti suojaa

Lyhyt versio

Salasanan hajautus suojaa käyttäjiä silloin, kun salasanatietokantasi varastetaan.

Se on sen päätehtävä. Ei ainoa yksityiskohta, ei koko tietoturvamalli, mutta keskeinen syy siihen, miksi hajautamme salasanat emmekä tallenna niitä suoraan.

Oikein hajautettu salasana on vaikea palauttaa alkuperäiseen muotoonsa. Jos hyökkääjä saa kopion käyttäjätaulustasi, hänen ei pitäisi heti saada tietää, että Alicen salasana on Spring2026!. Sen sijaan hän saa tallennetun hajautusarvon, jonka testaaminen arvauksia vastaan vaatii aikaa, rahaa ja laitteistoa.

Tällä erolla on merkitystä. Salasanan hajautuksen ei ole tarkoitus tehdä kirjautumisesta yksinään turvallista. Se ei pysäytä tietojenkalastelua. Se ei estä ketään kokeilemasta vuotaneita salasanoja kirjautumislomakkeeseesi. Se ei suojaa istuntoevästettä kirjautumisen jälkeen. Se ostaa aikaa ja vähentää vahinkoa yhden hyvin tietyn epäonnistumisen jälkeen: salasanan tarkisteiden tallennus paljastuu.

Kun ymmärrät tämän rajan, teet parempia päätöksiä algoritmeista, kustannusparametreista, nollauksista, lokituksesta ja häiriötilanteisiin vastaamisesta.

Mikä salasanan hajautusarvo on

Salasanan hajautusarvo on yksisuuntaisen funktion tuotos, joka on laskettu salasanasta, yleensä yksilöllisen suolan ja tarkoituksella hitaan salasananhajautusalgoritmin kanssa.

Kun käyttäjä luo tilin, järjestelmän pitäisi tehdä suunnilleen näin:

1. Vastaanottaa salasana HTTPS:n yli.
2. Luoda satunnainen ja yksilöllinen suola.
3. Ajaa salasana ja suola salasananhajautusfunktion, kuten Argon2id, bcrypt, scrypt tai PBKDF2, läpi.
4. Tallentaa algoritmin nimi, parametrit, suola ja syntynyt hajautusarvo.
5. Hylätä alkuperäinen salasana.

Kun käyttäjä kirjautuu myöhemmin sisään, järjestelmä toistaa saman hajautusprosessin annetulla salasanalla ja tallennetuilla parametreilla. Jos syntynyt hajautusarvo vastaa tallennettua hajautusarvoa, kirjautuminen onnistuu.

Tärkeä kohta: sovelluksen ei tarvitse tietää alkuperäistä salasanaa. Sen tarvitsee vain varmistaa, että annettu salasana tuottaa odotetun tuloksen.

Siksi salasanojen tallentaminen palautettavalla salauksella on yleensä väärä malli. Jos sovelluksesi voi purkaa jokaisen salasanan, kuka tahansa purkuavaimen varastava voi tehdä saman. Salasanojen pitäisi normaalisti olla mahdottomia tarkistaa takaperin, ei vain piilotettuja.

Miltä hajautus suojaa

1. Välittömältä salasanojen paljastumiselta tietomurron jälkeen

Jos hyökkääjä varastaa tietokannan, joka sisältää selväkielisiä salasanoja, vahinko on välitön. Jokainen salasana paljastuu. Käyttäjät ovat vaarassa paitsi sinun sivustollasi myös kaikkialla, missä he ovat käyttäneet samaa salasanaa uudelleen.

Jos tietokanta sisältää hyvin hajautettuja salasanoja, hyökkääjällä on enemmän työtä tehtävänä. Hänen täytyy arvata ehdokassalasanoja, hajauttaa jokainen arvaus oikealla suolalla ja parametreilla ja verrata tulosta.

Heikkojen salasanojen kohdalla tämä voi silti olla nopeaa. Vahvojen ja yksilöllisten salasanojen kohdalla se voi olla käytännössä mahdotonta.

Hajautus muuttaa katastrofaalisen paljastumisen kilpajuoksuksi: ehtivätkö käyttäjät nollata salasanansa ja pystytkö rajaamaan häiriön ennen kuin hyökkääjät murtavat niistä monia?

Se ei ole täydellistä. Kyseessä on silti tietomurto. Mutta se on huomattavasti parempi epäonnistumistapa.

2. Massahyökkäyksiltä koko käyttäjäkuntaasi vastaan

Suolat ovat olennainen osa salasanojen tallennusta, koska ne estävät hyökkääjiä hyökkäämästä tehokkaasti monia käyttäjiä vastaan kerralla esilaskettujen taulukoiden avulla.

Suola ei ole salainen. Se tallennetaan hajautusarvon rinnalle. Sen tehtävä on yksilöllisyys.

Jos kaksi käyttäjää valitsee saman salasanan, yksilölliset suolat varmistavat, että heidän tallennetut hajautusarvonsa eroavat toisistaan. Se estää hyökkääjiä näkemästä yhdellä silmäyksellä, että monilla käyttäjillä on sama salasana. Se estää myös perinteiset rainbow table -hyökkäykset, joissa hyökkääjät käyttävät valtavia esilaskettuja listoja salasana–hajautusarvo-pareista.

Ilman suoloja yksi murrettu hajautusarvo voi paljastaa kaikki käyttäjät, joilla on sama salasana. Suolojen kanssa jokainen salasana-arvaus täytyy testata erikseen jokaiselle käyttäjälle.

3. Nopealta offline-arvailulta

Kun hyökkääjillä on salasanatietokanta, he voivat arvailla offline-tilassa. Se tarkoittaa, että kirjautumisen nopeusrajoitukset, CAPTCHA, IP-esto ja valvonta eivät enää merkitse. Hyökkääjä voi testata arvauksia omalla laitteistollaan.

Tässä algoritmin valinnalla on merkitystä.

Yleiskäyttöiset hajautusfunktiot, kuten SHA-256 ja SHA-512, on suunniteltu nopeiksi. Se on hyvä tiedostojen eheyden ja digitaalisten allekirjoitusten kannalta. Se on huono salasanojen tallennuksen kannalta.

Salasananhajautusalgoritmit on suunniteltu hitaiksi, säädettäviksi ja joskus muistivaativiksi. Argon2id, bcrypt, scrypt ja PBKDF2 antavat kaikki säätää kustannusparametreja niin, että jokainen arvaus vie merkityksellisesti aikaa.

Argon2id on laajasti suositeltu uusiin järjestelmiin, koska se voidaan määrittää vaatimaan sekä CPU-aikaa että muistia, mikä tekee laajamittaisesta GPU-murtamisesta kalliimpaa. bcrypt on edelleen yleinen ja hyväksyttävä, kun se on määritetty hyvin, vaikka sillä on rajoituksia, kuten salasanan pituuden käsittely. PBKDF2 on yhä käytössä joissakin vaatimustenmukaisuuden ohjaamissa ympäristöissä, erityisesti silloin kun vaaditaan FIPS-validoituja komponentteja.

Periaate on yksinkertainen: tee laillisista kirjautumisista hyväksyttävän nopeita ja miljardeista arvauksista kalliita.

Miltä hajautus ei suojaa

1. Tietojenkalastelulta

Jos käyttäjä kirjoittaa salasanansa väärennetylle kirjautumissivulle, palvelimellasi tehtävä hajautus ei auta. Hyökkääjä saa salasanan ennen kuin järjestelmäsi koskaan näkee sitä.

Tässä puolustukset ovat erilaisia: monivaiheinen tunnistautuminen, passkeys, käyttäjäkoulutus, verkkotunnusten hygienia, tietojenkalastelua kestävät tunnistautumistavat ja huolelliset salasanan nollausprosessit.

Salasanan hajautus on varmistus tallennetuille salaisuuksille. Se ei ole puolustus sitä vastaan, että käyttäjät huijataan luovuttamaan nuo salaisuudet.

2. Tunnistetietojen kokeilulta

Tunnistetietojen kokeilu tapahtuu, kun hyökkääjät ottavat yhdestä palvelusta vuotaneita käyttäjätunnus- ja salasanapareja ja kokeilevat niitä toisessa.

Salasanasi hajautus voi olla erinomainen, ja tunnistetietojen kokeilu voi silti toimia, jos käyttäjät käyttävät salasanoja uudelleen.

Tämä on verkkohyökkäys kirjautumislomakettasi vastaan, ei offline-hyökkäys tietokantaasi vastaan. Tarvitset nopeusrajoituksia, poikkeamien tunnistusta, vuotaneiden salasanojen tarkistuksia, MFA:ta ja järkeviä lukituskäytäntöjä, jotka eivät luo helppoja palvelunestomahdollisuuksia.

Sama käytännöllinen ajattelu pätee mihin tahansa julkiseen lomakkeeseen. Jos arvioit tunnistautumispintaasi, kannattaa lukea, miksi yhteydenottolomakkeesi on suurin roskapostiriskisi; mekanismit eroavat, mutta opetus on samanlainen: julkiset syötteet tarvitsevat väärinkäytön torjuntaa, eivät vain siistiä taustajärjestelmäkoodia.

3. Lokeihin tai analytiikkaan päätyviltä salasanoilta

Hajautus auttaa vain, jos selväkielinen salasana hylätään nopeasti eikä sitä kopioida muualle.

Yleisiä epäonnistumisia ovat:

• Koko pyyntörungon lokitus epäonnistuneissa kirjautumisyrityksissä.
• Salasanojen lähettäminen virhevalvontatyökaluihin.
• Salasanakenttien tallentaminen istunnon toistotuotteissa.
• Tunnistetietojen sisällyttäminen URL-osoitteisiin huonosti suunnitelluissa nollaus- tai migraatioprosesseissa.
• Väliaikaisten selväkielisten salasanojen tallentaminen tuontien aikana.

Nämä virheet ohittavat salasanan hajautuksen kokonaan. Jos selväkieli päätyy lokeihin, varmuuskopioihin, tietovarastoihin tai kolmannen osapuolen työkaluihin, hajautusfunktiollasi ei ole merkitystä.

Käsittele salasanakenttiä myrkyllisenä datana. Peitä ne ennen lokitusta. Sulje ne pois analytiikasta. Pidä ne poissa URL-osoitteista. Rajoita sitä, kuka voi käyttää tuotannon jäljitystietoja.

4. Huonolta istuntoturvalta

Kirjautumisen jälkeen käyttäjän selain saa yleensä istuntoevästeen tai tunnisteen. Jos tunniste varastetaan, hyökkääjä ei välttämättä tarvitse salasanaa lainkaan.

Salasanan hajautus ei suojaa cross-site scriptingiltä, turvattomilta evästeiltä, session fixationilta, heikolta tunnisteiden luonnilta tai liian pitkiltä istuntojen elinajoilta.

Istuntoevästeet ansaitsevat oman tarkastelunsa: HttpOnly, Secure, sopiva SameSite, lyhytikäiset korkean riskin istunnot ja palvelinpuolinen mitätöinti salasanan vaihdon yhteydessä. Myös laajempi yksityisyyden ja selainten maisema muuttuu jatkuvasti, kuten käsitellään artikkelissa mikä muuttui evästeissä vuonna 2026.

5. Heikoilta salasanan nollaus- ja tilin palautusprosesseilta

Monet tilikaappaukset eivät ala salasanasta. Ne alkavat nollausprosessista.

Jos nollaustunnisteet ovat ennustettavia, pitkäikäisiä, vuotavat referrer-otsakkeiden kautta tai lähetetään murrettuihin sähköpostitileihin, salasanan hajautus ei pelasta sinua.

Käytä korkean entropian nollaustunnisteita, lyhyitä vanhenemisaikoja, kertakäyttöisyyttä ja selkeitä ilmoituksia käyttäjille. Koska sähköposti on usein palautuskanava, myös verkkotunnuksen perustason todennus on tärkeää. Jos tiimisi kohtelee DNS-tietueita salaperäisenä seremoniana, aloita artikkelista kehittäjäystävällinen kierros MX-, SPF-, DKIM- ja DMARC-tietueisiin.

Algoritmin valinta: mitä käyttää nyt

Uusissa sovelluksissa käytä Argon2id:tä, jos alustasi tukee sitä hyvin. Se on Password Hashing Competitionin voittaja ja suunniteltu salasanojen tallennukseen, mukaan lukien vastustuskyky GPU-painotteista murtamista vastaan.

Järkevä nykyaikainen hierarkia näyttää tältä:

1. Argon2id uusiin järjestelmiin, kun se on saatavilla.
2. bcrypt, kun Argon2id ei ole käytännöllinen ja bcrypt-tuki on kypsä.
3. scrypt, kun muistivaativa määritys on hyvin tuettu.
4. PBKDF2, kun alusta tai vaatimustenmukaisuus sitä edellyttää.

Vältä pelkkää SHA-256:ta, SHA-512:ta, MD5:tä tai itse rakennettua yhdistelmää, kuten sha256(password + salt). Nopeat hajautusfunktiot eivät ole salasanojen tallennusfunktioita. Nokkelat omatekoiset rakenteet ovat yleensä huonompia kuin tylsät vakiintuneet ratkaisut.

Vältä myös oman salasanakäytännön keksimistä algoritminippelitiedon ympärille. Käyttäjät eivät hyödy 12 säännön salasanan koostumuslistasta, jos se ohjaa heitä ennustettaviin malleihin. Pidemmät yksilölliset salasanat, salasanojen hallintaohjelmat, vuotaneiden salasanojen seulonta ja MFA ovat yleensä tärkeämpiä.

Kustannusparametreja ei aseteta ja unohdeta

Salasanan hajautuksella on parametreja. Argon2id:llä on muisti, iteraatiot ja rinnakkaisuus. bcryptillä on kustannuskerroin. PBKDF2:lla on iteraatiomäärä.

Nämä arvot pitäisi valita tuotantoympäristösi perusteella. Liian matala arvo, ja hyökkääjät arvaavat halvalla. Liian korkea arvo, ja kirjautumisjärjestelmästäsi tulee hidas tai altis palvelunestolle.

Käytännöllinen tavoite on usein kymmenistä muutamaan sataan millisekuntiin per salasanan tarkistus todellisilla palvelimillasi, liikenteestä ja riskistä riippuen. Korkean turvallisuuden järjestelmät voivat valita enemmän. Kuluttajamittakaavan järjestelmät voivat tarvita huolellista kapasiteettisuunnittelua.

Älä kopioi kustannuskerrointa viisi vuotta vanhasta blogikirjoituksesta. Laitteisto muuttuu. Kirjastot muuttuvat. Liikenteesi muuttuu.

Tarkista parametrit säännöllisesti ja suunnittele uudelleenhajautus. Yleinen malli on tallentaa algoritmi ja parametrit jokaisen hajautusarvon mukana. Onnistuneen kirjautumisen yhteydessä, jos tallennetut parametrit ovat vanhentuneet, hajauta annettu salasana uudella määrityksellä ja päivitä tietue.

Pepperit: hyödyllisiä, mutta eivät korvike

Pepper on salainen arvo, joka lisätään salasananhajautusprosessiin ja tallennetaan erilleen tietokannasta, usein secrets manageriin tai laitteistopohjaiseen tietoturvamoduuliin.

Toisin kuin suola, pepperin täytyy pysyä salassa.

Pepperit voivat vähentää vahinkoa, jos tietokanta vuotaa mutta sovellussalaisuudet eivät. Ne ovat hyödyllisimpiä kypsissä ympäristöissä, joissa avaintenhallinta on kunnossa. Ne ovat vähemmän hyödyllisiä, jos sama hyökkääjä voi varastaa sekä tietokannan että sovelluksen määritykset.

Jos käytät pepperiä, suunnittele kierto huolellisesti. Sen kierrättäminen voi vaatia käyttäjiä kirjautumaan uudelleen tai nollaamaan salasanansa, toteutuksesta riippuen. Pepper on lisäkerros, ei syy heikentää taustalla olevia hajautusasetuksia.

Operatiivinen tarkistuslista

Jos vastaat oikeasta järjestelmästä, käytännön tarkistuslista on lyhyt:

• Tallenna salasanat vain vakiintuneella salasananhajautusalgoritmilla.
• Käytä yksilöllistä satunnaista suolaa jokaiselle salasanalle.
• Suosi Argon2id:tä uusissa toteutuksissa.
• Säädä kustannusparametrit tuotantoa vastaavalla laitteistolla.
• Tallenna algoritmi ja parametrit jokaisen hajautusarvon mukana.
• Hajauta uudelleen kirjautumisen yhteydessä, kun parametrit vanhentuvat.
• Älä koskaan lokita salasanoja tai lähetä niitä analytiikkatyökaluihin.
• Käytä TLS:ää kaikkialla, missä tunnistetietoja lähetetään.
• Lisää MFA tai passkeys, kun riski sitä perustelee.
• Suojaa nollausprosessit yhtä vakavasti kuin kirjautumisprosessit.
• Pidä häiriösuunnitelma pakotettuja nollauksia ja käyttäjien ilmoittamista varten.

Salasanan hajautus ei ole hohdokasta. Se on putkistoa. Mutta juuri sellainen putkisto määrittää, muuttuuko tietomurto kivuliaaksi häiriöksi vai koko käyttäjäkunnan katastrofiksi.

<!-- tool-cta:start -->

💡 Kokeile tätä: Katso Hash Generator -työkalulla, miten sama syöte yhdistyy eri algoritmeihin, mikä tekee nopeiden tiivisteiden ja salasanatasoisten tiivisteiden erosta konkreettisen.

<!-- tool-cta:end -->

Rehellinen ajattelumalli

Paras tapa ajatella salasanan hajautusta on tämä:

Hajautus ei suojaa salasanaa, kun käyttäjä kirjoittaa sitä. Se ei suojaa tiliä sen jälkeen, kun käyttäjä on kirjautunut sisään. Se ei suojaa käyttäjiä, jotka käyttävät samoja salasanoja eri puolilla verkkoa.

Se suojaa tallennettua tarkistetta.

Se kuulostaa kapealta, mutta se on äärimmäisen tärkeää. Tietokannat vuotavat. Varmuuskopiot vuotavat. Staging-järjestelmiä kopioidaan. Toimittajat saavat pääsyn, jota heillä ei pitäisi olla. Vanhat viennit jäävät objektitallennukseen pidemmäksi aikaa kuin kukaan muistaa.

Kun niin tapahtuu, salasanojen tallennusratkaisusi ratkaisee eron sen välillä, saavatko hyökkääjät salasanat vai kalliin arvausongelman.

Siltä salasanan hajautus oikeasti suojaa.