Passkeys: Mi a fene és miért?

Újra kiadta Platón

Követő: 0

Ezeket a dolgokat hívják belépőkulcsok biztos, hogy körbejárnak ezekben a napokban. Fő attrakciót jelentettek itt W3C TPAC 2022ben nyert támogatást Safari 16, megtalálják az utat macOS és iOS, és a tervek szerint lesz az olyan jelszókezelők jövője, mint az 1Password. Ők már támogatott Androidon, és hamarosan megtalálják az utat a Chrome OS és a Windows jövőbeni kiadásaiban.

A geeky operációs rendszer biztonsági fejlesztései nem kapnak nagy címlapokat a front-end közösségben, de magától értetődik, hogy a hozzáférési kulcsok „dolog” lesz. És ha figyelembe vesszük, hogy a jelszavak és a jelszóalkalmazások hogyan befolyásolják a felhasználói élményt, például a hitelesítést és az űrlapfeldolgozást, érdemes lenne legalább ezekre gondolnunk, hogy tudjuk, mi következik.

Ez a cikk lényege. Már egy ideje tanulmányozom és kísérleteztem a jelszókkal – és a WebAuthn API-val, amelyre ezek épülnek. Hadd osszam meg, mit tanultam.

Tartalomjegyzék

Terminológia

Íme a terminológia kötelező része, amelyet tudni fogsz, amikor belemélyedünk. A legtöbb technológiához hasonlóan a jelszót ezoterikus szavakkal és betűszavakkal dolgozzák ki, amelyek gyakran akadályozzák a megértést. Megpróbálok itt néhányat eloszlatni.

Támaszkodó fél: a szerver, amelyen hitelesíteni fog. Ebben a cikkben a „szerver” kifejezést használjuk az Égő fél megjelölésére.
Ügyfél: esetünkben a webböngésző vagy operációs rendszer.
Hitelesítő: Szoftver- és/vagy hardvereszközök, amelyek lehetővé teszik nyilvános kulcspárok generálását és tárolását.
FIDO: Nyílt szabványok testülete, amely a FIDO hitelesítő adataival kapcsolatos specifikációkat is létrehoz.
WebAuthn: A kulcsok mögöttes protokollja, más néven a FIDO2 hitelesítő adatok vagy egy eszköz FIDO hitelesítő adatok.
azonosítók: WebAuthn, de felhőszinkronizálással (többeszközös FIDO hitelesítési adatoknak, felfedezhető hitelesítési adatoknak vagy rezidens hitelesítési adatoknak is nevezik).
Nyilvános kulcsú kriptográfia: Létrehozott kulcspár, amely magán és nyilvános kulcsot tartalmaz. Az algoritmustól függően vagy aláírásra és ellenőrzésre, vagy titkosításra és visszafejtésre kell használni. Ez más néven is ismert aszimmetrikus kriptográfia.
RSA: Az alkotók nevének rövidítése, Rivest Shamir és Adel. Az RSA egy régebbi, de még mindig hasznos, faktoring prímszámokon alapuló nyilvános kulcsú kriptográfiai család.
Elliptikus görbe kriptográfia (ECC): A kriptográfia egy újabb családja elliptikus görbék alapján.
ES256: Egy elliptikus görbe nyilvános kulcs, amely ECDSA aláíró algoritmust használ (PDF) A SHA256 a kivonatoláshoz.
256: Mint az ES256, de RSA-t használ vele RASSSA-PKCS1-v1.5 és SHA256.

Mik azok a jelszók?

Mielőtt konkrétan a hozzáférési kulcsokról beszélhetnénk, beszélnünk kell egy másik protokollról WebAuthn (más néven FIDO2). A jelszó egy olyan specifikáció, amely a WebAuthn tetejére épül. A WebAuthn lehetővé teszi a nyilvános kulcsú titkosítást a jelszavak helyettesítésére. Használunk valamilyen biztonsági eszközt, például hardverkulcsot ill Trusted Platform Module (TPM), privát és nyilvános kulcsok létrehozásához.

A nyilvános kulcsot bárki használhatja. A privát kulcs azonban nem távolítható el az azt létrehozó eszközről. Ez volt a WebAuthn egyik problémája; ha elveszíti az eszközt, elveszíti a hozzáférést.

A Passkeys ezt úgy oldja meg, hogy felhőalapú szinkronizálást biztosít a hitelesítő adatokhoz. Más szóval, amit a számítógépén generál, az mostantól a telefonján is használható (bár megtévesztő, hogy léteznek egyetlen eszköz hitelesítő adatai is).

