Passkeys: Mitä ihmettä ja miksi?

Julkaissut Platon

seuraajia: 0

Nämä asiat ns salasanat tekevät varmasti kierroksia näinä päivinä. Ne olivat tärkein nähtävyys W3C TPAC 2022, sai tukea vuonna Safari 16, löytävät tiensä macOS ja iOS, ja niiden on määrä olla 1Passwordin kaltaisten salasanojen hallintaohjelmien tulevaisuus. He ovat jo tuettu Androidissa, ja ne löytävät pian tiensä Chrome-käyttöjärjestelmään ja Windowsiin tulevissa julkaisuissa.

Geeky OS -tietoturvaparannukset eivät juuri nouse suuriin otsikoihin käyttöliittymäyhteisössä, mutta on selvää, että salasanat tulevat olemaan "juttu". Ja kun otetaan huomioon, kuinka salasanat ja salasanasovellukset vaikuttavat käyttökokemukseen esimerkiksi todentamisessa ja lomakkeiden käsittelyssä, saatamme haluta ainakin miettiä niitä, jotta tiedämme, mitä tuleman pitää.

Se on tämän artikkelin pointti. Olen tutkinut ja kokeillut salasanoja – ja niiden päälle rakennettua WebAuthn APIa – jo jonkin aikaa. Haluan jakaa mitä olen oppinut.

Sisällysluettelo

Terminologia

Tässä on pakollinen osio terminologiasta, jonka haluat tietää, kun perehdymme asiaan. Kuten useimmat tekniikat, salasanat on valmistettu esoteerisella sanamuodolla ja lyhenteillä, jotka ovat usein esteitä ymmärtämiselle. Yritän tyhjentää sinulle useita mystioita täällä.

Luottava osapuoli: palvelin, jota vastaan todennetaan. Käytämme sanaa "palvelin" viittaamaan luottavaan osapuoleen tässä artikkelissa.
Asiakas: meidän tapauksessamme selain tai käyttöjärjestelmä.
Todentaja: Ohjelmistot ja/tai laitteistot, jotka mahdollistavat julkisten avainparien luomisen ja tallentamisen.
FIDO: Avointen standardien elin, joka luo myös määrityksiä FIDO-tunnistetietojen ympärille.
WebAuthn: Salasanojen taustalla oleva protokolla, joka tunnetaan myös nimellä a FIDO2 valtuustiedot tai yhden laitteen FIDO-kirjautumistiedot.
Salasanat: WebAuthn, mutta pilvisynkronoinnilla (kutsutaan myös usean laitteen FIDO-kirjautumistiedoiksi, löydettäviksi tunnistetiedoiksi tai paikallisiksi kirjautumistiedoiksi).
Julkisen avaimen kryptografia: Luotu avainpari, joka sisältää yksityisen ja julkisen avaimen. Algoritmista riippuen sitä tulee käyttää joko allekirjoittamiseen ja todentamiseen tai salaukseen ja salauksen purkamiseen. Tämä tunnetaan myös nimellä epäsymmetrinen salaus.
RSA: Lyhenne tekijöiden nimistä Rivest Shamir ja Adel. RSA on vanhempi, mutta silti hyödyllinen julkisen avaimen salausperhe, joka perustuu factoring-alkulukuihin.
Elliptisen käyrän kryptografia (ECC): Uudempi salausperhe perustuu elliptisiin käyriin.
ES256: Elliptisen käyrän julkinen avain, joka käyttää ECDSA-allekirjoitusalgoritmia (PDF) Kanssa SHA256 hajauttamisesta.
RS256: Kuten ES256, mutta se käyttää RSA:ta RSASSA-PKCS1-v1.5 ja SHA256.

Mitä ovat salasanat?

Ennen kuin voimme puhua nimenomaan pääsyavaimista, meidän on puhuttava toisesta protokollasta WebAuthn (tunnetaan myös nimellä FIDO2). Salasanat ovat WebAuthnin päälle rakennettu määritys. WebAuthn mahdollistaa julkisen avaimen salauksen korvaamaan salasanat. Käytämme jonkinlaista turvalaitetta, kuten laitteistoavainta tai Trusted Platform Module (TPM), luodaksesi yksityisiä ja julkisia avaimia.

