29. října 2026

Proč passkeys na VPN přes RADIUS nefungují a co funguje

Passkeys zastaví phishing v prohlížeči, ale VPN přes RADIUS je nemá kam zapojit. Tři realistické způsoby ochrany přihlášení k VPN a co každému uniká.

V lednu 2026 zahájila FBI operaci Winter SHIELD a její první doporučené opatření zní: nasadit metody odolné vůči phishingu, „bezpečnostní klíče kompatibilní s FIDO2 nebo passkeys vázané na zařízení“ („FIDO2 compliant security keys or device-bound passkeys“), pro ověřování, vzdálený přístup a kritické systémy (FBI). Prováděcí pokyny agentury ENISA k NIS2 říkají o VPN a administračních systémech totéž: „kdekoli je to možné, používejte MFA odolné vůči phishingu“ („wherever possible, use phishing-resistant MFA“) (ENISA, červen 2025). Vlastní dokumentace Microsoftu dnes označuje MFA přes SMS i přes ověřovací aplikaci za „náchylné ke vzdáleným phishingovým útokům“ („prone to remote phishing attacks“) (Microsoft).

Pokud váš vzdálený přístup zajišťuje VPN koncentrátor, který přihlášení ověřuje přes RADIUS, problému jste si pravděpodobně už všimli: passkey není kam zapojit. Tento článek vysvětluje, proč tomu tak je, jaké tři realistické možnosti máte a před čím která z nich nechrání.

Co passkey ve skutečnosti dělá

Passkey je přihlašovací údaj WebAuthn: pár klíčů vygenerovaný v zařízení uživatele a zaregistrovaný pro jeden konkrétní web. Při přihlášení prohlížeč požádá zařízení, aby podepsalo výzvu (challenge) od webu, a podpis se vztahuje i na origin stránky, kterou prohlížeč právě zobrazuje. Web ověří, že origin v podpisu je jeho vlastní. Podvržená přihlašovací stránka na jiné doméně dostane podpis pro nesprávný origin a skutečný web ho odmítne. Uživatel si nemusí ničeho všimnout, protože kontrolu provádí prohlížeč (W3C WebAuthn).

Právě to mají normy na mysli, když mluví o odolnosti vůči phishingu. Aktuální definice NIST zní „schopnost ověřovacího protokolu zabránit vyzrazení ověřovacích tajemství … bez spoléhání na ostražitost žadatele“ („the ability of the authentication protocol to prevent the disclosure of authentication secrets … without relying on the vigilance of the claimant“) a výslovně uvádí, co testem neprojde: hesla, jednorázové kódy, schvalování push výzev a cokoli, co musí uživatel opsat, „nejsou odolné vůči phishingu“ („not phishing-resistant“) (NIST SP 800-63B-4, 2025). CISA řadí metody stejně: FIDO/WebAuthn a PKI nahoře, pak jednorázové kódy a push s porovnáváním čísel (number matching), pak push bez něj a nakonec SMS (CISA).

Pro VPN jsou na způsobu, jakým passkey tuto definici splňuje, podstatné dvě věci. Ochrana vychází z prohlížeče nebo klienta platformy, který ví, s jakým originem komunikuje, a z výzvy a podpisu, které cestují uvnitř přihlašovacího protokolu.

Proč VPN přes RADIUS nemá passkey kam zapojit

RADIUS, protokol, kterým se většina VPN bran ptá ověřovacího serveru „je toto přihlášení v pořádku?“, byl navržen pro vytáčené modemy. Access-Request nese uživatelské jméno a heslo zamaskované MD5 keystreamem, případně odpověď CHAP. Pokud server chce víc, pošle Access-Challenge, jehož text brána „MŮŽE zobrazit“ („MAY display“) uživateli, a ten pak napíše odpověď, která se vrátí v poli pro heslo (RFC 2865). To je celá slovní zásoba: řetězce, které někdo napsal na klávesnici. Není tu pole pro podepsanou aserci WebAuthn, žádný origin, ke kterému by se podpis vázal, protože VPN klient nemá žádnou stránku, a není tu ani user agent, který by to vymáhal.

Samy o sobě tedy passkeys pro přihlášení k VPN nezvládne žádný z těchto systémů:

  • MikroTik RouterOS: pouze RADIUS klient, žádný SAML ani OIDC (dokumentace MikroTik).
  • WireGuard: ověřuje protistrany statickými veřejnými klíči a žádné přihlášení uživatele nemá, takže se na něj žádná z níže uvedených možností nevztahuje; problémem je tam distribuce klíčů (wireguard.com).
  • OpenVPN Access Server: s RADIUSem, LDAP nebo PAM je druhým faktorem časově omezený kód a přihlášení dokáže předat prohlížeči pouze jeho režim SAML (dokumentace OpenVPN).

