Passkey

Passkey (česky též přístupový klíč, technicky discoverable credential podle standardu FIDO2/WebAuthn) je přihlašovací údaj pro autentizaci, který místo sdíleného tajemství používá pár klíčů asymetrické kryptografie. Při registraci zařízení uživatele vytvoří pro jednu konkrétní službu nový pár klíčů a službě předá jen veřejnou část. Při přihlášení služba pošle náhodnou výzvu, zařízení ji podepíše soukromým klíčem a služba podpis ověří. Uživatel přitom nic neopisuje ani nepamatuje: jen odemkne zařízení otiskem prstu, obličejem nebo PINem. Protože prohlížeč do podpisu vkládá adresu stránky, na které přihlášení probíhá, passkey na podvodné doméně nefunguje, a proto patří k nejsilnějším dostupným metodám proti phishingu.

Klíčové údaje
Anglicky	passkey, passkeys, FIDO2 credential, discoverable credential (dříve resident key)
Standardy	FIDO2 = W3C Web Authentication (WebAuthn) + FIDO CTAP2
Správce standardů	FIDO Alliance, W3C (Web Authentication Working Group)
Typické algoritmy	ECDSA P-256 se SHA-256 (COSE −7), Ed25519 (COSE −8), RSA (COSE −257)
Kde je soukromý klíč	platforma (iCloud Keychain, Google Password Manager, Windows Hello), správce hesel, hardwarový bezpečnostní klíč
Ověření uživatele	lokálně v zařízení: biometrie nebo PIN, nic se neposílá na server
Odolnost proti phishingu	ano, díky vazbě na doménu (rpId) a origin
Prosazení	závazek Apple, Google a Microsoft 5. května 2022, plošná dostupnost od podzimu 2022

Základní princip

U klasického hesla zná tajemství uživatel i služba (nebo jeho otisk). Kdo tajemství odposlechne, vyláká nebo ukradne z databáze, může se přihlásit. Passkey tento model obrací. Tajemstvím je soukromý klíč, který nikdy neopustí chráněné úložiště na straně uživatele, a služba drží jen veřejný klíč. Ten je k přihlášení k ničemu: slouží pouze k ověření digitálního podpisu.

Na přihlášení se podílejí tři strany:

• Relying party (RP, „spoléhající se strana“): webová služba nebo aplikace, která uživatele ověřuje. Identifikuje ji rpId, typicky doménové jméno, např. example.cz.
• Klient: prohlížeč nebo operační systém. Zprostředkovává komunikaci a hlavně do zprávy nezfalšovatelně doplňuje, na jaké adrese uživatel skutečně je.
• Autentizátor: místo, kde je uložen soukromý klíč a kde se ověřuje uživatel. Buď platformní (zabudovaný v telefonu či počítači, často s bezpečnostním čipem typu Secure Enclave nebo TPM), nebo roamingový (externí bezpečnostní klíč přes USB, NFC nebo Bluetooth).

Registrace

1. Uživatel se přihlásí dosavadním způsobem a zvolí „Vytvořit passkey“.
2. Server vygeneruje náhodnou výzvu (challenge, alespoň 16 bajtů) a pošle ji spolu s rpId, identifikátorem uživatele (user handle) a seznamem povolených algoritmů.
3. Prohlížeč ověří, že rpId odpovídá doméně aktuální stránky, a předá požadavek autentizátoru.
4. Autentizátor požádá uživatele o ověření (otisk, obličej, PIN zařízení) a vygeneruje nový pár klíčů jen pro tuto službu a tento účet.
5. Autentizátor vrátí veřejný klíč, identifikátor přihlašovacího údaje (credential ID), příznaky a volitelně atestaci. Klient přiloží clientDataJSON s výzvou a originem stránky.
6. Server zkontroluje výzvu, origin, rpId a příznaky a uloží si veřejný klíč a credential ID k účtu.

Přihlášení