Julkinen avain on kaikkien käytettävissä. Yksityistä avainta ei kuitenkaan voi poistaa sen luoneesta laitteesta. Tämä oli yksi WebAuthnin ongelmista; Jos kadotat laitteen, menetät pääsyn siihen.

Passkeys ratkaisee tämän tarjoamalla käyttäjätietojesi pilvisynkronoinnin. Toisin sanoen sitä, mitä luot tietokoneellasi, voidaan nyt käyttää myös puhelimessasi (vaikka hämmentävästi on olemassa myös yhden laitteen tunnistetietoja).

Tällä hetkellä tätä kirjoitettaessa vain iOS, macOS ja Android tarjoavat täyden tuen pilvisynkronoiduille avaimille, ja silloinkin niitä rajoittaa käytettävä selain. Google ja Apple tarjoavat käyttöliittymän synkronointia varten Googlen salasananhallinta ja Applen iCloud-avainnippu palvelut.

Miten salasanat korvaavat salasanat?

Julkisen avaimen kryptografiassa voit suorittaa ns allekirjoittaminen. Allekirjoitus ottaa osan tiedosta ja suorittaa sen sitten allekirjoitusalgoritmin läpi yksityisellä avaimella, jossa se voidaan sitten vahvistaa julkisella avaimella.

Kuka tahansa voi luoda julkisen avainparin, eikä se ole kenenkään henkilön syyksi, koska kuka tahansa olisi voinut luoda sen alun perin. Hyödyllistä on se, että vain yksityisellä avaimella allekirjoitetut tiedot voidaan varmistaa julkisella avaimella. Se on se osa, joka korvaa salasanan – palvelin tallentaa julkisen avaimen, ja me kirjaudumme sisään varmistamalla, että meillä on toinen puolikas (esim. yksityinen avain), allekirjoittamalla satunnaisen haasteen.

Lisäetuna on se, että koska tallennamme käyttäjien julkiset avaimet tietokantaan, ei ole enää huolta miljooniin käyttäjiin kohdistuvista salasanamurroista. Tämä vähentää tietojenkalastelua, tietomurtoja ja monia muita turvallisuusongelmia, joita salasanasta riippuvainen maailmamme tällä hetkellä kohtaa. Jos tietokanta rikotaan, kaikki se on tallennettu käyttäjän julkisiin avaimiin, mikä tekee siitä käytännössä hyödyttömän hyökkääjälle.

Ei myöskään enää unohdettuja sähköposteja ja niihin liittyviä salasanoja! Selain muistaa, mitä tunnistetietoja käytit millä verkkosivustolla – sinun tarvitsee vain napsauttaa muutama napsautus ja olet kirjautunut sisään. Voit tarjota toissijaisen vahvistustavan salasanan käyttöä varten, kuten biometriset tiedot tai PIN-koodi. , mutta ne ovat silti paljon nopeampia kuin menneen vuoden salasanat.

Lisää kryptografiasta

Julkisen avaimen salaus sisältää yksityisen ja julkisen avaimen (tunnetaan avainparina). Avaimet luodaan yhdessä ja niillä on eri käyttötarkoitukset. Esimerkiksi yksityinen avain on tarkoitettu pidettäväksi salassa ja julkinen avain on tarkoitettu kaikille, joiden kanssa haluat vaihtaa viestejä.

Viestin salauksessa ja salauksen purkamisessa käytetään viestin salaamiseen vastaanottajan julkista avainta niin, että vain vastaanottajan yksityinen avain voi purkaa viestin. Turvallisuuskielessä tätä kutsutaan "luottamuksellisuuden tarjoamiseksi". Tämä ei kuitenkaan tarjoa todistetta siitä, että lähettäjä on se, jota he sanovat olevansa, koska kuka tahansa voi mahdollisesti käyttää julkista avainta lähettääkseen jollekin salatun viestin.

