Know-how / Salasanaturvallisuus

Samat salasanat: miksi salasanojen uudelleenkäyttö on niin vaarallista

Yksi vuotanut salasana riittää – credential stuffing tekee yhdestä tietoturvapoikkeamasta ketjureaktion.

Saman salasanan käyttäminen useissa tileissä tuntuu harmittomalta – ja on silti yksi kaikkein useimmin hyväksikäytetyistä heikkouksista. Kun yksi palvelu murretaan, hyökkääjät kokeilevat saatuja kirjautumistietoja automatisoidusti kaikkiin muihin. Tämä artikkeli selittää, miten credential stuffing toimii, miksi salasanojen uudelleenkäyttö on yrityksille erityisen riskialtista ja millä toimenpiteillä ratkaisette ongelman rakenteellisesti.

Mitä salasanojen uudelleenkäyttö tarkoittaa?

Käsitteellä salasanojen uudelleenkäyttö tarkoitetaan sitä, että samaa tai vain hieman muunneltua salasanaa käytetään useissa tileissä. Käytännössä se ilmenee kolmessa muodossa:

  • Samat salasanat: yksi salasana sähköpostiin, CRM:ään, pilvitallennukseen ja verkkokauppaan – klassinen tapaus.
  • Muunnelmat: ”Kesä2025!” muuttuu muotoon ”Kesä2026!” tai ”Kesä2025!!” – automatisoiduille hyökkäyksille käytännössä yhtä helppoja arvata kuin alkuperäinen.
  • Yksityisen ja työkäytön sekoittuminen: yksityinen suoratoistopalvelun salasana on samalla yritysjärjestelmän kirjautumistunnus. Kuluttajapalvelun vuoto osuu näin suoraan yritykseen.

Kuinka yleinen ongelma on, näkyy kyselyissä säännöllisesti: noin kolmannes internetin käyttäjistä Saksassa käyttää samaa salasanaa useissa palveluissa (Bitkom, tammikuu 2025).

Credential stuffing: näin hyökkääjät käyttävät samoja salasanoja hyväkseen

Tietovuodon jälkeen kaapatut sähköpostiosoitteen ja salasanan yhdistelmät kiertävät asiaan vihkiytyneillä foorumeilla ja kokoelmissa. Credential stuffing -hyökkäyksessä hyökkääjät syöttävät nämä listat automatisoidusti muiden palveluiden kirjautumissivuille – bottiverkoilla, tuhansien IP-osoitteiden kautta hajautettuna, jotta estot kierretään. Jokainen uudelleenkäyttö muuttuu näin osumaksi (NCSC: Credential Stuffing Advisory).

Kuinka välittömästi hyödynnettävissä tämä on, osoittaa Verizon Data Breach Investigations Report: hyökkäysluokassa ”Basic Web Application Attacks” noin 88 % raportoiduista tapauksista liittyi varastettuihin kirjautumistietoihin. Toisin kuin brute force -hyökkäyksessä mitään ei tarvitse ”murtaa” – salasana on jo tiedossa.

Yksittäisestä vuodosta ketjureaktioksi

Varsinainen vahinko syntyy ketjuuntumisesta: kaapatulla sähköpostitilillä voidaan käynnistää salasanan palautuksia muihin palveluihin. Kaapatulla työntekijätunnuksella hyökkääjät pääsevät yritysverkkoon, laajentavat oikeuksiaan, liikkuvat verkossa sivusuunnassa – ja levittävät pahimmassa tapauksessa kiristyshaittaohjelman. BSI varoitti jo vuonna 2024 nimenomaisesti automatisoiduista kirjautumisyrityksistä julkisesti saavutettavia järjestelmiä vastaan.

Tyypillinen kulku: vuoto kuluttajapalvelussa → sama yhdistelmä toimii työsähköpostissa → postilaatikon kautta nollataan yhteistyövälineet ja pilvipalvelut → kaapatulta tililtä lähtee sisäisiä kalasteluviestejä kollegoille. Ketjun jokainen vaihe edellyttää vain yhtä asiaa: uudelleenkäytettyä salasanaa.

Miksi salasanojen uudelleenkäyttö on yrityksissä erityisen riskialtista