FortiGate, Palo Alto GlobalProtect a Cisco Secure Client passkeys při přihlášení k VPN nabízejí a všechny tři to řeší stejně: VPN klient otevře prohlížeč, prohlížeč se přihlásí u poskytovatele identity přes SAML, passkey se použije tam a IdP sdělí bráně, že uživatel je v pořádku. FortiClient to dělá volbou „external browser as user agent“, Cisco ASA 9.17 a novější spouštějí systémový prohlížeč právě z tohoto důvodu a GlobalProtect má v klientovi vestavěné zobrazení prohlížeče (Fortinet, Duo pro Cisco ASA, Palo Alto). U vlastní cesty přes RADIUS to Microsoft říká bez obalu: rozšíření NPS porovnávání čísel nezvládne a MS-CHAPv2 nedokáže přenést časově omezený kód (Microsoft).

Passkey se RADIUSu nikdy nedotkne. Práci odvede prohlížeč a brána věří slovu IdP.

Tři realistické možnosti

1. Předřaďte před VPN poskytovatele identity SAML a passkeys používejte tam

Tato cesta dává u uživatelských přihlášení k VPN odolnost vůči phishingu v přísném smyslu, a pokud ji vaše brána i klienti podporují, je to správná odpověď pro tu část problému, která prochází prohlížečem.

Co to stojí: poskytovatele identity s podporou passkeys a licenci, která k tomu patří, dostatečně nové verze klientů pro SAML s externím prohlížečem, zavedení passkeys u všech uživatelů VPN a proces obnovy pro ztracená zařízení. Co zůstane nepokryto: každý systém, který SAML neumí, včetně administrátorského přihlášení samotného firewallu na mnoha zařízeních, MikroTik, WireGuard a cokoli, co se přihlašuje bez prohlížeče.

2. Certifikáty

Ověřování klientským certifikátem (EAP-TLS na VPN nebo certifikáty počítače v zařízení) je druhá metoda, kterou NIST počítá mezi odolné vůči phishingu, a to díky tomu, co nazývá vazbou na kanál (channel binding) (NIST). Uživatel nemá co psát a není co přeposílat.

Co to stojí: certifikační autoritu, registraci každého zařízení, skutečně fungující obnovu a odvolávání certifikátů a někoho, kdo za to všechno odpovídá. CISA popisuje MFA založené na PKI jako metodu vyžadující „vysoce vyzrálé postupy správy identit“ („highly mature identity management practices“) a poznamenává, že není široce podporována (CISA). A certifikát počítače prokazuje, které zařízení se připojilo, nikoli kdo u něj seděl.

3. Ponechte RADIUS a přidejte schválení na telefonu, které přihlášení ukáže

Třetí cesta ponechá bránu i RADIUS server přesně tak, jak jsou, a do RADIUS cesty přidá druhý krok: váš RADIUS server nejprve zkontroluje heslo a teprve když přihlášení přijme, dostane uživatel na telefon žádost o schválení. Žádost uvádí službu, účet a zdrojovou IP adresu a přihlášení uspěje jen tehdy, když ji uživatel schválí. Přesně to dělá Notakey auth-proxy; návod k nastavení postup popisuje pro FreeRADIUS, NPS i User Manager na MikroTiku.

Nasadit ji je nejlevnější, protože na bráně se nemění nic kromě toho, kam posílá RADIUS požadavky, a funguje na každé bráně, která přihlášení ověřuje přes RADIUS, včetně těch, které SAML nikdy podporovat nebudou. Je to také cesta, kterou musíme popisovat nejopatrněji.

Co zastaví. Uniklé, plošně vyzkoušené nebo prolomené heslo už k přihlášení nestačí. FortiBleed, kampaň z roku 2026 proti VPN na FortiGate, nepotřebovala nic víc (naše analýza). Zachycení SMS ani výměna SIM se neuplatní, protože žádný kód neexistuje. Push-bombing dostal útočníky v roce 2022 do VPN Cisca i Uberu: posílali výzvy ke schválení, dokud někdo neklepl na ano (Cisco Talos, Uber). Tady push-bombing narazí na kartu, která ukazuje, který účet se přihlašuje ke které službě a odkud, a na omezovač četnosti na serveru (jak).