Joissakin tapauksissa meidän on varmistettava, että viesti todella tuli sen lähettäjältä. Näissä tapauksissa käytämme allekirjoitusta ja allekirjoituksen vahvistusta varmistaaksemme, että lähettäjä on se, joka he sanovat olevansa (tunnetaan myös nimellä aitous). Julkisella avaimella (kutsutaan myös epäsymmetrinen) kryptografia, tämä tehdään yleensä allekirjoittamalla viestin hash, jotta vain julkinen avain voi varmistaa sen oikein. Hash ja lähettäjän yksityinen avain tuottavat allekirjoituksen, kun se on suoritettu algoritmin läpi, ja sitten kuka tahansa voi varmistaa, että viesti tuli lähettäjältä lähettäjän julkisella avaimella.

Kuinka pääsemme käsiksi salasanoihin?

Päästääksemme salasanoihin meidän on ensin luotava ja tallennettava ne jonnekin. Osa näistä toiminnoista voidaan varustaa autentikaattorilla. An authenticator on mikä tahansa laitteisto- tai ohjelmistotuettu laite, joka mahdollistaa salausavainten luomisen. Ajattele niitä kertaluonteisia salasanoja, joista saat Google Authenticator, 1Passwordtai LastPass, Mm.

Esimerkiksi ohjelmistotodentaja voi käyttää Trusted Platform Module (TPM) -moduulia tai laitteen suojattua enklaavia valtuustietojen luomiseen. Tunnukset voidaan sitten tallentaa etänä ja synkronoida laitteiden välillä, esim. salasanat. Laitteiston todentaja olisi jotain a YubiKey, joka voi luoda ja tallentaa avaimia itse laitteeseen.

Autentikaattoriin pääsyä varten selaimella on oltava pääsy laitteistoon, ja sitä varten tarvitsemme käyttöliittymän. Tässä käyttämämme käyttöliittymä on Client to Authenticator Protocol (CTAP). Se mahdollistaa pääsyn erilaisiin todentajiin eri mekanismien kautta. Voimme esimerkiksi käyttää autentikaattoria NFC:n, USB:n ja Bluetoothin kautta käyttämällä CTAP:tä.

Yksi mielenkiintoisimmista tavoista käyttää salasanoja on yhdistää puhelimesi Bluetoothin kautta toiseen laitteeseen, joka ei ehkä tue salasanoja. Kun laitteet on paritettu Bluetoothin kautta, voin kirjautua sisään tietokoneeni selaimeen käyttämällä puhelintani välittäjänä!

Ero salasanan ja WebAuthnin välillä

Salasanat ja WebAuthn-avaimet eroavat monin tavoin. Ensinnäkin pääsyavaimia pidetään usean laitteen valtuustiedoina, ja ne voidaan synkronoida eri laitteiden välillä. Sitä vastoin WebAuthn-avaimet ovat yhden laitteen tunnistetietoja – hieno tapa sanoa, että olet sidottu yhteen laitteeseen vahvistusta varten.

Toiseksi WebAuthn-avainten on tarjottava käyttäjän kahva sisäänkirjautumista varten, jotta ne voidaan todentaa palvelimelle, minkä jälkeen allowCredentials Lista palautetaan asiakkaalle palvelimelta, joka kertoo millä tunnistetiedoilla voidaan kirjautua sisään. Salasanat ohittavat tämän vaiheen ja käyttävät palvelimen verkkotunnusta osoittamaan, mitkä avaimet on jo sidottu kyseiseen sivustoon. Voit valita salasanan, joka liittyy kyseiseen palvelimeen, koska järjestelmäsi jo tietää sen.

Muuten avaimet ovat kryptografisesti samat; ne eroavat vain siinä, miten ne on tallennettu ja mitä tietoja ne käyttävät kirjautumisprosessin aloittamiseen.

Prosessi… pähkinänkuoressa

