A Passkey-rejtély

A jelszavakat az elmúlt évtizedekben sokszor nyilvánították már „halottnak”, általában egy újabb adatvédelmi incidens, credential-stuffing kampány vagy phishing hullám után. Ezek a jóslatok azonban rendre nem váltak valóra. Nem azért, mert a jelszavak ideálisak lennének, hanem mert egyszerűek, széles körben támogatottak, és megfelelő megvalósítás mellett (megfelelő hossz, helyes hash-elés, újrafelhasználás nélkül) továbbra is elfogadható védelmet nyújtanak.

A valós használat azonban ritkán felel meg a bevált gyakorlatoknak. A jelszó-újrafelhasználás, a gyenge titkok és a phishing továbbra is rendszerszintű problémák, miközben ezek kezelési költsége folyamatosan nő. Ebben a környezetben az iparág egyre inkább a Passkey-ek felé mozdult el, nem mint egy újabb fokozatos erősítés, hanem mint a jelszavak lehetséges utódja. Ebben a bejegyzésben a Passkey-ek bevezetésének és használatának kihívásait vizsgáljuk meg, különösen azokat az eseteket, ahol a régi kockázatok csökkenésével új kockázatok jelennek meg.

Mielőtt ezekre a kockázatokra rátérnénk, érdemes tisztázni, hogy pontosan mik is a Passkey-ek, és hogyan működnek.

Mik azok a Passkey-ek?

A Passkey-ek a Web Authentication szabványra (WebAuthn) épülnek, amely lehetővé teszi, hogy a böngészők és platformok erős, phishing-ellenálló hitelesítést valósítsanak meg nyilvános kulcsú kriptográfiával. A regisztráció során a felhasználó eszköze létrehoz egy kriptográfiai kulcspárt: a publikus kulcsot a szolgáltatás megkapja és szerveroldalon tárolja, míg a privát kulcs biztonságosan az eszközön marad. Hitelesítéskor a szolgáltatás egy kihívást küld, amelyet kizárólag a privát kulcs tud aláírni, ezzel igazolva a jogosultságot anélkül, hogy bármilyen megosztott titok továbbításra kerülne.

Eszközszinten ezt a folyamatot a CTAP (Client to Authenticator Protocol) támogatja, amely meghatározza, hogyan kommunikálnak a külső vagy platform-szintű authenticatorok – például hardveres security key-ek vagy biometrikus alrendszerek – a WebAuthn műveletet végrehajtó klienssel. A gyakorlatban a WebAuthn a böngésző és a szerver közötti kommunikációt kezeli, míg a CTAP a kliens és az authenticator közötti kapcsolatért felel. Együttesen lehetővé teszik, hogy a hitelesítés egy konkrét eszközhöz vagy megbízható platformhoz legyen kötve, gyakran helyi felhasználói ellenőrzéssel, például biometrikus azonosítással vagy eszköz PIN-kóddal.

A megosztott titkok eltávolításával a Passkey-ek teljes támadási osztályokat szüntetnek meg, amelyek a jelszavakat sújtják, különösen a phishinget és a credential replay támadásokat. Ugyanakkor ezzel a bizalom is áthelyeződik: a megjegyzett titkok helyett az eszközökre, platformszolgáltatókra, felhős szinkronizációs mechanizmusokra és account recovery folyamatokra. Emiatt a Passkey-ek nem csodafegyverek, hanem a kockázat újraelosztását jelentik, amelyet tudatosan kell kezelni.

Ezzel az alapozással rátérhetünk azokra a kockázatokra és megfontolásokra, amelyek a Passkey-ek nagy léptékű bevezetésekor jelentkeznek.

A felhőben szinkronizált Passkey-ek növelik a támadási felületet

A felhőalapú vagy password manager jellegű szinkronizáció lehetővé teszi, hogy a privát kulcsok mentésre kerüljenek és több eszközön is használhatók legyenek, ami jelentősen javítja a használhatóságot. Ugyanakkor ez központosított célpontokat hoz létre, és növeli a kár mértékét, ha a szinkronizációs szolgáltató vagy az alatta lévő fiók (például egy Microsoft vagy Google account) kompromittálódik.