Yrityskontekstissa riskiä kärjistää kolme tekijää:

  • Jaetut tilit: sosiaalisen median, toimittajaportaalien tai palvelutilien tiimitunnukset jaetaan usein suullisesti, sähköpostilla tai listalla – ja ne säilyvät henkilövaihdoksissa muuttumattomina. Joka salasanan kerran tiesi, tietää sen edelleen.
  • Epäselvä offboarding: kun henkilö lähtee yrityksestä, ilman keskitettyä hallintaa kukaan ei tiedä luotettavasti, mitkä tunnukset hän tunsi ja mitkä salasanat on vaihdettava.
  • Yksityisen ja työkäytön sekoittuminen: yksityisten palveluiden vuotoja yritys ei voi estää eikä havaita – mutta niiden vaikutuksen voi rajata, kun työkäytön salasanat ovat taatusti ainutkertaisia.

Miten keskitetty salasanojen hallinta ratkaisee nämä rakenteelliset ongelmat, kuvaa yleiskatsauksemme Salasanojen hallintaohjelma yrityksille; organisatorista puolta käsittelee käytännön artikkeli Salasanojen turvallinen hallinta yrityksissä.

Uudelleenkäytettyjen ja vaarantuneiden salasanojen tunnistaminen

Kuvakaappaus Password Depotin Windows-asiakasohjelmasta: salasana-analyysi tallennettujen salasanojen turvallisuusarvioineen sekä salasanageneraattori.
Salasana-analyysi Windows-asiakasohjelmassa: tallennettujen salasanojen laadun tarkistus

Ensimmäinen askel on läpinäkyvyys: mitkä salasanat ovat heikkoja, useaan kertaan käytettyjä tai jo esiintyneet tunnetuissa tietovuodoissa? Kaksi työkalua auttaa:

  • Salasana-analyysi: Password Depot arvioi tallennettujen salasanojen laadun ja tuo näkyviin heikot merkinnät, jotka on syytä vaihtaa.
  • Vertailu vaarantuneiden salasanojen listoihin: toiminnolla Työkalut → Turvallisuustarkistus → Tarkista Pwned-salasanat Password Depot vertaa tallennettuja salasanoja julkiseen Have I Been Pwned -tietokantaan – k-anonymiteetilla, ilman että salasananne poistuvat koneelta selväkielisinä. Juuri tätä vertailua suosittelee myös NIST SP 800-63B.

Suorittakaa tarkistus säännöllisesti – erityisesti julkisuuteen tulleiden tietovuotojen tai kalastelutapausten jälkeen – ja vaihtakaa kyseiset salasanat heti.

Salasanojen uudelleenkäytön estäminen: toimenpiteet yhdellä silmäyksellä

Tehokas on käytännön, tekniikan ja arkikelpoisuuden yhdistelmä – pelkät kiellot kaatuvat siihen, ettei kymmeniä ainutkertaisia salasanoja voi muistaa:

ToimenpideToteutusVaikutus
Yksi salasana per palveluKäytäntö: uudelleenkäyttö kielletään; pitkät, satunnaiset salasanat generaattorista (ks. Vinkkejä turvallisiin salasanoihin)Vuoto rajoittuu yhteen palveluun
Salasanojen hallintaohjelman käyttöönottoAinutkertaiset salasanat muuttuvat käytännöllisiksi, koska kenenkään ei enää tarvitse muistaa salasanojaPoistaa uudelleenkäytön pääsyyn
Vertailu vuotolistoihinUudet ja olemassa olevat salasanat tarkistetaan vaarantuneiden salasanojen listoja vasten (NIST SP 800-63B)Jo vuotaneet salasanat tunnistetaan ja vaihdetaan
MFA / pääsyavaimetMonivaiheinen todennus, mieluiten kalastelunkestävä (FIDO2), vähintään ylläpito-, etä- ja pilvitunnuksille (CISA)Varastetut salasanat eivät enää yksin riitä
Tapahtumaperusteinen vaihto kalenterirotaation sijaanSalasanan vaihto pakotetaan vain epäiltäessä tai todettaessa vaarantuminen – näin suosittelevat BSI, NIST ja NCSC.Estää ennakoitavat muunnelmat, kuten ”Kesä2026!”

Salasanojen uudelleenkäytön keskitetty estäminen Password Depot Enterprise Serverillä