Jelenleg a cikk írásakor csak az iOS, a macOS és az Android támogatja a felhőben szinkronizált jelszavakat, és még akkor is korlátozza őket a használt böngésző. A Google és az Apple felületet biztosít a sajátjukon keresztüli szinkronizáláshoz Google Jelszókezelő és a Apple iCloud kulcstartó szolgáltatások, ill.

Hogyan helyettesítik a jelszavak a jelszavakat?

A nyilvános kulcsú kriptográfiában végrehajthatja az ún aláírás. Az aláírás egy adatot vesz fel, majd egy aláírási algoritmuson keresztül futtatja a privát kulccsal, ahol azután a nyilvános kulccsal ellenőrizhető.

Bárki létrehozhat nyilvános kulcspárt, és ez nem tulajdonítható senkinek, mivel bárki létrehozhatta azt először. Ami hasznossá teszi, az az, hogy csak a privát kulccsal aláírt adatok ellenőrizhetők nyilvános kulccsal. Ez az a rész, amely a jelszót helyettesíti – a szerver tárolja a nyilvános kulcsot, mi pedig úgy jelentkezünk be, hogy ellenőrizzük, hogy megvan-e a másik fele (pl. privát kulcs), egy véletlenszerű kihívás aláírásával.

További előny, hogy mivel a felhasználók nyilvános kulcsait egy adatbázisban tároljuk, többé nem kell aggódni a több millió felhasználót érintő jelszósértés miatt. Ez csökkenti az adathalászatot, a jogsértéseket és számos egyéb biztonsági problémát, amelyekkel jelszófüggő világunk jelenleg szembesül. Ha egy adatbázist feltörnek, akkor mindez a felhasználó nyilvános kulcsaiban tárolódik, ami gyakorlatilag használhatatlanná teszi a támadó számára.

Nincs több elfelejtett e-mail és a hozzájuk tartozó jelszavak sem! A böngésző megjegyzi, hogy melyik webhelyhez milyen hitelesítési adatokat használt – mindössze néhány kattintást kell tennie, és már bejelentkezik. A jelszó használatához megadhat másodlagos igazolási módot is, például biometrikus adatokat vagy PIN kódot. , de ezek még mindig sokkal gyorsabbak, mint a múltkori jelszavak.

Bővebben a kriptográfiáról

A nyilvános kulcsú kriptográfia magában foglalja egy privát és egy nyilvános kulcs (kulcspárként ismert) használatát. A kulcsok együtt jönnek létre, és külön-külön használhatók. Például a privát kulcsot titokban kell tartani, a nyilvános kulcsot pedig mindenkinek, akivel üzenetet kíván váltani.

Amikor egy üzenet titkosításáról és visszafejtéséről van szó, a címzett nyilvános kulcsát használják az üzenet titkosításához, így csak a címzett privát kulcsa tudja visszafejteni az üzenetet. Biztonsági nyelven ezt „titoktartás biztosítása”-nak nevezik. Ez azonban nem bizonyítja, hogy a feladó az, akinek mondják magukat, mivel bárki használhat nyilvános kulcsot titkosított üzenet küldésére.

Vannak esetek, amikor ellenőriznünk kell, hogy az üzenet valóban a feladótól érkezett-e. Ezekben az esetekben aláírást és aláírás-ellenőrzést alkalmazunk annak biztosítására, hogy a feladó az legyen, akinek mondják magukat (más néven hitelesség). Nyilvános kulcsban (más néven aszimmetrikus) kriptográfia, ez általában az üzenet hash-jének aláírásával történik, így csak a nyilvános kulcs tudja helyesen ellenőrizni azt. A hash és a küldő privát kulcsa egy algoritmuson való futtatás után aláírást hoz létre, majd bárki ellenőrizheti, hogy a feladó nyilvános kulcsával érkezett-e az üzenet.

Hogyan juthatunk hozzá a jelszóhoz?

A jelszó eléréséhez először létre kell hoznunk és valahol tárolnunk kell őket. E funkciók egy része hitelesítővel is ellátható. An hitelesítő bármely hardver vagy szoftver által támogatott eszköz, amely lehetővé teszi a kriptográfiai kulcsok létrehozását. Gondoljon azokra az egyszeri jelszavakra, amelyektől kap A Google Hitelesítő, 1Passwordvagy LastPass, Többek között.