A WebAuthn csökkenti a klasszikus credential phishing kockázatát, de az endpoint malware, a kompromittált authenticator felületek, a biometrikus kényszerítés, a kényszerített regisztrációs forgatókönyvek és a session hijacking továbbra is életképes támadási utak, amelyekhez kiegészítő endpoint és viselkedésalapú kontrollokra van szükség. Ahogy ma az infostealer-ek és account takeover eszközök a böngészőben tárolt jelszavakat célozzák, úgy a szinkronizált Passkey-ek is hasonló kockázatoknak lehetnek kitéve, különösen nem menedzselt eszközökön vagy gyenge account hitelesítési beállítások mellett.

Az eszközhöz kötött attestation áthelyezi a felelősséget

Enterprise identity platformok képesek authenticator attestation megkövetelésére annak érdekében, hogy a Passkey-ek eszközhöz kötöttek és nem szinkronizálhatók legyenek, de ez a kontroll jellemzően opcionális. Ha az attestation nincs kikényszerítve, a hitelesítő adatok nem menedzselt eszközökön is regisztrálhatók vagy használhatók, illetve szinkronizált Passkey-ek önállóan is felvehetők, megkerülve a szabályzatokat.

Az attestation a kockázat jelentős részét az endpoint eszközre helyezi át. Bár a hitelesítési folyamat erősnek tűnhet, egy ellopott mobiltelefon vagy laptop, amelyet csak egy egyszerű, négyjegyű PIN véd, közvetlen hozzáférést biztosíthat érzékeny fiókokhoz. Ahogy az erős tudásalapú faktorok (jelszavak) kikerülnek, a biztonságért való felelősség egyre inkább az egyes munkavállalókra hárul, ami enterprise kockázati szempontból kényelmetlen lehet.

Account recovery kompromisszumok

Ha nem szinkronizált Passkey-eket használnak, és egy eszköz elveszik, helyreállítási vagy reset folyamatokat kell bevezetni. Amint fallback hitelesítés válik elérhetővé, az email-alapú recovery, jelszavak vagy más, kevésbé biztonságos módszerek visszakúsznak a szervezetbe. Ennek eredményeként a Passkey-ek teljes biztonsági előnye jelentősen csökkenhet, még akkor is, ha a használhatóság javul.

A szinkronizáció-alapú recovery egyszerűsíti a felhasználói élményt, de a bizalmat a szinkronizációs szolgáltatóra helyezi át, ami alapos threat modelinget, valamint megerősített recovery és account recovery folyamatokat igényel.

Legacy platformok és endpointok nehezítik a bevezetést

Az operációs rendszerek és böngészők eltérő Passkey viselkedést, kontrollokat és API-kat biztosítanak. Legacy alkalmazások és nem modern kliensek gyakran fallback hitelesítési módszereket igényelnek, ami növeli a hitelesítés komplexitását.

A szinkronizációs szolgáltatások gyakran nem rendelkeznek enterprise szintű láthatósággal. Az adminisztrátorok korlátozott betekintéssel rendelkezhetnek arra vonatkozóan, hol vannak a hitelesítő adatok tárolva, vagy melyik eszköz végzett egy adott hitelesítést. Ez megnehezíti az incident response-t és a forenzikus elemzést, hacsak nem áll rendelkezésre attested hardware, erős device identity vagy integrált enterprise tooling.

A Passkey regisztrációs és hitelesítési folyamatokat a böngésző közvetíti. Rosszindulatú böngésző bővítmények, injektált szkriptek vagy böngésző sebezhetőségek beavatkozhatnak a WebAuthn interakciókba, megtévesztő felhasználói promptokat jeleníthetnek meg, vagy továbbíthatják a hitelesítési műveleteket. Hatékony védekezéshez böngésző hardeningre, erős EDR-re és szabályzat-kikényszerítésre van szükség a meglévő biztonsági kontrollok mellett.

Enterprise biztonsági nézőpont

Mindezek komoly kihívást jelentenek a Passkey-ek enterprise környezetben történő bevezetésekor, mivel a hitelesítési és recovery folyamatokat alkalmazás, megfelelőség, endpoint, eszköz és workflow szempontból is vizsgálni kell. Az új folyamatokkal együtt új support és account recovery playbookok, valamint új potenciális támadási módszerek és jelek is bekerülnek a security stack-be.

