Pääsmed: mis kuradit ja miks?

Need asjad kutsusid pääsukoodid kindlasti teevad nendel päevadel tiiru. Need olid peamiseks vaatamisväärsuseks W3C TPAC 2022aastal sai toetust Safari 16, leiavad tee macOS ja iOS, ja on kavas olla paroolihaldurite nagu 1Password tulevik. Nemad on juba toetatud Androidis ning leiavad peagi tee Chrome OS-i ja Windowsi tulevastes versioonides.

Geeky OS-i turvatäiustused ei too esiotsa kogukonnas just suuri pealkirju, kuid on loogiline, et pääsuvõtmed saavad olema "asi". Arvestades, kuidas paroolid ja paroolirakendused mõjutavad selliste asjade kasutuskogemust nagu autentimine ja vormide töötlemine, võiksime vähemalt nende ümber mõelda, et teaksime, mis tulemas on.

See on selle artikli mõte. Olen juba mõnda aega uurinud ja katsetanud pääsuvõtmeid – ja WebAuthni API-d, millele need on üles ehitatud. Lubage mul jagada, mida ma õppisin.

Sisukord

Terminoloogia

Siin on kohustuslik osa terminoloogiast, mida tahate teada, kui me süveneme. Nagu enamik tehnikaid, on paroolid koostatud esoteerilise sõnasõna ja akronüümidega, mis on sageli arusaamist takistavad. Püüan siin mitmed teie jaoks müstifitseerida.

• Tugineja: server, mille vastu autentida. Kasutame "serverit", et viidata selles artiklis sõltuvale osapoolele.
• Klient: meie puhul veebibrauser või operatsioonisüsteem.
• Autentija: Tarkvara- ja/või riistvaraseadmed, mis võimaldavad genereerida ja salvestada avalikke võtmepaare.
• FIDO: avatud standardite asutus, mis loob ka FIDO mandaatide kohta spetsifikatsioone.
• WebAuthn: pääsukoodide aluseks olev protokoll, tuntud ka kui a FIDO2 mandaat või ühe seadme FIDO mandaat.
• paroolid: WebAuthn, kuid pilvesünkroonimisega (nimetatakse ka mitme seadme FIDO mandaatideks, leitavateks mandaatideks või residentide mandaatideks).
• Avaliku võtme krüptograafia: Loodud võtmepaar, mis sisaldab privaatset ja avalikku võtit. Olenevalt algoritmist tuleks seda kasutada kas allkirjastamiseks ja kinnitamiseks või krüptimiseks ja dekrüpteerimiseks. Seda tuntakse ka kui asümmeetriline krüptograafia.
• RSA: Loojate nimede akronüüm Rivest Shamir ja Adel. RSA on vanem, kuid siiski kasulik avaliku võtme krüptograafia perekond, mis põhineb faktooringu algarvudel.
• Elliptilise kõvera krüptograafia (ECC): Krüptograafia uuem perekond elliptiliste kõverate põhjal.
• ES256: Elliptilise kõvera avalik võti, mis kasutab ECDSA allkirjastamisalgoritmi (pDF) koos SHA256 räsimiseks.
• RS256: Nagu ES256, kuid see kasutab RSA-d RASSSA-PKCS1-v1.5 ja SHA256.

Mis on pääsukoodid?

Enne kui saame konkreetselt pääsuvõtmetest rääkida, peame rääkima teisest protokollist, mida nimetatakse WebAuthn (tuntud ka kui FIDO2). Pääsmed on spetsifikatsioon, mis on üles ehitatud WebAuthni peale. WebAuthn võimaldab avaliku võtmega krüptograafiat paroolide asendamiseks. Kasutame mingit turvaseadet, näiteks riistvaravõtit või Usaldusväärse platvormi mooduli (TPM) privaatsete ja avalike võtmete loomiseks.

Avalik võti on kõigile kasutamiseks. Privaatvõtit ei saa aga selle genereerinud seadmest eemaldada. See oli üks WebAuthni probleeme; kui kaotate seadme, kaotate juurdepääsu.

Passkeys lahendab selle, pakkudes teie mandaatide pilvesünkroonimist. Teisisõnu, seda, mida oma arvutis loote, saab nüüd kasutada ka teie telefonis (kuigi segadusttekitavalt on olemas ka ühe seadme mandaat).