Például egy szoftverhitelesítő használhatja a Trusted Platform Module-t (TPM) vagy egy eszköz biztonságos enklávéját a hitelesítő adatok létrehozásához. A hitelesítő adatok ezután távolról tárolhatók, és szinkronizálhatók az eszközök között, például jelszavakkal. A hardveres hitelesítő olyasmi, mint a YubiKey, amely magán az eszközön tud kulcsokat generálni és tárolni.

A hitelesítő eléréséhez a böngészőnek hozzá kell férnie a hardverhez, ehhez pedig interfészre van szükségünk. Az itt használt felület a Client to Authenticator Protocol (CTAP). Lehetővé teszi a különböző hitelesítőkhöz való hozzáférést különböző mechanizmusokon keresztül. Például CTAP használatával hozzáférhetünk egy hitelesítőhöz NFC-n, USB-n és Bluetooth-on keresztül.

A jelszavak használatának egyik érdekesebb módja az, ha telefonját Bluetooth-on keresztül csatlakoztatja egy másik eszközhöz, amely esetleg nem támogatja a jelszót. Ha Bluetooth-on párosítják az eszközöket, a telefonom közvetítésével tudok bejelentkezni a számítógépem böngészőjébe!

A jelszó és a WebAuthn közötti különbség

A jelszavak és a WebAuthn kulcsok több szempontból is különböznek egymástól. Először is, a jelszót több eszköz hitelesítő adatainak tekintik, és szinkronizálhatók az eszközök között. Ezzel szemben a WebAuthn kulcsok egyetlen eszköz hitelesítő adatai – ez egy divatos módja annak, hogy elmondhassuk, egyetlen eszközhöz van kötve az ellenőrzés.

Másodszor, a kiszolgálón való hitelesítéshez a WebAuthn kulcsoknak biztosítaniuk kell a felhasználói kezelőt a bejelentkezéshez, majd allowCredentials listát küld vissza a kliens a szerverről, amely tájékoztat arról, hogy milyen hitelesítő adatokkal lehet bejelentkezni. A jelszavak kihagyják ezt a lépést, és a kiszolgáló tartománynevét használják annak kimutatására, hogy mely kulcsok már hozzá vannak kötve az adott webhelyhez. Kiválaszthatja a kiszolgálóhoz társított jelszót, mivel azt a rendszere már ismeri.

Egyébként a kulcsok kriptográfiailag azonosak; csak abban különböznek, hogyan tárolják őket, és milyen információkat használnak a bejelentkezési folyamat elindításához.

A folyamat… dióhéjban

A WebAuthn vagy a jelszó létrehozásának folyamata nagyon hasonló: kérjen kihívást a szervertől, majd használja a navigator.credentials.create web API nyilvános kulcspár létrehozásához. Ezután küldje vissza a kihívást és a nyilvános kulcsot a szerverre, hogy tárolja.

A nyilvános kulcs és a kihívás kézhezvételekor a szerver érvényesíti a kihívást és a munkamenetet, amelyből létrehozták. Ha ez megtörténik, a nyilvános kulcs, valamint minden egyéb releváns információ, például a felhasználói azonosító vagy a tanúsítási adatok tárolásra kerül az adatbázisban.

A felhasználónak van még egy lépése – kérjen le egy másik kihívást a szerverről, és használja a navigator.credentials.get API-t a kihívás aláírásához. Az aláírt kihívást visszaküldjük a szervernek, és a szerver ellenőrzi a kihívást, majd bejelentkezik, ha az aláírás sikeres.

Természetesen minden lépéshez jóval több tartozik. De általában így kell bejelentkeznünk egy webhelyre WebAuthn vagy jelszó használatával.

A hús és a burgonya

A hozzáférési kulcsokat két különböző fázisban használják: a hitelesítés és a kijelentés fázisban.

Az igazolási szakasz a regisztrációs szakasznak is felfogható. E-mail-címmel és jelszóval kell regisztrálnia egy új webhelyhez, de ebben az esetben a jelszavunkat használjuk.

Az érvényesítési szakasz hasonló ahhoz, ahogy a regisztráció után bejelentkezik egy webhelyre.

hitelesítés

Passkeys: Mi a fene és miért? PlatoBlockchain adatintelligencia. Függőleges keresés. Ai. — Teljes méret megtekintése

A navigator.credentials.create Az API áll tanúsítási szakaszunk középpontjában. Új felhasználóként regisztráltunk a rendszerben, és új nyilvános kulcspárt kell létrehoznunk. Meg kell azonban adnunk, hogy milyen kulcspárt szeretnénk generálni. Ez azt jelenti, hogy lehetőséget kell adnunk erre 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