Prosessi WebAuthnin tai salasanan luomiseen on hyvin samanlainen: hanki haaste palvelimelta ja käytä sitten navigator.credentials.create web API julkisen avainparin luomiseksi. Lähetä sitten haaste ja julkinen avain takaisin palvelimelle tallennettavaksi.

Vastaanotettuaan julkisen avaimen ja haasteen palvelin vahvistaa haasteen ja istunnon, josta se luotiin. Jos tämä kirjautuu ulos, julkinen avain sekä kaikki muut asiaankuuluvat tiedot, kuten käyttäjätunnus tai todistustiedot, tallennetaan tietokantaan.

Käyttäjällä on vielä yksi vaihe — hae toinen haaste palvelimelta ja käytä navigator.credentials.get API allekirjoittaa haaste. Lähetämme allekirjoitetun haasteen takaisin palvelimelle, ja palvelin vahvistaa haasteen ja kirjaa meidät sisään, jos allekirjoitus menee läpi.

Jokaisessa vaiheessa on tietysti vähän enemmän. Mutta yleensä näin kirjautuisimme verkkosivustolle käyttämällä WebAuthnia tai salasanoja.

Liha ja perunat

Tunnuslukuja käytetään kahdessa eri vaiheessa: todistaminen ja väite vaiheet.

Todistusvaihetta voidaan pitää myös rekisteröintivaiheena. Kirjautuisit sähköpostilla ja salasanalla uudelle verkkosivustolle, mutta tässä tapauksessa käyttäisimme salasanaamme.

Vahvistusvaihe on samanlainen kuin kuinka kirjautuisit verkkosivustolle rekisteröitymisen jälkeen.

todistaminen

Passkeys: Mitä ihmettä ja miksi? PlatoBlockchain Data Intelligence. Pystysuuntainen haku. Ai. — Näytä täysikokoinen