Praegu, kirjutamise ajal, pakuvad pilvesünkroonitud pääsuvõtmete täielikku tuge ainult iOS, macOS ja Android ning isegi siis piirab neid kasutatav brauser. Google ja Apple pakuvad oma kaudu sünkroonimiseks liidest Google'i paroolihaldur ja Apple iCloudi võtmehoidja vastavalt teenuseid.

Kuidas paroolid asendavad paroole?

Avaliku võtme krüptograafias saate teha nn allkirjastamine. Allkirjastamine võtab osa andmeid ja seejärel käivitab selle privaatvõtmega allkirjastamisalgoritmi kaudu, kus seda saab seejärel avaliku võtmega kontrollida.

Igaüks võib luua avaliku võtmepaari ja see ei ole ühelegi isikule omistatav, kuna iga inimene oleks võinud selle luua. Kasulikuks teeb selle see, et avaliku võtmega saab kontrollida ainult privaatvõtmega allkirjastatud andmeid. See on osa, mis asendab parooli – server salvestab avaliku võtme ja me logime sisse, kontrollides, et meil on teine ​​pool (nt privaatvõti), allkirjastades juhusliku väljakutse.

Kuna me salvestame kasutajate avalikud võtmed andmebaasi, ei pea enam muretsema miljoneid kasutajaid mõjutavate paroolirikkumiste pärast. See vähendab andmepüüki, rikkumisi ja paljusid muid turvaprobleeme, millega meie paroolist sõltuv maailm praegu silmitsi seisab. Kui andmebaasi rikutakse, salvestatakse see kõik kasutaja avalikesse võtmetesse, muutes selle ründajale praktiliselt kasutuks.

Samuti pole enam unustatud e-kirju ja nendega seotud paroole! Brauser jätab meelde, milliseid mandaate millise veebisaidi jaoks kasutasite – piisab, kui teha paar klõpsu ja olete sisse logitud. Saate pääsuvõtme kasutamiseks pakkuda teise kinnitusviisi, näiteks biomeetria või PIN-koodi , kuid need on siiski palju kiiremad kui eelmise aasta paroolid.

Veel krüptograafiast

Avaliku võtme krüptograafia hõlmab privaatse ja avaliku võtme (tuntud võtmepaarina) omamist. Võtmed genereeritakse koos ja neil on eraldi kasutusala. Näiteks privaatvõti on mõeldud hoidmiseks salajas ja avalik võti on mõeldud kõigile, kellega soovite sõnumeid vahetada.

Sõnumi krüptimisel ja dekrüpteerimisel kasutatakse sõnumi krüptimiseks saaja avalikku võtit, nii et sõnumit saab dekrüpteerida ainult saaja privaatvõti. Turvakeeles nimetatakse seda "konfidentsiaalsuse pakkumiseks". See aga ei tõenda, et saatja on see, kes ta end olevat, sest igaüks võib potentsiaalselt kasutada avalikku võtit kellelegi krüptitud sõnumi saatmiseks.

On juhtumeid, kus peame kontrollima, kas sõnum tuli tõepoolest saatjalt. Sellistel juhtudel kasutame allkirjastamist ja allkirja kinnitamist tagamaks, et saatja on see, kes ta end olevat (tuntud ka kui autentsus). Avalikus võtmes (nimetatakse ka asümmeetriline) krüptograafia, tehakse seda üldjuhul sõnumi räsi allkirjastamisega, nii et ainult avalik võti saab seda õigesti kontrollida. Räsi ja saatja privaatvõti annavad pärast selle algoritmi läbimist allkirja ja seejärel saab igaüks kontrollida, kas sõnum tuli saatja avaliku võtmega.

Kuidas pääseme ligi pääsuvõtmetele?

Pääsuvõtmetele juurdepääsuks peame need esmalt genereerima ja kuhugi salvestama. Osa sellest funktsioonist saab varustada autentijaga. An autentija on mis tahes riist- või tarkvaratoega seade, mis võimaldab krüptograafilise võtme genereerimist. Mõelge nendele ühekordsetele paroolidele, millest saate Google Authenticator, 1Passwordvõi LastPass, Teiste hulgas.