Megkapjuk PublicKeyCredential amely tartalmaz egy AuthenticatorAttestationResponse ami visszajön a teremtés után. A hitelesítő adat tartalmazza a generált kulcspár azonosítóját.

A válasz néhány hasznos információval szolgál. Először is, ebben a válaszban megvan a nyilvános kulcsunk, amelyet el kell küldenünk a tárolandó szervernek. Másodszor, azt is visszakapjuk a clientDataJSON tulajdonság, amelyet dekódolhatunk, és onnan visszakaphatjuk a type, challengeés origin a jelszóról.

A tanúsításhoz érvényesíteni szeretnénk a type, challengeés origin a szerveren, valamint tárolja a nyilvános kulcsot az azonosítójával, pl. kid. Opcionálisan tárolhatjuk is a attestationObject ha kívánjuk. Egy másik hasznos tárolási tulajdonság a LUSTÁLKODIK algoritmus, amelyet fentebb definiáltunk PublicKeyCredentialCreationOptions val vel alg: -7 or alg: -256, annak érdekében, hogy könnyen ellenőrizhessük az aláírt kihívásokat az állítási szakaszban.

kijelentés

A navigator.credentials.get Az API lesz az érvényesítési szakasz középpontjában. Elméletileg itt jelentkezik be a felhasználó a webalkalmazásba a regisztráció után.

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

Megint kapunk a PublicKeyCredential egy AuthenticatorAssertionResponse ezúttal. A hitelesítő adat ismét tartalmazza a kulcsazonosítót.

Mi is megkapjuk a type, challengeés origin tól clientDataJSON újra. A signature most szerepel a válaszban, valamint a authenticatorData. Szükségünk lesz ezekre és a clientDataJSON annak ellenőrzésére, hogy ez a privát kulccsal lett-e aláírva.

A authenticatorData tartalmaz néhány olyan tulajdonságot, amelyeket érdemes nyomon követni. Először is a használt eredet SHA256 hash-je, amely az első 32 bájton belül található, ami hasznos annak ellenőrzésére, hogy a kérés ugyanattól az eredetkiszolgálótól származik-e. A második a signCount, ami a 33-tól 37-ig terjedő bájt. Ezt a hitelesítő generálja, és össze kell hasonlítani az előző értékével, hogy megbizonyosodjon arról, hogy a kulccsal nem történik semmi rossz. Az értéknek mindig 0-nak kell lennie, ha többeszközös jelszóról van szó, és véletlenszerűen nagyobbnak kell lennie, mint az előző signCount, ha egyeszközös jelszóról van szó.

Miután érvényesítette bejelentkezési adatait, be kell jelentkeznie — gratulálok! A Passkeys egy nagyon jó protokoll, de bizonyos figyelmeztetéseket tartalmaz.

Néhány árnyoldal

A Passkeys-nek sok jó oldala van, azonban az írás idején vannak vele problémák. Egyrészt a jelszó még korai támogatást jelent, a Windows rendszeren csak egy-eszköz hitelesítési adatok engedélyezettek, a Linux-rendszerek támogatása pedig nagyon kevés. Passkeys.dev biztosít szép táblázat, ami olyan, mint ennek a protokollnak a Caniuse-ja.

Ezenkívül a Google és az Apple jelszó-platformjai nem kommunikálnak egymással. Ha át szeretné vinni a hitelesítő adatait Android-telefonjáról iPhone-jára… nos, most nincs szerencséje. Ez nem jelenti azt, hogy nincs átjárhatóság! Számítógépére úgy jelentkezhet be, hogy telefonját hitelesítőként használja. De sokkal tisztább lenne, ha beépítené az operációs rendszerbe, és anélkül lenne szinkronizálva, hogy a gyártói szinten zárolnák.

Merre mennek a dolgok?

Hogyan néz ki a jövő jelszóprotokollja? Nagyon jól néz ki! Amint több operációs rendszer támogatást kap, a használatban is fel kell erõsödni, és egyre gyakrabban fogják látni a vadonban. Néhány jelszókezelők sőt első kézből támogatják őket.

A jelszót semmiképpen sem csak az internet támogatja. Android és a iOS mindkettő támogatja a natív hozzáférési kulcsokat első osztályú állampolgárként. Még mindig az elején járunk ennek az egésznek, de várhatóan egyre gyakrabban emlegetjük.

Hiszen megszüntetjük a jelszavak szükségességét, és ezzel biztonságosabbá tesszük számára a világot!