1. Server vygeneruje novou jednorázovou výzvu.
2. Prohlížeč nabídne uživateli passkeys uložené pro dané rpId (díky tomu, že jde o discoverable credential, není nutné ani zadat uživatelské jméno).
3. Uživatel se ověří v zařízení. Úspěch se zapíše do příznaku UV (user verified), samotná fyzická přítomnost do příznaku UP (user present).
4. Autentizátor podepíše soukromým klíčem spojení dvou struktur: authenticatorData (otisk rpId, příznaky, čítač) a otisk clientDataJSON (výzva, origin, typ operace).
5. Server ověří podpis uloženým veřejným klíčem, shodu výzvy, originu a otisku rpId a nastavení příznaku UV. Teprve pak uživatele přihlásí.

Protože je výzva pokaždé jiná, nemá smysl zachycenou odpověď poslat znovu (replay útok). Biometrie ani PIN se na server nikdy neposílají: odemykají jen klíč uvnitř zařízení. Passkey tak sám o sobě kombinuje faktor vlastnictví (zařízení s klíčem) a faktor znalosti nebo vlastnosti, a splňuje tím definici vícefaktorové autentizace.

Proč je passkey odolný proti phishingu

Při phishingu oběť na podvržené stránce (např. examp1e-login.cz) zadá heslo i jednorázový kód a útočník je přes reverzní proxy (člověk uprostřed) okamžitě přepošle skutečné službě. U passkey to nejde ze tří důvodů:

• Vazba na rpId. Klíč vytvořený pro example.cz prohlížeč na jiné doméně vůbec nenabídne. Uživatel nemá co omylem prozradit.
• Origin v podepsaných datech. I kdyby útočník autentizátor nějak oslovil, podepsaná data obsahují skutečný origin podvodné stránky. Server ho porovná s očekávaným a odmítne.
• Nic opakovatelného. Neexistuje kód ani heslo, které by šlo opsat do telefonu „technické podpory“. Klasické sociální inženýrství tak ztrácí hlavní cíl.

Únik databáze služby útočníkovi také nepomůže: veřejné klíče nelze použít k přihlášení a každý je jiný, takže nevzniká problém opakovaně použitých hesel.

Odolnost má ale hranice. Passkey nechrání před malwarem, který převezme už přihlášenou relaci nebo ukradne relační cookie, a nechrání před útokem na slabší proces kolem přihlášení, typicky obnovu účtu přes SMS.

Standardy a historie

Standardy vyvíjí FIDO Alliance (Fast IDentity Online), průmyslové sdružení veřejně představené v únoru 2013, a konsorcium W3C. FIDO2 je souhrnný název dvou specifikací:

• WebAuthn (W3C): JavaScriptové API prohlížeče navigator.credentials.create() a navigator.credentials.get() a formát dat, která si vyměňuje klient se serverem.
• CTAP2 (Client to Authenticator Protocol, FIDO): protokol mezi klientem a externím autentizátorem přes USB, NFC, Bluetooth a takzvaný hybridní přenos.

Rok	Milník	Význam
2014	FIDO U2F a UAF 1.0 (prosinec)	hardwarový klíč jako druhý faktor k heslu; Google, Yubico
2019	WebAuthn Level 1 se stává doporučením W3C (březen)	jednotné API ve všech hlavních prohlížečích
2021	WebAuthn Level 2, CTAP 2.1	lepší správa klíčů na autentizátorech, rozšíření
2022	5. května společný závazek Apple, Google a Microsoft	synchronizace klíčů mezi zařízeními, přihlášení telefonem k blízkému počítači; Apple v červnu zavádí název „passkey“
2022–2023	iOS 16, macOS Ventura, Android, Chrome; Google nabízí passkeys jako výchozí metodu pro osobní účty (říjen 2023)	masová dostupnost
2024–2025	FIDO zveřejňuje návrhy CXP a CXF pro přenos passkeys mezi správci; CXF 1.0 jako Proposed Standard (srpen 2025); CTAP 2.2	řešení přenositelnosti
2026	CTAP 2.3 (únor), WebAuthn Level 3 doporučením W3C (25. srpna)	conditional UI, příznaky zálohy, Signals API, Related Origin Requests

Synchronizované a zařízením vázané passkeys

Původní FIDO klíče byly navždy uzavřené v jednom zařízení. Ztráta zařízení znamenala ztrátu přihlašovacího údaje, což masovému nasazení bránilo. Passkeys proto existují ve dvou podobách:

