Have I Been Pwned -palvelun laskuri näytti elokuussa 2026 lukeman 17,8 miljardia vuotanutta tiliä yli 1 030 tietovuodosta. Numero kasvaa lähes viikoittain, sillä uusia stealer log -kaatopaikkoja ja credential stuffing -listoja tulvii verkkoon jatkuvasti. Jos et ole koskaan tarkistanut, löytyykö oma sähköpostiosoitteesi näistä listoista, tämä opas käy koko prosessin läpi alusta loppuun: verkkosivun peruskäytöstä omaan Python-skriptiin, Bitwardenin ja 1Passwordin integraatioihin sekä siihen, mitä sinun pitää tehdä Suomen lain mukaan, jos yrityksesi data vuotaa.
Opas on suunnattu kehittäjille, IT-vastaaville ja kenelle tahansa, joka haluaa ottaa tietovuotojen seurannan omiin käsiinsä sen sijaan, että odottaa uutista rikkomuksesta vuosia myöhemmin. Kaikki 12 vaihetta ovat testattavissa suoraan artikkelin komennoilla.
Suomessa ja muualla Pohjoismaissa aihe on erityisen ajankohtainen juuri nyt. Tietosuojavaltuutetun toimisto käsittelee tuhansia ilmoituksia vuosittain, ja alkuvuoden 2026 Valtori-tapaus muistutti, että myös julkishallinto on hyökkääjien tähtäimessä. Samalla stealer-haittaohjelmien tuottama data on kasvattanut HIBP:n tietokannan käytännössä miljardien tilien mittakaavaan alle kahdessa vuodessa. Kun ymmärrät, miten palvelu toimii teknisesti ja miten sen voi kytkeä osaksi omaa tai organisaatiosi prosessia, tietovuodosta tulee hallittava rutiini yllätyksen sijaan.
Mikä Have I Been Pwned on ja miksi 17,8 miljardia tiliä on jo vuotanut
Troy Hunt perusti Have I Been Pwned (HIBP) -palvelun vuonna 2013 yksinkertaisesta syystä: ihmisillä ei ollut mitään keinoa tietää, oliko heidän sähköpostiosoitteensa ja salasanansa päätyneet rikollisten haltuun. Tänä päivänä palvelu indeksoi noin 17,8 miljardia vuotanutta tiliä yli 1 030 tunnetusta tietovuodosta, ja luku kasvaa jatkuvasti uusien lisäysten myötä. Palvelu on ilmainen yksityishenkilöille ja toimii sekä selaimessa että ohjelmointirajapinnan (API) kautta.
HIBP saa säännöllisesti dataa myös lainvalvontaviranomaisilta. Esimerkiksi toukokuussa 2025 kansainvälinen Operation Endgame -operaatio, jossa oli mukana useiden maiden poliisiviranomaisia, luovutti HIBP:lle 15,4 miljoonaa uhrin sähköpostiosoitetta ja 43,8 miljoonaa salasanaa, jotka oli takavarikoitu haittaohjelmaverkostoja kaatavien operaatioiden yhteydessä. Tällaiset viranomaisyhteistyössä syntyneet lisäykset ovat erityisen luotettavia, koska data on peräisin suoraan takavarikoiduilta palvelimilta eikä esimerkiksi epävarmasta foorumihuhusta.
HIBP jaottelee vuodot kahteen tyyppiin: vahvistettuihin (verified) ja vahvistamattomiin (unverified) tietovuotoihin. Vahvistettu vuoto tarkoittaa, että Hunt tai hänen tiiminsä on itse todentanut datan aitouden, esimerkiksi vertaamalla otosta oman tai vapaaehtoisten tunnettuihin tunnuksiin. Vahvistamaton vuoto taas näytetään sivustolla, mutta merkittynä epävarmaksi, koska alkuperää ei ole pystytty täysin todentamaan. Lisäksi osa vuodoista on merkitty “sensitiiviseksi” (sensitive breach), jolloin niitä ei näytetä domain-haussa lainkaan yksityisyyssyistä, esimerkiksi seksuaalivähemmistöille suunnattujen palveluiden tai aikuisviihdesivustojen tietovuodot kuuluvat tähän kategoriaan. Tämä jaottelu on tärkeää ymmärtää, koska se vaikuttaa suoraan siihen, mitä dataa näet ja miten sitä kannattaa tulkita.
Syy nykyiseen kasvuvauhtiin on niin sanottu stealer log -ilmiö. Haittaohjelmat keräävät käyttäjien selaimiin tallennetut kirjautumistiedot suoraan laitteelta, minkä jälkeen data myydään tai jaetaan Telegram-kanavilla ja hakkerifoorumeilla laajoina tietokantoina. Näistä koostuu suuri osa viime vuosien massiivisimmista lisäyksistä HIBP:hen. Alla on kooste kuudesta merkittävimmästä vuodesta, jotka on lisätty palveluun vuosien 2025 ja 2026 aikana.
Lukuja kannattaa suhteuttaa siihen, että 17,8 miljardia on suurempi luku kuin koko maailman väestö. Tämä ei tarkoita, että jokainen ihminen maapallolla olisi vuotanut, vaan sitä, että sama sähköpostiosoite esiintyy tyypillisesti useissa eri vuodoissa, joskus kymmenissä. Aktiivinen käyttäjä, joka on rekisteröitynyt lukuisiin palveluihin viimeisen viidentoista vuoden aikana, löytää itsensä usein neljästä, viidestä tai jopa kymmenestä eri vuodosta yhdellä haulla, mikä selittää osan luvun suuruudesta.
| Tietovuoto | Lisätty HIBP:hen | Vaikutetut tilit | Tyyppi |
|---|---|---|---|
| ALIEN TXTBASE Stealer Logs | 25.2.2025 | 284,1 milj. sähköpostiosoitetta | Stealer log |
| Stealer Logs (tammikuu 2025) | 13.1.2025 | 71 milj. osoitetta, 106 milj. salasanaa | Stealer log |
| Data Troll Stealer Logs | 13.8.2025 | 109,5 milj. uniikkia osoitetta (2,7 mrd. riviä) | Stealer log |
| Synthient Stealer Log Threat Data | 21.10.2025 | 183 milj. osoitetta | Stealer log |
| Synthient Credential Stuffing Threat Data | 6.11.2025 | 2 mrd. osoitetta, 1,3 mrd. salasanaa | Credential stuffing |
| Suno (tekoälymusiikkipalvelu) | 20.7.2026 | 55,3 milj. tiliä | Tietomurto |
Data Troll -tapaus tunnetaan mediassa harhaanjohtavasti “16 miljardin salasanan vuotona”. Todellisuudessa HIBP:n analyysi paljasti raakadatan sisältävän 2,7 miljardia riviä, jotka puhdistuksen jälkeen tiivistyivät 109,5 miljoonaan uniikkiin sähköpostiosoitteeseen. Tämä on hyvä muistutus siitä, että otsikoihin kannattaa suhtautua varauksella ja tarkistaa numerot alkuperäisestä lähteestä, kuten HIBP:n omalta API-dokumentaatiosta.
Synthient-tapaukset ansaitsevat oman huomionsa, koska ne edustavat uudempaa datatyyppiä kuin perinteinen “yritys X hakkeroitiin” -vuoto. Synthient on uhkatiedustelufirma, joka keräsi vuoden 2025 aikana credential stuffing -listoja, eli valmiiksi kokoonpantuja käyttäjätunnus-salasana-pareja, joita rikolliset syöttävät automatisoidusti kirjautumislomakkeisiin toivoen tunnusten toimivan useassa palvelussa samanaikaisesti. Tällaisessa datassa ei ole yhtä alkuperäistä uhria, vaan se on koottu lukuisista vanhemmista vuodoista uudelleenkäytettyjen salasanojen ympärille, mikä tekee siitä erityisen vaarallista juuri salasanojen kierrättäjille.
Suno-tapaus puolestaan on hyvä esimerkki siitä, että myös uudet, nopeasti kasvaneet tekoälypalvelut ovat kiinnostavia kohteita hyökkääjille. Palvelu, joka tuottaa tekoälyavusteista musiikkia, kärsi tietomurrosta marraskuussa 2025, ja tapaus lisättiin HIBP:hen heinäkuussa 2026 lähes 55,3 miljoonan tilin laajuudessa. Kahdeksan kuukauden viive tapahtuman ja julkisen tiedon välillä on tyypillinen esimerkki siitä, kuinka pitkään tietomurron laajuuden selvittäminen ja julkistaminen voi käytännössä kestää, vaikka GDPR edellyttääkin viranomaisilmoitusta huomattavasti nopeammin.
Esivaatimukset: nämä tarvitset ennen kuin aloitat
Opas ei vaadi erikoisosaamista, mutta muutama työkalu kannattaa olla valmiina ennen kuin etenet vaiheisiin. Verkkoselaimen kautta tehtävä tarkistus onnistuu ilman mitään asennuksia, mutta API-integraatioita ja skriptejä varten tarvitset seuraavat:
- Selain: mikä tahansa ajantasainen selain (Firefox, Chrome, Edge tai Brave) haveibeenpwned.com-sivun peruskäyttöön.
- Python 3.11 tai uudempi: omaa tarkistusskriptiä ja automaatioprojektia varten. Tarkista versio komennolla
python3 --version. - curl 8.x: useimmissa Linux-, macOS- ja Windows 11 -asennuksissa valmiina. Tarkista komennolla
curl --version. - Salasananhallinta: esimerkiksi Bitwarden (uusin vakaa versio 2026.x) tai 1Password 8, jos haluat ottaa käyttöön automaattisen tietovuotoraportin.
- HIBP-API-avain (valinnainen): tarvitaan vain, jos haluat tarkistaa sähköpostiosoitteita ohjelmallisesti API:n kautta. Avain maksaa alimmalla Pwned 1 -tasolla 4,50 dollaria kuukaudessa ja sen voi hankkia haveibeenpwned.com-sivun kautta.
- Slack- tai sähköpostiwebhook (valinnainen): tarvitaan vain lopun automaatioprojektissa, jos haluat hälytykset tiimin kanavaan.
Kaikki oppaan komennot toimivat samalla tavalla Windows 11:ssä (PowerShell tai WSL2), macOS:ssa ja Linuxissa, koska sekä curl että Python ovat alustariippumattomia. Jos käytät Windowsia ilman WSL2:ta, varmista, että python3-komento löytyy PATH-muuttujasta, tai käytä sen sijaan komentoa python, riippuen siitä, miten asennus on tehty. Docker-pohjaiset esimerkit (Bitwardenin self-hosted-asennus) vaativat lisäksi Docker Desktopin tai Docker Enginen, versio 24 tai uudempi.
Kaikki tässä oppaassa käytettävät ominaisuudet, kuten salasanan tarkistus k-anonymiteetti-API:n kautta, ovat ilmaisia eivätkä vaadi avainta. Maksullinen API-avain tarvitaan ainoastaan sähköpostiosoitteiden ohjelmalliseen massatarkistukseen.
Kannattaa myös varata noin 40 minuuttia yhtäjaksoista aikaa, jos aiot käydä läpi kaikki 12 vaihetta peräkkäin, mukaan lukien esimerkkiprojektin pystyttämisen. Pelkkä selainpohjainen tarkistus (vaiheet 1–2) vie käytännössä pari minuuttia, mutta API-integraatiot, skriptit ja automaatio vaativat hieman enemmän keskittymistä, varsinkin jos et ole aiemmin käsitellyt ympäristömuuttujia tai cron-ajastuksia.
Jos sinulla on kiire eikä aikaa koko oppaan läpikäyntiin kerralla, priorisoi vaiheet 1–2 ja 11 ensin: ne kattavat oman tilanteesi selvittämisen ja välittömät korjaustoimet vain muutamassa minuutissa. Loput vaiheet, kuten oma skripti, Bitwarden-integraatio ja tiimin automaatioprojekti, voi ottaa käyttöön myöhemmin omaan tahtiin, kun perusasiat ovat jo kunnossa.
Vaihe 1–2: Tarkista sähköposti ja puhelinnumero HIBP:ssä
Vaihe 1. Avaa haveibeenpwned.com ja kirjoita etusivun hakukenttään sähköpostiosoitteesi. Palvelu ei tallenna hakuja eikä lähetä osoitetta minnekään kolmannelle osapuolelle, se vain vertaa syötettä indeksoituun tietokantaan. Tulos näyttää suoraan listan vuodoista, joissa osoitteesi esiintyy, mukaan lukien vuodon päivämäärän ja tietotyypit (salasana, puhelinnumero, osoite ja niin edelleen).
Vaihe 2. Toista sama puhelinnumerollasi, jos käytät samaa numeroa useissa palveluissa. HIBP tukee myös puhelinnumerohakua tietyille vuodoille, kuten suurille yhteystietokannoille. Jos hallinnoit useita sähköposteja (työ, henkilökohtainen, vanha Hotmail-tili vuosien takaa), tarkista jokainen erikseen. Vanhat, unohdetut tilit ovat usein suurin riski, koska niiden salasanoja on saatettu käyttää uudelleen tuoreemmissa palveluissa.
Kannattaa kiinnittää huomiota myös siihen, mitä tietotyyppejä kukin vuoto paljastaa. Osa vuodoista sisältää vain sähköpostiosoitteen ja käyttäjänimen, mikä on lievempi riski, kun taas toiset paljastavat salasanoja, kotiosoitteita, syntymäaikoja tai jopa luottokorttitietoja. HIBP listaa jokaisen vuodon kohdalla tarkasti, mitä “Compromised data” -kenttiä kyseinen tapaus sisältää, ja juuri tämä tieto ratkaisee, kuinka kiireellisesti sinun kannattaa reagoida. Sähköposti ja vanha, jo vaihdettu salasana eivät vaadi paniikkia, mutta ajantasainen salasana yhdistettynä kotiosoitteeseen vaatii välitöntä toimintaa.
Esimerkki tuloksesta, jos osoite löytyy vuodoista, näyttää tältä:
Oh no – pwned!
Pwned in 4 data breaches and found no pastes
ALIEN TXTBASE Stealer Logs (25 Feb 2025)
Compromised data: Email addresses, Passwords
Synthient Credential Stuffing Threat Data (6 Nov 2025)
Compromised data: Email addresses, Passwords, UsernamesJos näet listan, älä panikoi. Tärkeintä on tunnistaa, mitkä salasanat ovat vielä käytössä ja vaihtaa ne, katso siitä lisää vaiheessa 11.
HIBP:n etusivulla on myös oma, palvelun sisäänrakennettu “Notify me” -tilausominaisuus, joka on eri asia kuin myöhemmin vaiheessa 10 käsiteltävä Mozilla Monitor. Kun rekisteröit sähköpostiosoitteesi tähän listaan, saat vahvistuslinkin, jonka klikkaaminen todistaa omistavasi kyseisen osoitteen. Sen jälkeen HIBP lähettää automaattisen sähköpostin joka kerta, kun osoitteesi ilmestyy uudessa vuodossa, ilman että sinun tarvitsee käydä sivustolla manuaalisesti. Tämä on nopein tapa saada jatkuva, ilmainen seuranta yksittäiselle sähköpostiosoitteelle ilman kolmannen osapuolen palvelua.
Vaihe 3–4: K-anonymiteetti ja Pwned Passwords -API selitettynä
Vaihe 3. Sähköpostitarkistus on vasta alku. Pwned Passwords -rajapinta antaa tarkistaa yksittäisen salasanan turvallisesti ilman, että itse salasana koskaan lähtee laitteeltasi verkkoon. Tekniikan nimi on k-anonymiteetti, ja se toimii näin: selain tai skripti laskee salasanasta SHA-1-tiivisteen paikallisesti, lähettää palvelimelle vain tiivisteen viisi ensimmäistä merkkiä ja saa vastaukseksi kaikki tietokannan tiivisteet, jotka alkavat samalla etuliitteellä. Koska mahdollisia viiden merkin etuliitteitä on 16^5 eli hieman yli miljoona, yksi kysely palauttaa keskimäärin noin 478 osumaa, mikä tekee alkuperäisen salasanan päättelystä käytännössä mahdotonta palvelimen suunnalta.
Vaihe 4. Testaa API suoraan terminaalissa. Alla oleva komento hakee kaikki tunnetut tiivisteet, jotka alkavat etuliitteellä CBFDA:
# Lasketaan SHA-1-tiiviste salasanasta paikallisesti (esimerkki)
echo -n "password123" | sha1sum
# Tulos: cbfdac6008f9cab4083784cbd1874f76618d2a97
# Lähetetään vain viiden merkin etuliite HIBP:n range-API:in
curl -s "https://api.pwnedpasswords.com/range/CBFDA" | head -5
# Esimerkkivastaus (muoto: LOPPUOSA:ESIINTYMISKERRAT)
# 6008F9CAB4083784CBD1874F76618D2A97:2847371
# 6018F1CAB4083784CBD1874F76618D2A11:12
# ...Jos alkuperäisen tiivisteen loppuosa löytyy vastauksesta, salasana on tunnetusti vuotanut, ja luku sen perässä kertoo, kuinka monta kertaa se on nähty eri tietovuodoissa. Rajapinta on täysin ilmainen, ei vaadi API-avainta eikä sitä ole nopeusrajoitettu, kunhan käyttöä ei väärinkäytetä. Taustalla HIBP käyttää Azure Functions -palvelua, joka lukee tiivisteryhmät suoraan Azure Blob Storagesta, mikä pitää vastausajat alle sadassa millisekunnissa lähes aina.
Kannattaa ymmärtää, miksi tämä malli on parempi kuin ilmeisin vaihtoehto eli koko tiivisteen lähettäminen palvelimelle. Jos lähettäisit täyden SHA-1-tiivisteen, palvelin näkisi tarkalleen, mitä salasanaa tarkistat, ja voisi periaatteessa tallentaa lokin jokaisesta tarkistetusta salasanasta. Viiden merkin etuliitteen ja keskimäärin 478 osuman ansiosta palvelin ei koskaan tiedä, mikä täsmälleen niistä sadoista mahdollisista tiivisteistä on se, jota todella etsit. Troy Hunt kuvasi tätä ratkaisua alun perin Pwned Passwords -version 2 julkaisun yhteydessä, ja malli on sen jälkeen otettu käyttöön muun muassa selainten ja salasananhallintaohjelmien sisäisissä tarkistuksissa ilman, että käyttäjän tarvitsee luottaa mihinkään yksittäiseen kolmanteen osapuoleen täyden salasanan kanssa.
Range-API tukee myös NTLM-tiivisteitä SHA-1:n rinnalla, mikä on hyödyllistä erityisesti Windows-ympäristöissä ja Active Directory -integraatioissa, joissa salasanat tallennetaan usein NTLM-muodossa. Kutsu toimii muuten identtisesti, mutta osoitteeseen lisätään parametri ?mode=ntlm, jolloin palvelin vertaa etuliitettä NTLM-tiivisteiden tietokantaan SHA-1:n sijaan. Tämä mahdollistaa saman tarkistuslogiikan käytön myös yritysympäristöissä, joissa salasanapolitiikkaa valvotaan suoraan hakemistopalvelun tasolla eikä pelkästään yksittäisissä verkkosovelluksissa.
Vaihe 5–6: Rakenna oma Python-tarkistusskripti
Vaihe 5. Käsin tehtävä curl-kysely on hyvä oppimateriaali, mutta käytännössä haluat automatisoida koko prosessin. Alla oleva Python-skripti laskee tiivisteen, tekee kyselyn ja kertoo suoraan, onko salasana vuotanut ja kuinka monta kertaa. Oman skriptin rakentaminen valmiin selainlaajennuksen sijaan antaa täyden hallinnan siitä, mihin dataa käytetään, mikä on tärkeää etenkin, jos aiot myöhemmin liittää tarkistuksen osaksi omaa rekisteröitymislomaketta tai sisäistä työkalua.
import hashlib
import sys
import urllib.request
def check_password(password: str) -> int:
sha1 = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
prefix, suffix = sha1[:5], sha1[5:]
url = f"https://api.pwnedpasswords.com/range/{prefix}"
req = urllib.request.Request(url, headers={"User-Agent": "hibp-tutorial-fi"})
with urllib.request.urlopen(req, timeout=10) as response:
body = response.read().decode("utf-8")
for line in body.splitlines():
hash_suffix, count = line.split(":")
if hash_suffix == suffix:
return int(count)
return 0
if __name__ == "__main__":
pw = sys.argv[1] if len(sys.argv) > 1 else input("Salasana: ")
hits = check_password(pw)
if hits:
print(f"VAROITUS: salasana on nähty {hits} kertaa tunnetuissa tietovuodoissa.")
else:
print("Ei osumia tunnetuissa vuodoissa. Käytä silti aina uniikkeja salasanoja.")Vaihe 6. Aja skripti komennolla python3 check_password.py ja syötä testisalasana. Huomaa, että itse salasanaa ei koskaan lähetetä mihinkään, ainoastaan viiden merkin etuliite lähtee verkkoon. Tämä sama looginen kulku on juuri se, jota NIST SP 800-63B -standardin kohta 3.1.1.2 edellyttää palveluilta, jotka haluavat estää käyttäjiä valitsemasta jo vuotaneita salasanoja rekisteröitymisen yhteydessä.
Skriptiä kannattaa laajentaa käytännössä kahdella tavalla ennen kuin otat sen tuotantokäyttöön. Ensinnäkin, lisää virheenkäsittely verkko-ongelmille, esimerkiksi try/except-lohko urllib.error.URLError-poikkeukselle, jotta hetkellinen yhteyskatko ei kaada koko rekisteröitymislomaketta. Toiseksi, harkitse paikallista välimuistia usein toistuville etuliitteille, jos tarkistat suuria määriä salasanoja lyhyessä ajassa, esimerkiksi joukkoanalyysissä yrityksen vanhoille tunnuksille. Näin vähennät verkkokutsujen määrää merkittävästi ilman, että tinkeet tarkkuudesta millään tavalla.
Vaihe 7: Ota HIBP käyttöön Bitwardenissa
Jos käytät jo Bitwardenia (katso asennusohje Bitwardenin käyttöönotto-oppaastamme), pilvipalveluversiossa tietovuotoraportti löytyy verkkoholvista polusta Reports > Data Breach Report, ja se on käytössä oletuksena eikä vaadi mitään konfigurointia. Se käy koko holvisi läpi ja merkitsee jokaisen tunnuksen, jonka salasana on nähty HIBP:n Pwned Passwords -tietokannassa.
Jos sen sijaan ylläpidät itse isännöityä (self-hosted) Bitwarden-asennusta, sinun täytyy hankkia oma HIBP-API-avain ja lisätä se ympäristöasetuksiin ennen kuin raportti toimii:
# Muokkaa global.override.env -tiedostoa self-hosted-asennuksessa
globalSettings__hibpApiKey=SINUN_HIBP_API_AVAIMESI
# Käynnistä palvelut uudelleen muutoksen jälkeen
docker compose down
docker compose up -dIlman tätä avainta itse isännöity Bitwarden ei pysty hakemaan tietovuotodataa, ja Reports-välilehden Data Breach Report jää tyhjäksi tai näyttää virheilmoituksen. Tämä on yksi yleisimmistä syistä, miksi ylläpitäjät luulevat toiminnon olevan rikki, vaikka kyse on vain puuttuvasta avaimesta.
Kun raportti toimii, se jaottelee löydökset kolmeen kategoriaan: heikot salasanat, uudelleenkäytetyt salasanat ja HIBP:n listaamat vuotaneet salasanat. Kannattaa käydä läpi juuri kolmas kategoria ensin, koska se kertoo suoraan, mitkä holvisi tunnukset ovat todistetusti päätyneet rikollisten käsiin. Bitwarden ei automaattisesti vaihda salasanoja puolestasi, joten raportti toimii lähinnä priorisointityökaluna: se kertoo, mistä kannattaa aloittaa, kun tunnuksia on kymmeniä tai satoja.
Raportti kannattaa ajaa läpi säännöllisesti, esimerkiksi kerran kuukaudessa, sen sijaan että tarkistaisi sen vain kertaalleen käyttöönoton yhteydessä. Uusia tietovuotoja lisätään HIBP:hen jatkuvasti, joten holvi, joka näytti puhtaalta tammikuussa, voi sisältää useita vaaraan joutuneita tunnuksia jo maaliskuussa ilman, että olet itse tehnyt mitään väärin.
Vaihe 8: 1Password Watchtower ja muut integraatiot
1Password on integroinut HIBP:n Watchtower-toimintoonsa jo vuosia, ja se skannaa holvisi tunnukset tunnettuja vuotoja vasten paljastamatta itse sähköpostiosoitettasi HIBP:lle suoraan, samaa k-anonymiteettiperiaatetta hyödyntäen kuin salasanatarkistuksessa. Watchtower näkyy sovelluksen etusivulla omana välilehtenään ja päivittyy automaattisesti taustalla, joten erillistä vaihetta ei tarvita, kunhan käytät ajantasaista sovellusversiota.
Watchtower kokoaa saman näkymän alle myös muita tarkistuksia, kuten heikot salasanat, salasanojen uudelleenkäytön eri tileillä sekä vanhentuneet kaksivaiheisen tunnistautumisen menetelmät. Käytännössä tämä tarkoittaa, että voit priorisoida korjaustoimet yhdestä näkymästä sen sijaan, että kävisit läpi jokaisen tunnuksen erikseen manuaalisesti. Tämä on merkittävä etu erityisesti käyttäjille, joiden holvissa on useita satoja tallennettuja tunnuksia.
Jos vertailet salasanahallintaohjelmia ja mietit, kannattaako vaihtaa, katso vertailumme kolmesta suosituimmasta vaihtoehdosta artikkelista Bitwarden vs LastPass vs KeePass. Kaikki kolme tukevat jotain muotoa tietovuototarkistusta, mutta laajuus ja automaatioaste vaihtelevat merkittävästi.
KeePass eroaa näistä kahdesta siinä, ettei sillä ole natiivia, sisäänrakennettua HIBP-integraatiota, koska ohjelma on suunniteltu toimimaan täysin paikallisesti ilman pilviyhteyksiä. Jos käytät KeePassia, tietovuototarkistus kannattaa hoitaa erillisellä työkalulla, esimerkiksi tämän oppaan vaiheiden 3–6 Python-skriptillä, jota voi ajaa manuaalisesti aina, kun tuot uusia tunnuksia tietokantaan. Tämä on hyvä esimerkki siitä, että työkalun valinta vaikuttaa suoraan siihen, kuinka paljon manuaalista työtä tietovuotojen seuranta vaatii jatkossa.
Vaihe 9: Automatisoi jatkuva domain-seuranta
Jos vastaat yrityksesi tietoturvasta, yksittäisten sähköpostien manuaalinen tarkistus ei riitä. HIBP tarjoaa domain-haun, joka näyttää kaikki tunnettuihin vuotoihin päätyneet osoitteet omalla verkkotunnuksellasi. Domain-haku vaatii omistajuuden todistamisen DNS TXT -tietueella tai HTML-tiedostolla, ja DNS-tietue on yleensä nopeampi vaihtoehto, koska sen voi lisätä suoraan verkkotunnuksen DNS-hallintapaneelista ilman pääsyä itse verkkopalvelimelle. Vahvistuksen jälkeen ilmaistaso näyttää enintään kymmenen vuotanutta osoitetta ilman veloitusta. Suurempiin organisaatioihin on tarjolla maksullisia Pwned-tasoja, jotka kattavat rajattoman määrän osoitteita ja valinnaisesti myös stealer log -datan.
| Taso | Vuotaneet osoitteet | Stealer logit | Hinta/kk |
|---|---|---|---|
| Free | enintään 10 | Ei | 0 $ |
| Pwned 1 | enintään 25 | Ei | 4,50 $ |
| Pwned 2 | enintään 100 | Ei | 22 $ |
| Pwned 3 | enintään 500 | Ei | 37,50 $ |
| Pwned 4 | rajaton | Ei | 163 $ |
| Pwned 5 | rajaton | Kyllä | 326 $ |
Domain-hausta saatavaa dataa kannattaa yhdistää cron-ajastukseen, jotta uudet vuodot huomataan heti eikä vasta seuraavan manuaalisen tarkistuksen yhteydessä. Tähän palataan tarkemmin lopun täydellisessä esimerkkiprojektissa.
Kannattaa myös huomata, että domain-haun subscription-taso määräytyy sen mukaan, kuinka monta vuotanutta osoitetta verkkotunnuksellasi on kaikkiaan kaikissa ei-spam-listatuissa vuodoissa, ei sen mukaan, kuinka monta työntekijää organisaatiossasi on. Pienelläkin, muutaman hengen yrityksellä voi olla satoja vuotaneita osoitteita, jos verkkotunnusta on käytetty pitkään lukuisilla eri kolmansien osapuolten palveluilla, kun taas suurella organisaatiolla, joka on ottanut käyttöön tiukan salasanapolitiikan vasta hiljattain, luku voi olla yllättävän matala. Tämän vuoksi kannattaa tarkistaa oma tasosi käytännössä ennen kuin arvioit, mikä Pwned-taso riittää.
Vaihe 10: Mozilla Monitor ja selainhälytykset
Entinen Firefox Monitor, nykyinen Mozilla Monitor, käyttää edelleen HIBP:n tietokantaa taustallaan ja tarjoaa ilmaiseksi jatkuvan seurannan enintään 20 sähköpostiosoitteelle. Palvelu lähettää sähköposti-ilmoituksen heti, kun jokin seuratuista osoitteista löytyy uudesta vuodosta, mikä poistaa tarpeen käydä manuaalisesti tarkistamassa HIBP:n etusivulla. Tämä sopii erityisesti henkilöille, jotka haluavat passiivisen ratkaisun ilman skriptejä tai API-avaimia.
Jos käytät Firefoxia päivittäin, kannattaa yhdistää Monitor-seuranta muihin selaimen yksityisyysasetuksiin. Kävimme koko asetusvalikoiman läpi artikkelissa Firefoxin yksityisyysasetukset, joka täydentää tätä opasta hyvin.
Mozilla Monitor kannattaa nähdä ennen kaikkea turvaverkkona niille tileille, joita et jaksa tarkistaa säännöllisesti manuaalisesti, esimerkiksi vanhoille harrastesivustotileille tai kertaluontoisiin uutiskirjetilauksiin käytetyille osoitteille. Aktiivisessa käytössä oleville pääsähköposteille kannattaa silti pitää myös oma, tiheämpi tarkistusrutiini, koska Monitorin ilmoitukset saattavat viivästyä hieman verrattuna HIBP:n omaan, reaaliaikaisempaan tietokantaan.
Vaihe 11–12: Toimintasuunnitelma vuodon jälkeen ja GDPR-ilmoitus Suomessa
Vaihe 11. Kun löydät oman osoitteesi vuototietokannasta, tee tämä järjestyksessä: vaihda ensin salasana kyseiseen palveluun, tarkista sitten, oletko käyttänyt samaa salasanaa muualla ja vaihda se sielläkin, ota käyttöön kaksivaiheinen tunnistautuminen (mieluiten passkey tai autentikaattorisovellus, ei tekstiviesti), ja lopuksi tarkista tilin viimeaikainen aktiviteetti epäilyttävien kirjautumisten varalta. Salasanan salaamisesta sähköpostiviestinnässä kannattaa lukea lisää oppaastamme salatun sähköpostin käyttöönotosta, joka suojaa myös itse ilmoitusviestit uteluilta.
Vaihe 12. Jos vastaat organisaatiosi tietosuojasta ja huomaat oman yrityksesi datan vuotaneen, kello alkaa käydä heti. GDPR:n 33 artikla velvoittaa ilmoittamaan henkilötietojen tietoturvaloukkauksesta valvontaviranomaiselle ilman aiheetonta viivytystä ja mahdollisuuksien mukaan 72 tunnin kuluessa siitä, kun rikkomus on havaittu. Suomessa toimivaltainen viranomainen on tietosuojavaltuutetun toimisto, ja lisätietoa kyberturvallisuuden kokonaiskuvasta löytyy Traficomin Kyberturvallisuuskeskuksen sivuilta. Ilmoitus itse tietoturvaloukkauksesta tehdään tietosuojavaltuutetun toimiston sähköisellä lomakkeella. Tietosuojavaltuutetun toimiston vuoden 2025 vuosikertomuksen mukaan Suomessa tehtiin kyseisenä vuonna noin 7 355 tietoturvailmoitusta, mikä antaa hyvän mittakaavan siitä, kuinka rutiininomaiseksi prosessi on muodostunut suomalaisille organisaatioille.
Yksi tuoreimmista esimerkeistä suomalaisittain on Valtorin, valtionhallinnon ICT-keskuksen, alkuvuoden 2026 tietomurto, jossa hyökkääjät pääsivät käsiksi noin 50 000 valtion työntekijän sähköpostiosoitteisiin, puhelinnumeroihin ja laitetietoihin. Tapauksen taustalla oli haavoittuvuus valmisohjelmistossa, ja tutkinta on edelleen kesken kyberrikostutkinnan puolella. Tapaus osoittaa, että myös julkishallinnon toimijat tarvitsevat samat perusprosessit, joita tämä opas käy läpi: säännöllisen tarkistuksen, nopean reagoinnin ja lakisääteisen ilmoituksen 72 tunnin sisällä.
Käytännössä 72 tunnin kello käynnistyy siitä hetkestä, kun organisaatio kohtuudella voi todeta, että kyseessä on henkilötietoja koskeva tietoturvaloukkaus, ei siitä hetkestä, kun tapaus on ehditty tutkia loppuun. Käytännössä ilmoitus tehdään usein keskeneräisin tiedoin, ja sitä täydennetään myöhemmin, kun lisätietoa saadaan. Ilmoituksessa on kerrottava ainakin loukkauksen luonne, arvio vaikutuspiirissä olevien henkilöiden ja tietueiden määrästä, tietosuojavastaavan yhteystiedot sekä toimenpiteet, joilla vahinkoa pyritään rajoittamaan. Jos loukkaus todennäköisesti aiheuttaa korkean riskin rekisteröityjen oikeuksille ja vapauksille, myös rekisteröidyille itselleen on ilmoitettava erikseen, ei ainoastaan valvontaviranomaiselle.
HIBP:n rajoitukset: mitä palvelu ei kerro sinulle
Have I Been Pwned on korvaamaton työkalu, mutta se ei ole täydellinen kuva koko uhkakentästä, ja tämä kannattaa ymmärtää ennen kuin luotat siihen sokeasti. Ensinnäkin, palvelu näyttää vain sen datan, jonka Troy Huntin tiimi on saanut käsiinsä ja ehtinyt indeksoida. Moni pienempi tai kohdennetumpi tietovuoto ei koskaan päädy HIBP:hen, koska sitä ei jaeta julkisesti tai laajasti hakkerifoorumeilla, vaan se myydään suoraan rajatulle ostajajoukolle. Käytännössä “ei osumia” -tulos ei ole tae siitä, että tunnuksesi ovat täysin turvassa, vaan ainoastaan siitä, ettei tunnettua, laajaa vuotoa ole toistaiseksi löydetty.
Toiseksi, vuodon tapahtumishetken ja HIBP:hen lisäämisen välillä on usein kuukausien tai jopa vuosien viive. Data Troll -tapauksessa alkuperäinen vuoto tapahtui kesäkuussa 2025, mutta se lisättiin palveluun vasta elokuussa 2025. Synthient-datan kohdalla väli oli samaa luokkaa. Käytännössä rikolliset ovat saattaneet käyttää tunnuksiasi kuukausia ennen kuin sinulla on ollut mahdollisuutta edes tietää vuodosta HIBP:n kautta. Juuri tämän vuoksi vaiheessa 11 kuvattu tapa, eli salasanojen säännöllinen vaihtaminen ja kaksivaiheisen tunnistautumisen käyttö riippumatta siitä, onko tunnusta havaittu vuodoksi, on tärkeämpää kuin pelkkä reaktiivinen tarkistus.
Kolmanneksi, sensitiiviset vuodot eivät näy domain-haussa lainkaan, kuten aiemmin mainittiin, joten organisaation koko riskikuva vaatii myös muita työkaluja, kuten pimeän verkon seurantapalveluita tai uhkatiedustelun syötteitä. HIBP kannattaa siis nähdä yhtenä kerroksena laajemmassa tietoturvan kokonaisuudessa, ei ainoana tarvittavana työkaluna.
Neljänneksi, palvelu ei kerro mitään siitä, onko juuri sinun tunnuksiasi käytetty aktiivisesti väärin, vaan ainoastaan sen, että ne ovat teoriassa jonkun rikollisen saatavilla. Näiden kahden asian erottaminen toisistaan on tärkeää viestinnässä, esimerkiksi kun selität tilannetta johdolle tai asiakkaille: “tunnuksesi löytyy vuototietokannasta” ei ole sama asia kuin “tiliäsi on murrettu”, vaikka molemmat vaativat samat suojaustoimenpiteet varmuuden vuoksi.
Täydellinen esimerkkiprojekti: tiimin automaattinen valvontaskripti
Alla on kokonainen, toimiva projekti, joka tarkistaa listan sähköpostiosoitteita HIBP:n breach-API:n kautta (vaatii Pwned-tason API-avaimen), tallentaa uudet vuodot tiedostoon ja lähettää hälytyksen Slack-webhookiin. Skripti sopii ajettavaksi viikoittain cronilla tai Task Schedulerilla.
Projektin rakenne on tarkoituksella yksinkertainen, jotta sen pystyy ottamaan käyttöön ilman erillistä tietokantapalvelinta tai pilvi-infrastruktuuria. Tarvitset kolme tiedostoa samassa kansiossa: itse skriptin (monitor.py), tekstitiedoston seurattavista sähköposteista (emails.txt, yksi osoite per rivi) sekä tilatiedoston, jonka skripti luo itse ensimmäisellä ajokerralla (known_breaches.json). Käytännön asennus etenee näin: luo kansio /opt/hibp-monitor, tallenna skripti sinne, lisää sähköpostilista, aseta ympäristömuuttujat ja testaa ensin manuaalisesti ennen cron-ajastuksen käyttöönottoa.
# monitor.py – täydellinen tiimin vuotoseuranta
import json
import os
import time
import urllib.request
from pathlib import Path
API_KEY = os.environ["HIBP_API_KEY"]
SLACK_WEBHOOK = os.environ["SLACK_WEBHOOK_URL"]
EMAILS_FILE = Path("emails.txt")
STATE_FILE = Path("known_breaches.json")
def fetch_breaches(email: str) -> list:
url = f"https://haveibeenpwned.com/api/v3/breachedaccount/{email}"
req = urllib.request.Request(url, headers={
"hibp-api-key": API_KEY,
"User-Agent": "team-hibp-monitor"
})
try:
with urllib.request.urlopen(req, timeout=10) as resp:
return json.loads(resp.read().decode("utf-8"))
except urllib.error.HTTPError as e:
if e.code == 404:
return []
raise
def slack_alert(email: str, breach_name: str) -> None:
payload = {"text": f":rotating_light: Uusi tietovuoto: *{email}* löytyi vuodosta *{breach_name}*"}
req = urllib.request.Request(
SLACK_WEBHOOK,
data=json.dumps(payload).encode("utf-8"),
headers={"Content-Type": "application/json"},
)
urllib.request.urlopen(req, timeout=10)
def main() -> None:
known = json.loads(STATE_FILE.read_text()) if STATE_FILE.exists() else {}
emails = [line.strip() for line in EMAILS_FILE.read_text().splitlines() if line.strip()]
for email in emails:
breaches = fetch_breaches(email)
seen = known.get(email, [])
for breach in breaches:
name = breach["Name"]
if name not in seen:
slack_alert(email, name)
seen.append(name)
known[email] = seen
time.sleep(6) # pysy Pwned 1 -tason 10 kyselyä/min rajassa
STATE_FILE.write_text(json.dumps(known, indent=2))
if __name__ == "__main__":
main()Cron-ajastus (Linux/macOS), joka ajaa skriptin joka maanantai kello 08:00:
crontab -e
# Lisää rivi:
0 8 * * 1 cd /opt/hibp-monitor && HIBP_API_KEY=xxx SLACK_WEBHOOK_URL=xxx python3 monitor.py >> monitor.log 2>&1Projekti tallentaa jo nähdyt vuodot known_breaches.json-tiedostoon, joten hälytys lähtee vain uusista löydöksistä, ei samasta vuodosta joka viikko uudelleen. time.sleep(6)-rivi pitää huolen siitä, ettet ylitä halvimman Pwned 1 -tason kymmenen kyselyn minuuttirajaa.
Jos tiimisi sähköpostilista kasvaa yli 25 osoitteen, kannattaa harkita korkeampaa Pwned-tasoa jo pelkästään nopeuden vuoksi: 50 osoitteen listan tarkistus kestäisi Pwned 1 -tasolla noin viisi minuuttia, kun taas Pwned 2 -tasolla saman listan ehtii käydä läpi murto-osassa ajasta. Skriptiä voi laajentaa myös lähettämään yhteenvedon sähköpostitse jokaisen ajon jälkeen riippumatta siitä, löytyikö uusia vuotoja, jotta tiimi näkee valvonnan olevan aktiivinen eikä vain hiljaa taustalla.
Yleisimmät virheet tietovuototarkistuksessa
Seuraavat virheet toistuvat säännöllisesti, kun kehittäjät ja ylläpitäjät ottavat HIBP:n integraatioita käyttöön ensimmäistä kertaa. Suurin osa niistä on helppo välttää, kunhan tietää etukäteen, mistä ne johtuvat.
- Salasanan lähettäminen suoraan API:in. Älä koskaan lähetä täyttä salasanaa tai edes täyttä SHA-1-tiivistettä ulkopuoliselle palvelulle, vaikka löytäisit siihen valmiin koodiesimerkin jostain vanhasta blogista. Käytä aina range-API:a viiden merkin etuliitteellä, kuten vaiheissa 3–4 näytettiin, ja tarkista koodikatselmuksessa erikseen, ettei kukaan tiimissä ole vahingossa toteuttanut tarkistusta väärin.
- Email-breach-API:n sekoittaminen Pwned Passwords -API:in. Salasanatarkistus on ilmainen ja avaimeton, mutta sähköpostiosoitteen breach-haku API:n kautta vaatii aina maksullisen avaimen. Moni kehittäjä yrittää kutsua breachedaccount-päätepistettä ilman avainta ja saa vain 401-virheen, minkä jälkeen turhaan epäilee koko rajapinnan olevan poissa käytöstä.
- Liian tiheä kyselytahti. Halvin API-taso sallii vain 10 kyselyä minuutissa. Ilman viivettä koodissa saat nopeasti 429 Too Many Requests -virheitä, kuten esimerkkiprojektin
time.sleep(6)-rivi ehkäisee. Suurilla listoilla kannattaa laskea etukäteen, kuinka kauan koko ajo kestää, jotta cron-ajastus ei mene päällekkäin seuraavan ajon kanssa. - Vanhojen tilien unohtaminen. Suurin osa ihmisistä tarkistaa vain aktiivisen sähköpostinsa, vaikka juuri kymmenen vuoden takainen unohdettu Hotmail- tai Yahoo-tili sisältää usein salasanan, jota käytetään yhä nykyisissä palveluissa, koska sitä ei ole koskaan vaihdettu sen jälkeen, kun tili jäi käyttämättömäksi.
- Domain-haun todentamisen laiminlyönti. Yritysten domain-haku ei toimi ennen kuin omistajuus on todistettu DNS TXT -tietueella tai HTML-tiedostolla. Moni ylläpitäjä luulee toiminnon olevan poissa käytöstä, vaikka kyse on vain puuttuvasta vahvistuksesta, joka olisi voitu hoitaa muutamassa minuutissa.
- Ilmoitusvelvollisuuden unohtaminen. Yksityishenkilön ei tarvitse ilmoittaa mitään viranomaiselle, mutta jos kyse on organisaation hallussa olevasta asiakas- tai työntekijädatasta, GDPR:n 72 tunnin sääntö käynnistyy heti havaitsemishetkellä, ei vasta tutkinnan valmistuttua. Moni organisaatio tekee virheen odottamalla, että kaikki yksityiskohdat ovat selvillä ennen ensimmäistä ilmoitusta, vaikka ilmoitusta voi ja pitää täydentää myöhemmin.
Vianmääritys: yleiset ongelmat ja ratkaisut
Jos jokin edellä kuvatuista vaiheista ei toimi odotetusti, alla oleva taulukko kattaa kahdeksan yleisintä ongelmaa, joita lukijat ja kehittäjät ovat kohdanneet HIBP:n API:a ja siihen liittyviä integraatioita käyttöönottaessaan. Käy taulukko läpi ennen kuin oletat viasta olevan kyse itse palvelussa, sillä valtaosa ongelmista juontuu paikallisesta konfiguraatiosta.
| Ongelma | Todennäköinen syy | Ratkaisu |
|---|---|---|
| API palauttaa 401 Unauthorized | hibp-api-key-otsake puuttuu tai on väärä | Tarkista avain haveibeenpwned.com-tililtäsi ja lisää se pyynnön otsakkeisiin |
| API palauttaa 429 Too Many Requests | Kyselyjä liikaa minuutissa | Lisää viive (esim. 6 sekuntia Pwned 1 -tasolla) tai päivitä korkeampaan tasoon |
| Range-API palauttaa tyhjän vastauksen | Etuliite kirjoitettu pienillä kirjaimilla tai virheellisesti | Käytä isoja kirjaimia SHA-1-tiivisteessä ja tarkista, että lähetät tasan viisi merkkiä |
| Bitwardenin Data Breach Report on tyhjä self-hosted-asennuksessa | globalSettings__hibpApiKey puuttuu ympäristöasetuksista | Lisää avain global.override.env-tiedostoon ja käynnistä kontit uudelleen |
| Domain-haku näyttää “Verification required” | DNS TXT -tietuetta tai HTML-tiedostoa ei ole vielä lisätty | Lisää HIBP:n antama vahvistustunniste DNS-palveluun ja odota TTL:n verran |
| Python-skripti heittää urllib.error.HTTPError: 404 | Sähköposti ei ole yhdessäkään vuodossa, mikä on normaalia | Käsittele 404 erikseen ja tulkitse se “ei osumia” -tilana, älä virheenä |
| Slack-hälytys ei saavu | Webhook-URL vanhentunut tai kanava poistettu | Luo uusi webhook Slackin App-hallinnasta ja päivitä ympäristömuuttuja |
| Sama vuoto hälyttää joka viikko uudelleen | known_breaches.json ei tallennu pysyvästi (esim. kontti nollautuu) | Liitä tiedosto pysyvään taltioon tai käytä ulkoista tietokantaa tilan säilytykseen |
Kaksi viimeistä riviä taulukossa liittyvät toisiinsa ja kannattaa ratkaista yhdessä, jos ajat esimerkkiprojektia konttiympäristössä, kuten Dockerissa tai Kubernetesissa. Kontit menettävät oletuksena kaiken paikallisen tiedoston sisällön uudelleenkäynnistyksen yhteydessä, ellei erikseen määritä pysyvää taltiota (volume). Tämä on yksi yleisimmistä syistä, miksi automaatioprojekti näyttää toimivan hetken, mutta alkaa lähettää duplikaattihälytyksiä muutaman viikon kuluttua käyttöönotosta.
Edistyneet vinkit ammattilaisille
Perusvalvonta riittää yksityishenkilölle ja pienelle tiimille, mutta jos vastaat isomman organisaation tietoturvasta, kannattaa viedä prosessi pidemmälle. Alla neljä käytännön askelta, jotka nostavat tietovuotoseurannan reaktiivisesta tarkistuksesta osaksi ennaltaehkäisevää tietoturva-arkkitehtuuria.
Kun perusvalvonta on pystyssä, muutama lisäys nostaa prosessin tuotantotasolle. Ensinnäkin, yhdistä Pwned Passwords -tarkistus suoraan omaan rekisteröitymislomakkeeseesi, jos rakennat verkkopalvelua: hylkää salasana rekisteröinnin yhteydessä, jos se löytyy vuototietokannasta, aivan kuten NIST SP 800-63B suosittelee. Tämä on huomattavasti tehokkaampi kuin pelkkä pituus- tai merkkivaatimus, koska se estää konkreettisesti jo murrettujen salasanojen uudelleenkäytön.
Toiseksi, jos organisaatiosi käsittelee suuria käyttäjämääriä, harkitse Pwned Passwords -datasetin lataamista offline-käyttöön Cloudflaren tarjoaman peilipalvelun kautta sen sijaan, että jokainen rekisteröityminen tekisi verkkokyselyn. Tämä poistaa ulkoisen riippuvuuden ja nopeuttaa vastausaikaa merkittävästi suurella liikennemäärällä.
Kolmanneksi, siirry vähitellen tekstiviestipohjaisesta kaksivaiheisesta tunnistautumisesta passkeyihin niissä palveluissa, jotka niitä tukevat. Passkey ei ole koskaan “vuotanut salasana”, koska yksityinen avain ei koskaan poistu laitteeltasi, mikä poistaa kokonaisen hyökkäysvektorin listalta. Tekstiviestipohjainen tunnistautuminen on lisäksi altis SIM-vaihtopetoksille, joissa rikollinen huijaa operaattorin siirtämään uhrin numeron omaan SIM-korttiinsa, mikä ei koske passkey-pohjaista tunnistautumista lainkaan.
Neljänneksi, jos hallinnoit useita verkkotunnuksia, automatisoi domain-haun tulokset samaan monitor.py-tyyliseen skriptiin ja aja se päivittäin isommilla organisaatioilla, viikoittain riittää pienemmille tiimeille. Stealer log -data (Pwned 5 -taso) kannattaa erityisesti organisaatioille, joiden työntekijät käyttävät henkilökohtaisia laitteita työasioihin, koska stealer-haittaohjelmat keräävät nimenomaan selaimeen tallennettuja työtunnuksia.
Viidenneksi, kirjaa jokainen tietovuotolöydös ja siihen reagointi omaan lokiin, erillään pelkästä Slack-hälytyksestä. Kun tietosuojavaltuutetun toimisto tai sisäinen tarkastus kysyy myöhemmin, miten organisaatio havaitsi ja käsitteli tietyn tapauksen, valmis aikaleimattu loki säästää huomattavasti aikaa verrattuna siihen, että tiedot pitäisi kaivaa jälkikäteen Slack-historian tai sähköpostien seasta.
Usein kysytyt kysymykset
Onko Have I Been Pwned turvallinen ja luotettava palvelu?
Kyllä. Palvelu on toiminut vuodesta 2013 lähtien, sitä käyttävät muun muassa Mozilla, 1Password ja lukuisat viranomaiset osana omia tietoturvatyökalujaan, ja sen taustalla oleva k-anonymiteettitekniikka on avoimesti dokumentoitu. Troy Hunt julkaisee myös säännöllisesti läpinäkyviä blogikirjoituksia siitä, mitä uusia vuotoja on lisätty ja miksi, mikä erottaa palvelun monista epämääräisemmistä “tarkista salasanasi” -sivustoista.
Maksaako sähköpostini tarkistus mitään?
Ei. Sähköpostiosoitteen ja salasanan tarkistus haveibeenpwned.com-sivun kautta on täysin ilmaista yksityishenkilöille. Maksu tulee kyseeseen vain, jos haluat käyttää sähköposti-breach-API:a ohjelmallisesti tai jos tarvitset domain-haun ilmaistasoa laajemman kattavuuden.
Näkeekö HIBP oikean salasanani, kun tarkistan sen?
Ei koskaan. Salasana muunnetaan SHA-1-tiivisteeksi paikallisesti laitteellasi, ja palvelimelle lähtee ainoastaan tiivisteen ensimmäiset viisi merkkiä. Palvelin ei näe koko tiivistettä eikä varsinkaan alkuperäistä salasanaa.
Mitä minun pitää tehdä, jos löydän itseni tietovuodosta?
Vaihda ensin kyseisen palvelun salasana, tarkista, oletko käyttänyt samaa salasanaa muualla, ota käyttöön kaksivaiheinen tunnistautuminen ja seuraa tiliäsi epäilyttävän aktiviteetin varalta muutaman viikon ajan. Jos vuoto sisälsi myös maksukorttitietoja, ota lisäksi yhteyttä pankkiisi ja harkitse kortin uusimista, vaikka mitään väärinkäyttöä ei olisi vielä havaittu.
Onko yrityksellä pakko ilmoittaa tietovuodosta viranomaiselle?
Kyllä, jos kyse on henkilötietojen tietoturvaloukkauksesta. GDPR:n 33 artikla velvoittaa ilmoittamaan valvontaviranomaiselle, Suomessa tietosuojavaltuutetun toimistolle, ilman aiheetonta viivytystä ja pääsääntöisesti 72 tunnin kuluessa havaitsemisesta.
Voiko HIBP-dataa käyttää osana omaa sovellustani?
Kyllä. Pwned Passwords -API on ilmainen ja avaimeton kenelle tahansa kehittäjälle. Sähköposti-breach-API vaatii maksullisen avaimen, halvin taso Pwned 1 maksaa 4,50 dollaria kuukaudessa ja sallii 10 kyselyä minuutissa.
Mikä ero on Mozilla Monitorilla ja suoralla HIBP-tarkistuksella?
Mozilla Monitor käyttää samaa HIBP-tietokantaa taustalla, mutta lisää siihen jatkuvan, automaattisen sähköposti-ilmoituksen enintään 20 osoitteelle ilmaiseksi. Suora HIBP-sivu vaatii manuaalisen tarkistuksen joka kerta.
Kuinka usein tietovuototarkistus kannattaa tehdä?
Yksityishenkilölle riittää, että ottaa käyttöön jatkuvan ilmoituspalvelun kuten Mozilla Monitorin tai Bitwardenin automaattisen raportin. Yrityksille suosittelemme viikoittaista automaattista domain-tarkistusta, kuten tämän oppaan esimerkkiprojektissa. Kriittisiä järjestelmiä ylläpitäville tiimeille päivittäinen tarkistus on perusteltu, koska stealer log -data päivittyy HIBP:hen usein epäsäännöllisin väliajoin, joskus useita kertoja samalla viikolla.
Tietovuototarkistus ei ole kertaluontoinen tehtävä, vaan rutiini, joka kannattaa kytkeä osaksi laajempaa salasana- ja tunnistautumishygieniaa. Kun sähköpostin ja salasanan tarkistus, salasananhallinnan integraatiot ja organisaation domain-seuranta ovat kaikki paikallaan, tietovuodon havaitseminen muuttuu tunneista tai päivistä minuuteiksi, ja se on juuri se aikaikkuna, jolla rikollinen ehtii tehdä vahinkoa tunnuksillasi.