Mi a helyzet a webes / SaaS környezettel?

Fontos megjegyezni, hogy jelenleg csak néhány száz SaaS szolgáltatás támogatja teljes körűen a Passkey-eket, és a fentiekből is látható, hogy a Passkey tárolási és szinkronizációs módok kulcsfontosságúak a felhasználói viselkedés és kockázatok megértésében.

Az alábbiakban a lehetséges kockázati tényezők és megoldások bontása látható.

Apple iCloud Keychain

Kontrollmodell: Privát fiók (Apple ID)
Szinkronizáció / mobilitás: Automatikus, több eszköz közötti szinkron
Fő kockázati tényezők: Apple ID takeover, felhasználói szintű recovery folyamatok, korlátozott enterprise láthatóság
Enterprise biztonsági értékelés: Medium — erős kriptográfia, gyengébb enterprise irányítás

Google Password Manager

Kontrollmodell: Privát fiók többnyire(Google Account)
Szinkronizáció / mobilitás: Automatikus, több eszköz közötti szinkron
Fő kockázati tényezők: Account recovery visszaélések, phishing, korlátozott szervezeti kontroll
Enterprise biztonsági értékelés: Medium — a biztonság nagymértékben a Google fiók védelmétől függ

Windows Hello (TPM-backed)

Kontrollmodell: Lokális, hardverhez kötött
Szinkronizáció / mobilitás: Csak helyi használat (kivéve, ha az Edge sync engedélyezett)
Fő kockázati tényezők: Eszköz elvesztése, korlátozott hordozhatóság
Enterprise biztonsági értékelés: Very High — a legerősebb lokális védelem, minimális felhős kitettség

Microsoft Edge Passkey Sync

Kontrollmodell: Felhős fiók(Microsoft Account vagy Entra ID)
Szinkronizáció / mobilitás: Opcionális, több eszköz közötti szinkron
Fő kockázati tényezők: Cloud identity kompromittálódása, policy hibák
Enterprise biztonsági értékelés: High — különösen Entra ID és Conditional Access használata esetén

Third-Party Password Manager (Privát)

Kontrollmodell: Vendor által menedzselt vault
Szinkronizáció / mobilitás: Cross-platform
Fő kockázati tényezők: Master password kompromittálódása, phishing, vendor breach
Enterprise biztonsági értékelés: Medium — jelentős eltérések vannak vendor és felhasználói gyakorlatok szerint

Third-Party Password Manager (Enterprise )

Kontrollmodell: Szervezet által menedzselt vault, policy enforcementtel
Szinkronizáció / mobilitás: Cross-platform
Fő kockázati tényezők: Adminisztratív hibák, insider threat
Enterprise biztonsági értékelés: High–Very High — SSO, MFA, device trust és auditálás mellett

Hardware Security Key (FIDO2)

Kontrollmodell: Fizikai birtoklás
Szinkronizáció / mobilitás: Csak fizikai használat
Fő kockázati tényezők: Elvesztés, korlátozott backup és recovery lehetőségek
Enterprise biztonsági értékelés: Very High — a legalacsonyabb távoli támadási felület

Következtetés

A Passkey-ek valódi előrelépést jelentenek a hitelesítésben, de biztonsági tulajdonságaik nagymértékben függenek attól, hogyan történik a tárolásuk, szinkronizációjuk és helyreállításuk. Azoknak a szervezeteknek, amelyek a Passkey-ek bevezetését mérlegelik, a kérdés nem az, hogy a Passkey-ek elméletben „biztonságosabbak-e” a jelszavaknál, hanem az, hogy egy adott megvalósítás mennyire illeszkedik az enterprise kontroll-, láthatósági- és kockázatkezelési elvárásokhoz.

A legnagyobb kockázat azonban a láthatóság hiánya ezeknél a fiókoknál, hasonlóan a jelszóalapú bejelentkezésekhez. A Passkey-alapú bejelentkezések teljes körű feltérképezéséhez érdemes megfontolni a Scirge böngésző bővítmény használatát, amely minden böngészőből indított bejelentkezést összegyűjt, beleértve a jelszavas, SSO és Passkey alapú fiókokat is.

‍