• Synchronizované (synced, multi-device): soukromý klíč je koncově šifrovaný a zálohovaný do cloudu poskytovatele, takže je k dispozici na všech zařízeních uživatele. Pohodlné a odolné vůči ztrátě telefonu.
• Vázané na zařízení (device-bound): klíč nelze z hardwaru exportovat. Bezpečnější, ale ztráta zařízení znamená nutnost obnovy.

Služba to pozná z příznaků v authenticatorData: BE (backup eligible, klíč může být zálohován) a BS (backup state, klíč zálohován je).

Poskytovatel	Typ	Synchronizace	Ověření uživatele	Poznámka
iCloud Keychain (Apple)	platformní, synchronizovaný	mezi zařízeními Apple, koncově šifrováno	Face ID, Touch ID, kód zařízení	sdílení passkeys ve skupinách rodiny
Google Password Manager	platformní, synchronizovaný	Android, Chrome na desktopu	otisk, obličej, zámek obrazovky, PIN správce	dostupný i mimo Android přes Chrome
Windows Hello	platformní, typicky vázaný na zařízení	klíč chráněný v TPM konkrétního počítače	obličej, otisk, PIN Windows	Windows 11 umí ukládat passkeys i do správců třetích stran
1Password, Bitwarden a další správci hesel	synchronizovaný	napříč operačními systémy	odemčení trezoru	řeší uzamčení u jednoho výrobce platformy
YubiKey a jiné bezpečnostní klíče	roamingový, vázaný na zařízení	žádná	PIN klíče, u některých modelů otisk	omezený počet slotů pro discoverable credentials, neexportovatelný klíč

Rozdíl je podstatný pro regulované prostředí. NIST SP 800-63B-4 povoluje synchronizované autentizátory na úrovni AAL2, ale na úrovni AAL3 je výslovně zakazuje, protože AAL3 vyžaduje neexportovatelný soukromý klíč.

Přihlášení z jiného zařízení (hybridní přenos)

Uživatel často sedí u počítače, na kterém žádný passkey nemá (cizí počítač, jiný operační systém). Pro tento případ existuje hybridní přenos (hybrid transport), původně nazývaný caBLE (cloud-assisted Bluetooth Low Energy), specifikovaný v CTAP 2.2:

1. Prohlížeč na počítači zobrazí QR kód s jednorázovým klíčovým materiálem.
2. Uživatel ho naskenuje telefonem, na kterém passkey je.
3. Telefon a počítač ověří fyzickou blízkost přes Bluetooth Low Energy. Bez ní přihlášení neproběhne, což brání vzdálenému zneužití QR kódu.
4. Vlastní data putují šifrovaným tunelem přes relay server (u Androidu a Chromu provozuje Google, u Applu Apple). Relay vidí jen šifrovaný provoz.
5. Telefon ověří uživatele a podepíše výzvu, počítač ji předá službě.

Zařízení si mohou spárování zapamatovat, takže příště už QR kód není nutný.

Atestace

Při registraci může autentizátor připojit atestaci: podpis od výrobce, kterým dokládá svůj model a vlastnosti (např. „certifikovaný hardwarový klíč s neexportovatelným úložištěm“). Model identifikuje AAGUID, šestnáctibajtový identifikátor. Metadata a certifikační úrovně autentizátorů publikuje FIDO Alliance v Metadata Service (MDS).

Spotřebitelské služby atestaci obvykle nevyžadují (attestation: "none"), synchronizované passkeys ji většinou ani neposkytují. Firmy a úřady ji využívají k povolení jen schválených modelů klíčů, např. certifikovaných podle FIPS 140.

AAGUID se podle WebAuthn Level 3 může předávat i bez atestace, aby služba mohla v nastavení účtu zobrazit, ve kterém správci je passkey uložen.

Obnova účtu a ztráta zařízení

Passkey odstraňuje heslo, ale ne potřebu vrátit uživateli přístup, když o klíč přijde. Obnova je proto nejslabším článkem celého systému:

• U synchronizovaných passkeys se obnova přesouvá na účet poskytovatele (Apple ID, Google účet, trezor správce hesel). Bezpečnost passkeys je tak shora omezena bezpečností tohoto účtu a jeho obnovy.
• U zařízením vázaných klíčů je nutné mít registrovaný záložní klíč nebo jinou metodu. Ztráta jediného klíče bez zálohy znamená zablokovaný účet.
• Pokud služba jako záložní cestu nabízí SMS kód nebo odkaz e-mailem, útočník se o passkey nepokouší a zaútočí přímo na tuto cestu.

Proto služby umožňují registrovat více passkeys na jeden účet a vydávají záložní kódy.

Srovnání s jinými metodami

Vlastnost	Passkey	Heslo	TOTP aplikace	SMS kód
Co server uchovává	veřejný klíč	otisk hesla (hash)	sdílené tajemství	telefonní číslo
Únik databáze služby	neškodný	umožňuje lámání hesel	umožňuje generovat kódy	umožňuje cílený SIM swap
Odolnost proti phishingu	ano	ne	ne (kód lze přeposlat v reálném čase)	ne
Opakované použití napříč službami	nemožné	běžné	nehraje roli	nehraje roli
Co uživatel opisuje	nic	heslo	6místný kód	6místný kód
Závislost na zařízení	ano (s výjimkou synchronizace)	ne	ano	ano, na SIM a operátorovi
Typická role	samostatná metoda splňující MFA	první faktor	druhý faktor	nouzový druhý faktor

Omezení a kritika

• Uzamčení u výrobce (vendor lock-in). Passkey uložený v iCloud Keychain se dlouho nedal přenést do Google Password Manageru ani naopak. FIDO proto připravuje Credential Exchange Format (CXF), formát pro bezpečný export a import přihlašovacích údajů, který je od srpna 2025 ve stavu Proposed Standard, a Credential Exchange Protocol (CXP) pro přenos mezi poskytovateli, který je zatím ve fázi pracovního návrhu. Apple a Google začaly podporu přímého importu a exportu zavádět, plně standardizovaný přenos mezi platformami ale zatím nefunguje.
• Nekonzistentní uživatelské rozhraní. Dialogy se liší podle prohlížeče, systému a správce a uživatel často neví, kde je passkey uložen.
• Souběh s hesly. Většina služeb heslo ponechává jako záložní metodu. Pokud ho nelze vypnout, útočník se dál může pokusit přihlásit heslem a SMS kódem a výhoda passkey se ztrácí.
• Bezpečnost platformy. U synchronizovaných passkeys rozhoduje zabezpečení cloudového účtu a koncového šifrování poskytovatele. Kompromitace Apple ID nebo trezoru správce hesel může znamenat přístup ke všem passkeys.

Rozšíření v Česku

Passkeys podporují globální služby, které čeští uživatelé denně používají (Google, Microsoft, Apple, Amazon, PayPal a další). Z domácích služeb je nasazuje Seznam.cz: podle zprávy serveru Lupa.cz z října 2026 si uživatelé mohou passkey vytvořit v nastavení zabezpečení účtu, přičemž heslo zůstává funkční. Passkeys, bezpečnostní klíče a autentizační aplikace na Seznamu nahradily dvoufázové ověření přes Seznam Aplikaci, jehož podpora skončila v lednu 2026.

Tipy pro vývojáře

• Nepište kryptografii sami. Používejte ověřené knihovny, např. SimpleWebAuthn (TypeScript), py_webauthn (Python), java-webauthn-server (Java) nebo webauthn-rs (Rust).
• Zvolte správně rpId. rpId musí být registrovatelná doména aktuálního originu nebo jeho přípona. Volba example.cz umožní používat passkey na www.example.cz i app.example.cz, volba app.example.cz ne. Pozdější změna rpId znamená, že stávající passkeys přestanou fungovat. Pro několik různých domén (example.cz, example.de) slouží Related Origin Requests se seznamem v /.well-known/webauthn.
• Výzvy generujte na serveru kryptograficky bezpečným generátorem, s jednorázovou a krátkou platností.
• Vždy ověřujte origin, rpId, výzvu, typ operace a příznaky UP a UV. Pro bezheslové přihlášení vyžadujte userVerification: "required".
• Zapněte conditional UI (automatické vyplňování): mediation: "conditional" a atribut autocomplete="username webauthn" u pole se jménem. Prohlížeč pak nabídne passkey přímo v políčku formuláře.
• Usnadněte přechod: po přihlášení heslem nabídněte vytvoření passkey, případně tiše přes conditional create.
• Povolte více passkeys na účet a zobrazte je v nastavení s názvem správce (podle AAGUID).
• Nespoléhejte na čítač podpisů: synchronizované passkeys obvykle vrací nulu.
• Promyslete obnovu účtu stejně pečlivě jako samotné přihlášení. Nejslabší záložní metoda určuje skutečnou úroveň zabezpečení.