- navigator.credentials.create API on todistusvaiheemme painopiste. Olemme rekisteröityneet uudeksi käyttäjäksi järjestelmään ja meidän on luotava uusi julkinen avainpari. Meidän on kuitenkin määritettävä, millaisen avainparin haluamme luoda. Tämä tarkoittaa, että meidän on tarjottava vaihtoehtoja navigator.credentials.create.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialCreationOptions = { challenge: safeEncode(challenge), rp: { id: window.location.host, name: document.title, }, user: { id: new TextEncoder().encode(crypto.randomUUID()), // Why not make it random? name: 'Your username', displayName: 'Display name in browser', }, pubKeyCredParams: [ { type: 'public-key', alg: -7, // ES256 }, { type: 'public-key', alg: -256, // RS256 }, ], authenticatorSelection: { userVerification: 'preferred', // Do you want to use biometrics or a pin? residentKey: 'required', // Create a resident key e.g. passkey }, attestation: 'indirect', // indirect, direct, or none timeout: 60_000,
};

const pubKeyCredential: PublicKeyCredential = await navigator.credentials.create({ publicKey
});
const { id // the key id a.k.a. kid
} = pubKeyCredential;
const pubKey = pubKeyCredential.response.getPublicKey();
const { clientDataJSON, attestationObject } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for registration

Saamme PublicKeyCredential joka sisältää an AuthenticatorAttestationResponse joka tulee takaisin luomisen jälkeen. Tunnisteella on luodun avainparin tunnus.

Vastaus tarjoaa pari bittiä hyödyllistä tietoa. Ensinnäkin meillä on julkinen avaimemme tässä vastauksessa, ja meidän on lähetettävä se palvelimelle tallennettavaksi. Toiseksi saamme myös takaisin clientDataJSON ominaisuuden, jonka voimme purkaa ja sieltä saada takaisin type, challengeja origin salasanasta.

Todennusta varten haluamme vahvistaa type, challengeja origin palvelimelle, sekä tallentaa julkisen avaimen tunnisteineen, esim. kid. Voimme myös halutessasi säilyttää attestationObject jos haluamme. Toinen hyödyllinen varastointiominaisuus on COSE algoritmi, joka on määritelty yllä meidän PublicKeyCredentialCreationOptions with alg: -7 or alg: -256, jotta allekirjoitetut haasteet voidaan helposti todentaa vahvistusvaiheessa.

Väite

- navigator.credentials.get API on väitevaiheen painopiste. Käsitteellisesti tämä olisi paikka, jossa käyttäjä kirjautuu sisään verkkosovellukseen rekisteröitymisen jälkeen.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialRequestOptions = { challenge: new TextEncoder().encode(challenge), rpId: window.location.host, timeout: 60_000,
};

const publicKeyCredential: PublicKeyCredential = await navigator.credentials.get({ publicKey, mediation: 'optional',
});
const { id // the key id, aka kid
} = pubKeyCredential;
const { clientDataJSON, attestationObject, signature, userHandle } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for verification

Saamme jälleen a PublicKeyCredential kanssa AuthenticatorAssertionResponse tällä kertaa. Tunniste sisältää jälleen avaimen tunnisteen.

Saamme myös type, challengeja origin mistä clientDataJSON uudelleen. signature on nyt mukana vastauksessa, samoin kuin authenticatorData. Tarvitsemme niitä ja clientDataJSON varmistaaksesi, että tämä on allekirjoitettu yksityisellä avaimella.

- authenticatorData sisältää joitain ominaisuuksia, joita kannattaa seurata Ensinnäkin on käyttämäsi alkuperän SHA256-hajautusarvo, joka sijaitsee ensimmäisten 32 tavun sisällä, mikä on hyödyllistä sen varmistamiseksi, että pyyntö tulee samalta alkuperäpalvelimelta. Toinen on signCount, joka on tavuista 33–37. Tämä luodaan autentikaattorista ja sitä tulisi verrata sen aikaisempaan arvoon, jotta avaimella ei tapahdu mitään hämärää. Arvon tulee aina olla 0, kun se on usean laitteen salasana, ja sen tulee olla satunnaisesti suurempi kuin edellinen signCount, kun se on yhden laitteen salasana.

Kun olet vahvistanut kirjautumistunnuksesi, sinun tulee kirjautua sisään - onnea! Passkeys on melko hieno protokolla, mutta siinä on joitain varoituksia.

Joitakin huonoja puolia

Passkeysissa on paljon hyviä puolia, mutta sen kanssa on joitain ongelmia tätä kirjoitettaessa. Ensinnäkin salasanat ovat vielä jonkin verran varhaisia tuen kannalta, vain yhden laitteen tunnistetiedot ovat sallittuja Windowsissa ja hyvin vähän tukea Linux-järjestelmille. Passkeys.dev tarjoaa a hieno pöytä, joka on tavallaan kuin tämän protokollan Caniuse.

Googlen ja Applen salasana-alustat eivät myöskään kommunikoi keskenään. Jos haluat saada kirjautumistietosi Android-puhelimesta iPhoneen… no, et ole toistaiseksi onneton. Tämä ei tarkoita, etteikö yhteentoimivuutta olisi! Voit kirjautua sisään tietokoneellesi käyttämällä puhelintasi todentajana. Mutta olisi paljon puhtaampaa, jos se olisi sisäänrakennettu käyttöjärjestelmään ja synkronoitu ilman, että se lukittaisiin toimittajatasolla.

Mihin asiat ovat menossa?

Miltä tulevaisuuden salasanaprotokolla näyttää? Näyttää aika hyvältä! Kun se saa tukea useammista käyttöjärjestelmistä, sen käytön pitäisi lisääntyä, ja alat nähdä sen olevan yhä enemmän käytössä luonnossa. Jonkin verran salasanan hallinta aikovat jopa tukea heitä omakohtaisesti.

Tunnuslukuja ei tueta missään nimessä vain verkossa. Android ja iOS molemmat tukevat alkuperäisiä salasanoja ensiluokkaisina kansalaisina. Olemme vielä tämän kaiken alkuaikoina, mutta odotamme, että se mainitaan yhä useammin.

Loppujen lopuksi poistamme salasanojen tarpeen ja teemme näin maailmasta turvallisemman!