Kaksi vaihetta ei välttämättä tarkoita kahta tekijää: salasana ja PIN ovat molemmat tietoon perustuvia. Biometria voi aktivoida tunnistimen, mutta ei yksin takaa anonymiteettiä tai tietojenkalastelun kestävyyttä.
Vertaa mekanismeja, älä näyttöjen määrää
NIST erottaa tiedon, hallussa olevan välineen ja biometriset ominaisuudet. Käsin syötetty kertakoodi voidaan välittää huijaussivun kautta; SMS ja TOTP eivät siis vastaa kalastelunkestävää tunnistautumista. Oikein toteutettu pääsyavain sitoo vastauksen palveluun. Suoja riippuu myös paikallisesta varmennuksesta sekä varmuuskopioinnista ja synkronoinnista.
Ymmärrä biometrian rooli
WebAuthnissa biometrinen tunnistus voi tapahtua tunnistimessa; biometrisiä tietoja ei välitetä vastaanottavalle verkkopalvelulle. Paikallinen varmennus voi käyttää myös PIN-koodia. Käyttäjän läsnäolo (UP) ja varmennus (UV) ovat eri asioita. Palvelimen on tarkistettava vastaus protokollan mukaan; kasvojentunnistusnäkymä ei riitä.
Suojaa elinkaari
Suunnittele rekisteröinti, uuden menetelmän lisääminen, laitteen menetys, peruminen ja tilin palautus. Arvioi saavutettavuus ja varamenetelmät, jotka voivat heikentää pääreittiä. Tunnistautuminen ei korvaa tietojen ja toimintojen käyttöoikeuksia.
Lähteet
Toimituksellinen tarkistus: 1. marraskuuta 2026.
Erota toinen tekijä tietojenkalasteluhyökkäysten estämisestä
NIST huomauttaa, että huijarisivu voi välittää manuaalisesti syötetyn kertakäyttöisen koodin, joten sen olemassaolo yksinään ei tee kirjautumisesta tietojenkalasteluhyökkäysten kestävää. Oikein integroitu WebAuthn sitoo vastauksen aitoon palveluun. Tilin palauttaminen on edelleen turvallinen tie.
- Listaa sovellukset, jotka edelleen hyväksyvät tekstiviestejä, koodeja tai ohitettavissa olevia hyväksyntöjä, ja priorisoi käyttöoikeutettuja tilejä.
- Testaa rekisteröitymistä, laitteen katoamista ja peruuttamista todellisen käyttäjäpolun kautta.
- Mittaa vastustuskykytekijän kattavuutta ja pidä poikkeukset päivättyinä omistajien kanssa.
Ensisijainen lähde: NIST SP 800-63B-4. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Passkeyt: verkkotunnuksen ja RP ID:n vaihto
Erota tili, verkkoalkuperä ja RP ID, jotta tunnistetietoja ei siirretä hiljaisesti uuteen rajaukseen.
- Kirjaa vanhat ja uudet alkuperät, RP ID:t ja niihin liittyvät tilit. Sama tilinimi ei tee passkeysta kelvollista toiselle RP ID:lle. Tarkista WebAuthnin sallimat yhdistelmät ja siirtymän aikana toimivat pääsypolut.
- Tarkista valtuutetussa testiympäristössä haaste, alkuperä, RP ID ja tilisidonta sopivalla kirjastolla. Testaa odottamaton alkuperä ja toistettu haaste. RP ID:n vaihto vaatii uuden tunnistetun rekisteröinnin; rivin kopiointi ei siirrä avainta.
- Testaa käyttäjä, jolla on vain vanha tunniste, palautuminen ja avoimet istunnot. Määritä polkujen avaus ja poisto testatulla paluulla. Rekisteröinti uudessa tunnuksessa ei osoita kaikkien vanhojen istuntojen peruuttamista.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}Odotettu päätös
Kuvitteellinen esimerkki: tili säilyy, mutta old.example vaihtuu new.exampleksi eri RP ID:llä. Vanhaa tunnistetta ei voi hiljaisesti siirtää; uusi rekisteröinti seuraa suunniteltua tunnistettua polkua.
Voiko tietokantamuutos vaihtaa passkeyn RP ID:n?
Ei. RP ID kuuluu tunnisteen varmennettuun rajaukseen. Valmistele kelvollinen uusi rekisteröinti ja tunnistettu tilikytkentä.
Ensisijainen lähde: W3C — Web Authentication Level 2. Aiheeseen liittyvä menetelmä: lue käytännön opas.
postMessage: tarkista alkuperä, ikkuna ja komento
Määritä iframe- tai ponnahdusikkunan viestisopimus, joka hylkää odottamattomat lähettäjät ja tiedot.
- Luettele tarkat alkuperät, odotettu ikkunaviite ja hyödylliset tyypit. Käytä täsmällistä targetOrigin-arvoa arkaluonteisille tiedoille. Alkuperään kuuluvat protokolla, isäntä ja portti; verkkotunnuksen osamerkkijonohaku ei varmista lähettäjää.
- Vertaa event.origin ja tässä integraatiossa event.source odotettuun ikkunaan. Tarkista skeema, sallitut arvot ja toiminnon tila. Käsittele sisältö tietona ilman eval-kutsua tai HTML-lisäystä. Sallittu alkuperä ei korvaa palvelimen käyttöoikeustarkistusta.
- Testaa samankaltainen verkkotunnus, eri portti, toinen saman alkuperän ikkuna, virheelliset kentät ja sulkemisen jälkeiset viestit. Poista tarpeettomat kuuntelijat ja mitätöi päättyneet vaihdot. Vastaa vain ennalta hyväksyttyyn alkuperään myös navigoinnin jälkeen.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"allowed_origin": "https://widget.example",
"observed_origin": "https://widget.example",
"expected_window": "active_iframe",
"observed_window": "another_window",
"payload_schema_valid": true,
"expected": "reject_without_effect"
}Odotettu päätös
Kuvitteellinen esimerkki: https://widget.example on sallittu, mutta event.source on toinen ikkuna. Sopimus edellyttää aktiivista iframe-ikkunaa: hylkää viesti ilman komentoa.
Ensisijainen lähde: MDN — Window.postMessage. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Identiteetti: tekijät, istunnot ja palautus
Kaksi tekijää: tarkista protokolla, ei vain käyttöliittymää
Syötetyt koodit, push-hyväksynnät ja WebAuthn-vastaukset sitoutuvat palveluun eri tavoin. Biometria voi aktivoida tunnistimen, mutta ei korvaa vastauksen kryptografista tarkistusta.
- Aktivoi paikallisesti — PIN tai biometria laitteen mukaan.
- Allekirjoita vastaus — Palveluun sidottu avain ja saatu haaste.
- Tarkista palvelimella — Haaste, alkuperä, allekirjoitus ja liput.
- Valtuuta toiminto — Kohteen ja toiminnon oikeudet.
- Tarkastele UP- ja UV-lippuja erikseen.
- Tarkista tarvittavat synkronoinnin ja avainten viennin rajoitukset.
- Harjoittele menetystä ja uuden menetelmän liittämistä olemassa olevasta istunnosta.
Tutustu identiteetin kontrolleihin →
Lähteet tarkistettu · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3
Laajennukset: oikeudet ja käyttö
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
Robust authentication does not describe extension access
Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.
- Test approved extensions in a profile dedicated to sensitive operations.
- For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
- Distinguish session revocation, token revocation, extension disablement and native-component removal.
Read the permission directory and manifest examples →
Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent