Gesla: Kaj za vraga in zakaj?

Te stvari se imenujejo ključi te dni zagotovo krožijo. Bili so glavna atrakcija pri W3C TPAC 2022, dobil podporo v Safari 16, najdejo pot v macOS in iOS, in naj bi bili prihodnost za upravitelje gesel, kot je 1Password. Oni so že podprto v Androidu in bodo kmalu našli pot v Chrome OS in Windows v prihodnjih izdajah.

Izboljšave varnosti operacijskega sistema Geeky ne objavljajo velikih naslovnic v čelni skupnosti, vendar je logično, da bodo gesla »stvar«. In glede na to, kako gesla in aplikacije za gesla vplivajo na uporabniško izkušnjo stvari, kot sta preverjanje pristnosti in obdelava obrazcev, bi se morda želeli vsaj zamisliti okoli njih, da bomo vedeli, kaj prihaja.

To je bistvo tega članka. Že nekaj časa preučujem in eksperimentiram z gesli — in API-jem WebAuthn, na katerem so zgrajeni. Naj povem, kaj sem se naučil.

Kazalo

Terminologija

Tukaj je obvezen del terminologije, ki jo boste želeli izvedeti, ko se bomo poglabljali. Kot večina tehnologije so tudi gesla opremljena z ezoteričnim besedičenjem in akronimi, ki pogosto ovirajo razumevanje. Tukaj vam bom poskušal demistificirati nekatere.

• Zanašajoča se stranka: strežnik, s katerim se boste preverjali. Za označevanje odvisne stranke v tem članku bomo uporabili »strežnik«.
• Naročnik: v našem primeru spletni brskalnik ali operacijski sistem.
• Avtentifikator: Programske in/ali strojne naprave, ki omogočajo ustvarjanje in shranjevanje parov javnih ključev.
• FIDO: Organ za odprte standarde, ki prav tako ustvarja specifikacije okoli poverilnic FIDO.
• WebAuthn: osnovni protokol za gesla, znan tudi kot a FIDO2 poverilnice ali poverilnice FIDO za eno napravo.
• ključi: WebAuthn, vendar s sinhronizacijo v oblaku (imenovane tudi poverilnice FIDO za več naprav, poverilnice, ki jih je mogoče odkriti, ali poverilnice rezidentov).
• Kriptografija javnega ključa: Ustvarjen par ključev, ki vključuje zasebni in javni ključ. Odvisno od algoritma naj bi se uporabljal bodisi za podpisovanje in preverjanje bodisi za šifriranje in dešifriranje. To je znano tudi kot asimetrična kriptografija.
• RSA: Akronim imen ustvarjalcev, Rivest Shamir in Adel. RSA je starejša, a še vedno uporabna družina kriptografije z javnimi ključi, ki temelji na faktoriziranju praštevil.
• Kriptografija eliptične krivulje (ECC): Novejša družina kriptografije na podlagi eliptičnih krivulj.
• ES256: Javni ključ eliptične krivulje, ki uporablja podpisni algoritem ECDSA (PDF) Z SHA256 za zgoščevanje.
• RS256: Kot ES256, vendar uporablja RSA z RSASSA-PKCS1-v1.5 in SHA256.

Kaj so gesla?

Preden lahko govorimo posebej o gesloh, moramo govoriti o drugem protokolu, imenovanem WebAuthn (znan tudi kot FIDO2). Gesla so specifikacija, zgrajena na vrhu WebAuthn. WebAuthn omogoča kriptografijo z javnim ključem, ki nadomesti gesla. Uporabljamo nekakšno varnostno napravo, kot je strojni ključ oz Trusted Platform Module (TPM), za ustvarjanje zasebnih in javnih ključev.

Javni ključ je namenjen vsem. Zasebnega ključa pa ni mogoče odstraniti iz naprave, ki ga je ustvarila. To je bila ena od težav z WebAuthn; če izgubite napravo, izgubite dostop.

Passkeys to reši tako, da zagotovi sinhronizacijo vaših poverilnic v oblaku. Z drugimi besedami, tisto, kar ustvarite v računalniku, je zdaj mogoče uporabiti tudi v telefonu (čeprav zmede obstajajo tudi poverilnice za eno napravo).

Trenutno, v času pisanja, samo iOS, macOS in Android nudijo polno podporo za gesla, sinhronizirana z oblakom, in tudi takrat so omejeni z brskalnikom, ki se uporablja. Google in Apple ponujata vmesnik za sinhronizacijo prek svojih Googlov upravitelj gesel in Apple iCloud obesek za ključe storitev oz.

Kako gesla nadomestijo gesla?

V kriptografiji z javnim ključem lahko izvedete tako imenovano podpis. Podpisovanje vzame del podatkov in jih nato požene skozi algoritem za podpisovanje z zasebnim ključem, kjer jih je nato mogoče preveriti z javnim ključem.

Vsakdo lahko ustvari par javnih ključev in tega ni mogoče pripisati nobeni osebi, saj bi ga lahko ustvarila katera koli oseba. Koristno je, da je mogoče z javnim ključem preveriti samo podatke, podpisane z zasebnim ključem. To je del, ki nadomesti geslo — strežnik shrani javni ključ, mi pa se prijavimo tako, da preverimo, ali imamo drugo polovico (npr. zasebni ključ), s podpisom naključnega izziva.

Kot dodatna prednost, ker javne ključe uporabnika shranjujemo v bazi podatkov, ni več skrbi glede vdorov gesel, ki bi prizadeli milijone uporabnikov. To zmanjšuje lažno predstavljanje, vdore in kopico drugih varnostnih težav, s katerimi se trenutno sooča naš svet, odvisen od gesel. Če pride do vdora v zbirko podatkov, je vse to shranjeno v uporabnikovih javnih ključih, zaradi česar je za napadalca praktično neuporabno.

Nič več pozabljenih e-poštnih sporočil in z njimi povezanih gesel! Brskalnik si bo zapomnil, katere poverilnice ste uporabili za katero spletno mesto – vse kar morate storiti je, da naredite nekaj klikov in prijavljeni ste. Za uporabo gesla lahko zagotovite drugo sredstvo preverjanja, kot je biometrija ali PIN , vendar so še vedno veliko hitrejša od gesel iz preteklosti.

Več o kriptografiji

Kriptografija z javnim ključem vključuje zasebni in javni ključ (znan kot par ključev). Ključi so ustvarjeni skupaj in imajo ločeno uporabo. Na primer, zasebni ključ je namenjen tajnosti, javni ključ pa je namenjen vsem, s katerimi želite izmenjati sporočila.

Ko gre za šifriranje in dešifriranje sporočila, se za šifriranje sporočila uporablja prejemnikov javni ključ, tako da lahko samo prejemnikov zasebni ključ dešifrira sporočilo. V varnostnem jeziku je to znano kot "zagotavljanje zaupnosti". Vendar to ne zagotavlja dokaza, da je pošiljatelj tisti, za katerega se predstavlja, saj lahko vsakdo uporabi javni ključ, da nekomu pošlje šifrirano sporočilo.

Obstajajo primeri, ko moramo preveriti, ali je sporočilo res prišlo od pošiljatelja. V teh primerih uporabljamo podpisovanje in preverjanje podpisa, da zagotovimo, da je pošiljatelj tisti, za katerega se predstavlja (znan tudi kot Pristnost). V javnem ključu (imenovanem tudi asimetrična) kriptografija, se to običajno naredi s podpisom zgoščene vrednosti sporočila, tako da ga lahko pravilno preveri le javni ključ. Zgoščena vrednost in pošiljateljev zasebni ključ ustvarita podpis, potem ko ju zaženete skozi algoritem, nato pa lahko kdorkoli preveri, ali je sporočilo prišlo od pošiljatelja s pošiljateljevim javnim ključem.

Kako dostopamo do gesel?

Za dostop do gesel jih moramo najprej ustvariti in nekje shraniti. Nekatere od teh funkcij je mogoče zagotoviti z avtentifikatorjem. An avtentikator je katera koli naprava, podprta s strojno ali programsko opremo, ki omogoča ustvarjanje kriptografskega ključa. Pomislite na tista enkratna gesla, ki jih dobite Google Authenticator, 1Passwordali LastPass, Med drugim.

Na primer, overitelj programske opreme lahko za ustvarjanje poverilnic uporabi modul zaupanja vredne platforme (TPM) ali varno enklavo naprave. Poverilnice je mogoče nato shraniti na daljavo in sinhronizirati med napravami, npr. Strojni avtentifikator bi bil nekaj podobnega YubiKey, ki lahko ustvari in shrani ključe na sami napravi.

Za dostop do avtentifikatorja mora imeti brskalnik dostop do strojne opreme, za to pa potrebujemo vmesnik. Vmesnik, ki ga tukaj uporabljamo, je protokol CTAP (Client to Authenticator Protocol). Omogoča dostop do različnih avtentifikatorjev preko različnih mehanizmov. Na primer, z uporabo CTAP lahko dostopamo do avtentifikatorja prek NFC, USB in Bluetooth.

Eden bolj zanimivih načinov uporabe gesel je povezava telefona prek povezave Bluetooth z drugo napravo, ki morda ne podpira gesel. Ko sta napravi seznanjeni prek Bluetootha, se lahko prijavim v brskalnik na svojem računalniku s telefonom kot posrednikom!

Razlika med geslom in WebAuthn

Gesla in ključi WebAuthn se razlikujejo na več načinov. Prvič, gesla veljajo za poverilnice za več naprav in jih je mogoče sinhronizirati med napravami. Nasprotno pa so ključi WebAuthn poverilnice ene naprave – domišljen način, da poveste, da ste za preverjanje vezani na eno napravo.

Drugič, za preverjanje pristnosti v strežniku morajo ključi WebAuthn zagotoviti uporabniško ročico za prijavo, nato pa allowCredentials strežnik vrne odjemalcu seznam, ki sporoča, katere poverilnice je mogoče uporabiti za prijavo. Gesla preskočijo ta korak in uporabijo ime domene strežnika, da pokažejo, kateri ključi so že povezani s tem mestom. Izberete lahko geslo, ki je povezano s tem strežnikom, saj ga vaš sistem že pozna.

V nasprotnem primeru so ključi kriptografsko enaki; razlikujejo se le v tem, kako so shranjeni in katere informacije uporabljajo za začetek postopka prijave.

Postopek… na kratko

Postopek za generiranje WebAuthn ali gesla je zelo podoben: od strežnika pridobite izziv in nato uporabite navigator.credentials.create spletni API za ustvarjanje para javnih ključev. Nato pošljite izziv in javni ključ nazaj na strežnik, da ju shranite.

Po prejemu javnega ključa in izziva strežnik potrdi izziv in sejo, iz katere je bil ustvarjen. Če se to preveri, se javni ključ in vse druge pomembne informacije, kot je identifikator uporabnika ali podatki o potrdilu, shranijo v zbirko podatkov.

Uporabnik ima še en korak — pridobiti drug izziv s strežnika in uporabiti navigator.credentials.get API za podpis izziva. Podpisani izziv pošljemo nazaj strežniku, strežnik pa preveri izziv, nato pa nas prijavi, če je podpis uspešen.

Za vsak korak je seveda še nekaj več. Toda na splošno bi se tako prijavili na spletno mesto z uporabo WebAuthn ali gesla.

Meso in krompir

Gesla se uporabljajo v dveh različnih fazah: potrdilo in trditev faze.

Fazo atestiranja lahko razumemo tudi kot fazo registracije. Prijavili bi se z e-pošto in geslom za novo spletno mesto, vendar bi v tem primeru uporabili naše geslo.

Faza trditve je podobna prijavi na spletno mesto po prijavi.

Potrjevanje

O navigator.credentials.create API je v središču naše faze potrjevanja. V sistemu smo registrirani kot nov uporabnik in moramo ustvariti nov par javnih ključev. Vendar pa moramo določiti, kakšen par ključev želimo ustvariti. To pomeni, da moramo zagotoviti možnosti za 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

Dobili bomo PublicKeyCredential ki vsebuje AuthenticatorAttestationResponse ki se vrne po ustvarjanju. Poverilnica ima ustvarjen ID para ključev.

Odgovor ponuja nekaj koristnih informacij. Prvič, v tem odgovoru imamo svoj javni ključ, ki ga moramo poslati na strežnik, da se shrani. Drugič, prav tako dobimo nazaj clientDataJSON lastnino, ki jo lahko dekodiramo in od tam dobimo nazaj type, challengein origin gesla.

Za atestiranje želimo potrditi type, challengein origin na strežniku, kot tudi shraniti javni ključ z njegovim identifikatorjem, npr. Po želji lahko tudi shranimo attestationObject če želimo. Druga koristna lastnost za shranjevanje je COSE algoritem, ki je definiran zgoraj v našem  PublicKeyCredentialCreationOptions z alg: -7 or alg: -256, za enostavno preverjanje morebitnih podpisanih izzivov v fazi trditve.

Trditev

O navigator.credentials.get API bo v središču faze trditve. Konceptualno bi bilo to mesto, kjer se uporabnik po prijavi prijavi v spletno aplikacijo.

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

Spet bomo dobili a PublicKeyCredential s AuthenticatorAssertionResponse tokrat. Poverilnica spet vključuje identifikator ključa.

Dobimo tudi type, challengein origin Iz clientDataJSON ponovno. The signature je zdaj vključen v odgovor, kot tudi authenticatorData. Potrebovali bomo tiste in to clientDataJSON da preverite, ali je bilo to podpisano z zasebnim ključem.

O authenticatorData vključuje nekatere lastnosti, ki jim je vredno slediti. Najprej je zgoščena vrednost SHA256 izvora, ki ga uporabljate, ki se nahaja v prvih 32 bajtih, kar je uporabno za preverjanje, ali zahteva prihaja iz istega izvornega strežnika. Drugo je signCount, ki je od bajta 33 do 37. To je ustvarjeno iz avtentifikatorja in ga je treba primerjati s svojo prejšnjo vrednostjo, da se zagotovi, da se s ključem ne dogaja nič nejasnega. Vrednost mora biti vedno 0, če gre za geslo za več naprav, in mora biti naključno večja od prejšnjega signCount, če gre za geslo za eno napravo.

Ko potrdite svojo prijavo, bi morali biti prijavljeni — čestitke! Passkeys je precej odličen protokol, vendar ima nekaj opozoril.

Nekaj ​​slabosti

Gesla imajo veliko prednosti, vendar je v času tega pisanja nekaj težav z njimi. Prvič, geslo je še vedno nekoliko zgodnje podpore, saj so v sistemu Windows dovoljene samo poverilnice za eno napravo in zelo malo podpore za sisteme Linux. Gesla.dev določa lepa miza, ki je nekako podobna Caniuseu tega protokola.

Poleg tega Googlova in Applova platforma za geslo ne komunicirata med seboj. Če želite svoje poverilnice iz telefona Android prenesti na svoj iPhone ... no, zaenkrat nimate sreče. To ne pomeni, da ni interoperabilnosti! V svoj računalnik se lahko prijavite z uporabo telefona kot avtentifikatorja. Vendar bi bilo veliko čistejše samo, če bi ga imeli vgrajenega v operacijski sistem in sinhroniziranega, ne da bi ga zaklenili na ravni prodajalca.

Kam gredo stvari?

Kako izgleda protokol gesel prihodnosti? Izgleda kar dobro! Ko pridobi podporo več operacijskih sistemov, bi se morala uporaba razširiti in videli boste, da se vedno bolj uporablja v naravi. nekaj skrbniki gesel jih bodo celo podprli iz prve roke.

Gesla nikakor niso podprta samo v spletu. Android in iOS bosta oba podpirala domača gesla kot prvorazredna državljana. Še vedno smo na začetku vsega tega, vendar pričakujte, da se bo vse več omenjalo.

Navsezadnje odpravimo potrebo po geslih in s tem naredimo svet zanj varnejši!

viri

Tukaj je še nekaj virov, če želite izvedeti več o geslih. Obstajata tudi skladišče in predstavitev, ki sem ju sestavil za ta članek.

• Distribucija vsebine in PR s pomočjo SEO. Okrepite se še danes.
• Platoblockchain. Web3 Metaverse Intelligence. Razširjeno znanje. Dostopite tukaj.
• vir: https://css-tricks.com/passkeys-what-the-heck-and-why/