Co nezastaví. Nezastaví přeposílání v reálném čase, kdy podvržený VPN portál předává skutečné přihlášení oběti dál a oběť schválí vlastní relaci na útočníkově připojení. Schvalovací karta zobrazuje zdrojovou IP adresu, takže uživatel, který se podívá, přeposílání uvidí; ochrana ale závisí na tom, že se podívá, a definice NIST vylučuje přesně tento druh spoléhání. Schvalování push výzev není odolné vůči phishingu ve smyslu CISA, s porovnáváním čísel i bez něj, a říkáme to na své stránce o bezpečnosti, místo abychom si toto označení vypůjčovali.

Jak průniky skutečně vypadaly

Vyplatí se porovnat možnosti s tím, jak se do VPN a vzdáleného přístupu skutečně pronikalo, a ne s modelem hrozeb.

Incident Jak se útočník dostal dovnitř Která možnost by ho zastavila
Colonial Pipeline, 2021 Starší (legacy) VPN účet s heslem a bez druhého faktoru (svědectví) Kterákoli ze tří
Change Healthcare, 2024 Portál vzdáleného přístupu Citrix bez MFA (svědectví) Kterákoli ze tří
FortiBleed, 2026 Plošně zkoušená, uniklá a prolomená hesla k FortiGate (FBI/USSS) Kterákoli ze tří
Cisco, Uber, 2022 Ukradené heslo, pak push výzvy, dokud jednu někdo nepřijal Passkeys, certifikáty; čitelné schválení ukáže výzvu, kterou nikdo nevyvolal
Scattered Spider, 2023 Podvržené SSO stránky, výměny SIM, push-bombing proti VPN a webmailu (CISA AA23-320A) Passkeys a certifikáty zcela; schválení ukáže přeposílání
0ktapus, 2022 Podvržené stránky Okta přeposílající hesla a jednorázové kódy v reálném čase (Cloudflare) Pouze passkeys a certifikáty

Tři ze šesti nepotřebovaly žádné obcházení MFA: žádné MFA tam nebylo. Při poctivém čtení tabulky vychází, že k většině škod stále dochází v mezeře mezi „pouze heslo“ a „jakýkoli druhý faktor“ a že mezera mezi čitelným schválením a passkey je nejdůležitější u účtů, které bude odhodlaný útočník přeposílat v reálném čase.

Jak se rozhodnout

  • Administrátorské účty firewallů a bran. Právě na ty mířil FortiBleed a právě ty Winter SHIELD doporučuje řešit přednostně. Pokud správcovské rozhraní podporuje klíče FIDO2 nebo přihlášení přes SAML s passkeys, použijte je. Pokud umí pouze RADIUS, je schválení na telefonu u přihlášení administrátora mnohem lepší než samotné heslo, a zvlášť lepší než heslo sdílené.
  • Uživatelská VPN na bráně, která umí SAML s externím prohlížečem. Nasaďte passkeys u poskytovatele identity. To je odpověď v přísném smyslu a dnes ji umožňují FortiGate, GlobalProtect i Cisco.
  • Uživatelská VPN na zařízeních pouze s RADIUSem, jako je MikroTik nebo starší koncentrátory. Na výběr jsou certifikáty nebo schválení na telefonu. Certifikáty vítězí v odolnosti vůči phishingu, pokud už PKI provozujete. Pokud ne, čitelné schválení znamená, že samotné heslo už k přihlášení nestačí, a už dnes nahradí SMS kódy i slepé push výzvy; přihlášení procházející prohlížečem můžete i tak později převést na passkeys.
  • Ať zvolíte cokoli, dívejte se na celou cestu. Průnik do Cisca v roce 2022 začal osobním účtem Google, který synchronizoval pracovní heslo; VPN byla až druhým krokem. MFA na VPN, které chybí na webmailu nebo vzdálené ploše, útočníka jen pošle k sousedním dveřím.

Notakey pokrývá třetí cestu a říkáme otevřeně, kde na žebříčku CISA stojí. Pokud vaše brána používá RADIUS, návod na 2FA pro VPN vás k prvnímu schválení na telefonu dovede za jedno odpoledne a zařízení Notakey běží ve vaší vlastní infrastruktuře nebo v našem cloudu. Vyzkoušejte živé demo, abyste viděli, jak čitelné schválení vypadá na vašem vlastním telefonu, nebo požádejte o demo a my namapujeme vaše přihlášení k VPN, do administrace firewallu a ke vzdálené ploše na pilotní provoz.

← Všechny články

První přihlášení bez hesla už tento týden

30minutový rozhovor s inženýrem, žádná prodejní prezentace. Společně naplánujeme, jak ve vašem prostředí s VPN, SSO nebo Windows spustit funkční pilotní projekt.