Minimální volání pro přihlášení v prohlížeči:

const cred = await navigator.credentials.get({
mediation: "conditional",
publicKey: { challenge, rpId: "example.cz", userVerification: "required" }
});

Doporučení pro uživatele

• Kde služba passkey nabízí, vytvořte si ho, přednostně u e-mailu, správce hesel, bankovnictví a sociálních sítí.
• Passkey vytvářejte jen na vlastním zařízení, které je zamčené biometrií nebo silným PINem. Kdo zná PIN vašeho telefonu, může použít i vaše passkeys.
• Zabezpečte účet, do kterého se passkeys synchronizují (Apple ID, Google účet, správce hesel): silným heslem, vícefaktorovým ověřením a ideálně dalším passkey nebo bezpečnostním klíčem.
• Mějte vždy aspoň dvě cesty přihlášení: passkey na dvou zařízeních, záložní bezpečnostní klíč nebo uložené záložní kódy.
• Pokud služba umožňuje vypnout heslo nebo SMS, zvažte to. Jinak zůstávají otevřenými dveřmi.

Doporučení pro organizace

• Požadavky na MFA odolné proti phishingu se zpřísňují. Memorandum OMB M-22-09 z ledna 2022 ukládá federálním úřadům USA používat pro zaměstnance, dodavatele i partnery výhradně metody odolné proti phishingu (FIDO2/WebAuthn nebo čipové karty PIV). CISA totéž doporučuje i soukromému sektoru.
• NIS2 a český zákon o kybernetické bezpečnosti vyžadují vícefaktorovou autentizaci u vybraných účtů a přístupů. Passkeys a bezpečnostní klíče FIDO2 jsou nejjednodušší cestou, jak požadavek splnit s odolností proti phishingu. Konkrétní požadavky stanoví prováděcí vyhlášky a metodika NÚKIB.
• Rozlišujte úrovně účtů. Pro běžné zaměstnance stačí synchronizované passkeys (NIST AAL2). Pro administrátory, správce identit a přístupy do produkce vyžadujte zařízením vázané hardwarové klíče s atestací (AAL3), dva na osobu.
• Zahrňte passkeys do koncepce Zero Trust, kde je silné ověření identity základem.
• Postupně odstraňujte slabé metody: SMS, hlasové hovory a push bez párování čísel, staré protokoly bez podpory MFA.
• Zabezpečte helpdesk, častou cestu útoku přes žádosti o reset „ztraceného“ klíče. Obnovu podmiňte ověřením totožnosti, které nejde provést jen telefonicky.

Zdroje

• Jirásek, P., Novák, L., Požár, J.: Výkladový slovník kybernetické bezpečnosti, 6. aktualizované vydání, Centrum kybernetické bezpečnosti, z.ú. / NÚKIB
• W3C: Web Authentication: An API for accessing Public Key Credentials Level 3
• FIDO Alliance: Client to Authenticator Protocol (CTAP) v2.2, Proposed Standard, 14. 7. 2025
• FIDO Alliance: Credential Exchange Format (CXF) v1.0, Proposed Standard, 14. 8. 2025
• Apple Newsroom: Apple, Google and Microsoft commit to expanded support for FIDO standard to accelerate availability of passwordless sign-ins (5. 5. 2022)
• NIST SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
• CISA: Implementing Phishing-Resistant MFA (fact sheet)
• passkeys.dev: dokumentace pro vývojáře (FIDO Alliance a W3C)
• MDN Web Docs: Web Authentication API
• SimpleWebAuthn: knihovna pro WebAuthn v TypeScriptu
• Lupa.cz: Přihlašování na Seznamu se mění. Hesla už nebudou potřeba (9. 10. 2026)