Yksittäiset toimenpiteet auttavat – ainutkertaisuuden voi kuitenkin panna täytäntöön vain keskitetysti. Password Depot Enterprise Server ankkuroi toimenpiteet infrastruktuuriin:

  • Keskitetyt salasanakäytännöt: vähimmäispituus, sallitut merkintätyypit ja generaattorisäännöt pätevät palvelinpuolella kaikille – eivät suosituksena vaan vaatimuksena.
  • Jaetut tilit ilman jaettuja salaisuuksia: tiimitunnukset sijaitsevat yhteisissä, salatuissa tietokannoissa rooleineen ja oikeuksineen – eivät listoissa ja chateissa. Offboardingissa näette keskitetysti, mitkä merkinnät ovat kyseessä.
  • Turvallisuustarkistus kaikille: heikot ja vuodoissa esiintyneet salasanat tunnistetaan ja vaihdetaan – kattavasti eikä käyttäjäkohtaisesti.
  • MFA ja hakemistoliitäntä: FIDO2/WebAuthn ja TOTP suojaavat pääsyn lisäksi; käyttäjät ja ryhmät tulevat olemassa olevasta identiteetinhallinnastanne, kuten artikkelissa Active Directory, SSO ja MFA kuvataan.
  • Jäljitettävyys: auditointilokit vastaavat kysymykseen ”kenellä oli pääsy mihinkin ja milloin?” – tärkeää poikkeama-analyysissä ja auditoinneissa.

Yhteenveto: ainutkertaisuus on tehokkain yksittäinen toimenpide

Salasanojen uudelleenkäyttö ei ole mukavuusongelma, vaan mekanismi, joka tekee vieraasta tietovuodosta teidän tietoturvapoikkeamanne. Ratkaisu on ollut vuosia BSI:n, NIST:n ja NCSC:n yhteinen kanta: pitkät, ainutkertaiset salasanat palvelukohtaisesti, salasanojen hallintaohjelma, joka tekee siitä käytännöllistä, vertailu vuotolistoihin ja MFA. Yrityksissä tähän kuuluu keskitetty salasanojen hallinta, joka panee säännöt täytäntöön – sen sijaan, että vain suosittelisi niitä.

Usein kysyttyä samoista salasanoista

Mitä on credential stuffing?

Automatisoitu hyökkäys, jossa tietovuodoista peräisin olevia sähköpostiosoitteen ja salasanan yhdistelmiä kokeillaan massoittain muiden palveluiden kirjautumissivuille. Se toimii vain siksi, että moni käyttää salasanoja uudelleen – mitään ei tarvitse murtaa.

Mistä tiedän, onko salasanani joutunut tietovuotoon?

Vertaamalla sitä julkisiin vuototietokantoihin, kuten Have I Been Pwnediin. Password Depotissa tarkistus on sisäänrakennettu: Työkalut → Turvallisuustarkistus → Tarkista Pwned-salasanat – k-anonymiteetilla, ilman että salasananne siirtyvät selväkielisinä.

Riittääkö salasanan pieni muuntelu?

Ei. Muunnelmat, kuten perään lisätyt vuosiluvut tai huutomerkit, ovat ennakoitavia, ja hyökkäystyökalut testaavat ne automaattisesti. Turvallinen on vain palvelukohtaisesti ainutkertainen, satunnaisesti luotu salasana.

Kuinka usein salasanat pitäisi vaihtaa?

Tapahtumaperusteisesti eikä kalenterin mukaan: kun vaarantumista epäillään tai se on todettu, kalastelutapausten jälkeen tai kun tunnuksiin pääsyn omanneet työntekijät lähtevät. Rutiininomaisesta pakkovaihdosta ilman aihetta BSI, NIST ja NCSC kehottavat luopumaan, koska se johtaa heikompiin, ennakoitaviin salasanoihin.

Suojaako monivaiheinen todennus credential stuffingilta?

MFA on yksi tehokkaimmista vastatoimista: oikeallakin salasanalla kirjautuminen kaatuu toiseen tekijään. Kalastelunkestävät menetelmät, kuten FIDO2/pääsyavaimet, antavat vahvimman suojan. MFA ei kuitenkaan korvaa ainutkertaisia salasanoja – molemmat kuuluvat yhteen.

Miten yritykset estävät salasanojen uudelleenkäytön järjestelmällisesti?

Keskitetyllä salasanojen hallinnalla, kuten Password Depot Enterprise Serverillä: palvelinpuolen salasanakäytännöt, generaattori ainutkertaisille salasanoille, yhteinen turvallisuustarkistus vuotolistoja vasten, MFA sekä roolit ja auditointilokit jaetuille tunnuksille.

Ainutkertaiset salasanat keskitetysti käytäntöön

Password Depot Enterprise Server tekee suosituksista sitovia käytäntöjä – generaattorilla, turvallisuustarkistuksella ja auditointilokeilla koko tiimillenne.

Tutustukaa Enterprise Serveriin