Näiteks võib tarkvara autentija kasutada mandaatide loomiseks usaldusväärse platvormi moodulit (TPM) või seadme turvalist enklaavi. Mandaate saab seejärel eemalt salvestada ja seadmete vahel sünkroonida, nt pääsuvõtmed. Riistvara autentija oleks midagi sellist YubiKey, mis suudab võtmeid seadmes endas genereerida ja talletada.

Autentijale juurdepääsuks peab brauser saama juurdepääsu riistvarale ja selleks vajame liidest. Siin kasutatav liides on Client to Authenticator Protocol (CTAP). See võimaldab juurdepääsu erinevatele autentijatele erinevate mehhanismide kaudu. Näiteks pääseme autentijale juurde NFC, USB ja Bluetoothi ​​kaudu, kasutades CTAP-i.

Üks huvitavamaid viise paroolide kasutamiseks on telefoni ühendamine Bluetoothi ​​kaudu teise seadmega, mis ei pruugi paroolisid toetada. Kui seadmed on Bluetoothiga seotud, saan oma arvutis brauserisse sisse logida, kasutades vahendajana oma telefoni!

Pääsmete ja WebAuthni erinevus

Pääsmed ja WebAuthni võtmed erinevad mitmel viisil. Esiteks peetakse pääsuvõtmeid mitme seadme mandaadiks ja neid saab seadmete vahel sünkroonida. Seevastu WebAuthni võtmed on ühe seadme mandaadid – väljamõeldud viis öelda, et olete kinnitamiseks seotud ühe seadmega.

Teiseks peavad WebAuthni võtmed serveris autentimiseks pakkuma kasutajakäepidet sisselogimiseks, misjärel allowCredentials serverist tagastatakse kliendile nimekiri, mis annab teada, milliseid mandaate saab sisselogimiseks kasutada. Pääsmed jätavad selle sammu vahele ja kasutavad serveri domeeninime, et näidata, millised võtmed on selle saidiga juba seotud. Saate valida selle serveriga seotud pääsukoodi, kuna see on teie süsteemile juba teada.

Vastasel juhul on võtmed krüptograafiliselt samad; need erinevad ainult selle poolest, kuidas neid salvestatakse ja millist teavet nad sisselogimisprotsessi alustamiseks kasutavad.

Protsess… lühidalt

WebAuthni või pääsukoodi genereerimise protsess on väga sarnane: hankige serverilt väljakutse ja kasutage seejärel navigator.credentials.create veebi API avaliku võtmepaari loomiseks. Seejärel saatke väljakutse ja avalik võti salvestamiseks serverisse tagasi.

Avaliku võtme ja väljakutse saamisel kinnitab server väljakutse ja seansi, millest see loodi. Kui see õnnestub, salvestatakse andmebaasi avalik võti ja muu asjakohane teave, näiteks kasutaja identifikaator või kinnitusandmed.

Kasutajal on veel üks samm – hankige serverist uus väljakutse ja kasutage seda navigator.credentials.get API väljakutse allkirjastamiseks. Saadame allkirjastatud väljakutse serverisse tagasi ja server kontrollib väljakutset ja logib meid siis sisse, kui allkiri läbib.

Muidugi on igal sammul palju rohkem. Kuid üldiselt logiksime WebAuthni või paroolide abil veebisaidile sisse nii.

Liha ja kartul

Pääsukoode kasutatakse kahes erinevas faasis: atesteerimine ja väide faasid.

Atesteerimisfaasi võib pidada ka registreerimisfaasiks. Registreeruksite uue veebisaidi jaoks e-posti aadressi ja parooliga, kuid sel juhul kasutaksime oma pääsuvõtit.

Kinnitamise faas on sarnane sellele, kuidas logite pärast registreerumist veebisaidile sisse.

Tõendamine

. navigator.credentials.create API on meie atesteerimisfaasi keskmes. Oleme süsteemis registreeritud uue kasutajana ja peame looma uue avaliku võtmepaari. Siiski peame täpsustama, millist võtmepaari tahame genereerida. See tähendab, et me peame pakkuma võimalusi 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

Me saame PublicKeyCredential mis sisaldab an AuthenticatorAttestationResponse mis tuleb pärast loomist tagasi. Mandaadil on loodud võtmepaari ID.

Vastus sisaldab paar kasulikku teavet. Esiteks on meil selles vastuses oma avalik võti ja me peame saatma selle salvestamiseks serverisse. Teiseks saame ka tagasi clientDataJSON vara, mille saame dekodeerida ja sealt tagasi saada type, challengeja origin pääsukoodist.

Atesteerimiseks tahame kinnitada type, challengeja origin serveris, samuti salvestada avalik võti koos selle identifikaatoriga, nt kid. Soovi korral saame ka hoiustada attestationObject kui soovime. Veel üks kasulik vara hoidmiseks on COSE algoritm, mis on meie ülalpool määratletud  PublicKeyCredentialCreationOptions koos alg: -7 or alg: -256, et hõlpsasti kontrollida kõiki allkirjastatud väljakutseid kinnitusfaasis.

Väide

. navigator.credentials.get API on kinnitusfaasi keskmes. Põhimõtteliselt oleks see koht, kus kasutaja logib pärast registreerumist veebirakendusse sisse.

// 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

Saame jälle a PublicKeyCredential koos AuthenticatorAssertionResponse seekord. Mandaat sisaldab taas võtme identifikaatorit.

Samuti saame type, challengeja origin alates clientDataJSON uuesti. The signature on nüüd vastuses, samuti authenticatorData. Me vajame neid ja clientDataJSON et kontrollida, kas see on privaatvõtmega allkirjastatud.

. authenticatorData sisaldab mõningaid jälgimist väärt atribuute. Esiteks on teie kasutatava lähtekoha SHA256 räsi, mis asub esimese 32 baidi piires, mis on kasulik kontrollimaks, et päring pärineb samast lähteserverist. Teiseks on signCount, mis on baitidest 33 kuni 37. Selle genereerib autentija ja seda tuleks võrrelda selle eelmise väärtusega tagamaks, et võtmega ei juhtu midagi kahtlast. Väärtus peaks alati olema 0, kui see on mitme seadme pääsuvõti, ja juhuslikult suurem kui eelmine signCount, kui see on ühe seadme pääsuvõti.

Kui olete oma sisselogimise kinnitanud, peaksite olema sisse logitud — Palju õnne! Passkeys on päris suurepärane protokoll, kuid sellega kaasnevad mõned hoiatused.

Mõned miinused

Passkeysil on palju positiivseid külgi, kuid selle kirjutamise ajal on sellega probleeme. Esiteks on pääsukoodid veel mõnevõrra varajased, Windowsis on lubatud ainult ühe seadme mandaat ja Linuxi süsteemide tugi on väga väike. Passkeys.dev annab kena tabel, mis on umbes nagu selle protokolli Caniuse.

Samuti ei suhtle Google'i ja Apple'i pääsukoodide platvormid omavahel. Kui soovite oma Android-telefoni mandaadid iPhone'i üle kanda, siis pole teil praegu õnne. See ei tähenda, et koostalitlusvõimet poleks! Saate oma arvutisse sisse logida, kasutades oma telefoni autentijana. Kuid oleks palju puhtam, kui see oleks operatsioonisüsteemi sisse ehitatud ja sünkroonitud, ilma et see oleks müüja tasemel lukustatud.

Kuhu asjad liiguvad?

Kuidas näeb välja tuleviku pääsukoodide protokoll? See näeb päris hea välja! Kui see saab rohkemate operatsioonisüsteemide tuge, peaks selle kasutamine suurenema ja hakkate nägema, et seda kasutatakse looduses üha enam. Mõned paroolihaldurid kavatsevad neid isegi vahetult toetada.

Pääsukoode ei toetata mingil juhul ainult veebis. Android ja iOS mõlemad toetavad esmaklassiliste kodanikena kohalikke pääsukoode. Oleme selle kõigega alles algusaegadel, kuid loodame, et seda mainitakse üha enam.

Me kaotame ju vajaduse paroolide järele ja muudame seda tehes maailma selle jaoks turvalisemaks!

Vahendid

Siin on veel mõned ressursid, kui soovite pääsukoodide kohta lisateavet. Samuti on selle artikli jaoks kokku pandud hoidla ja demo.

• SEO-põhise sisu ja PR-levi. Võimenduge juba täna.
• Platoblockchain. Web3 metaversiooni intelligentsus. Täiustatud teadmised. Juurdepääs siia.
• Allikas: https://css-tricks.com/passkeys-what-the-heck-and-why/