La teva passkey no es trenca: es copia la clau mestra

El 3 d'agost, Unit 42 va publicar tres maneres d'entrar en comptes protegits amb passkey sense trencar ni una sola línia de criptografia. Cap no necessita permisos d'administrador. La primera no demana empremta, ni PIN, ni fa aparèixer res a la pantalla; les altres dues entren pel reenrolament del dispositiu, de manera que l'usuari veu la pantalla de sempre demanant-li el PIN de recuperació de Google, el tecleja sense sospitar res i la feina bruta passa al darrere. I totes comencen al mateix lloc: un Windows on ja s'executa un programa maliciós. L'important, a la primera frase, perquè ningú no s'endugui la idea equivocada: continuem recomanant passkeys. El que ha caigut no és la tecnologia, és una frase de màrqueting.

Les tres portes, en ordre

El treball es diu Pass the Passkey i apunta a un lloc molt concret: l'autenticador al núvol del gestor de contrasenyes de Google dins del Chrome, en Windows amb TPM. No hi ha cap CVE assignat. Hi ha tres tècniques, i convé entendre-les per separat perquè no donen el mateix.

• Pass-ta-key. El malware es fa passar pel dispositiu de confiança fent servir la clau d'identitat que el Chrome té protegida pel TPM, i demana una resposta d'autenticació. El detall que decideix si funciona o no és un sol bit: l'asserció va amb la marca d'«usuari verificat» sense activar. Contra un servei que comprova aquest bit, no serveix. Contra un que no el comprova, sí —i l'exemple publicat és eBay, que les acceptava fins que li ho van comunicar, mentre que GitHub ja el validava.
• Silver Pass-ta-key. Puja un esglaó: força un reenrolament del dispositiu i, durant aquella finestra de recuperació, registra una clau de verificació d'usuari de l'atacant. La palanca és d'una senzillesa incòmoda: n'hi ha prou amb esborrar el fitxer d'estat local de l'enclavament, i els investigadors anoten que «no hi ha cap protecció incorporada que n'impedeixi l'eliminació». A partir d'aquí el bit d'«usuari verificat» ve activat de debò, així que comprovar-lo ja no salva: l'asserció és legítima, només que qui la signa no ets tu.
• Golden Pass-ta-key. La greu. Durant aquest mateix reenrolament, el secret del domini de seguretat —32 bytes, la clau que xifra totes les passkeys sincronitzades del compte— passa breument en clar per la memòria del procés del Chrome, i d'allà se n'extreu. Amb aquests 32 bytes es desxifren les claus privades de totes les passkeys sincronitzades, no la d'un lloc. I una frase dels investigadors que convé no llegir per sobre: «en la implementació actual de Google no hi ha manera de rotar ni revocar el secret, cosa que vol dir que totes les passkeys sincronitzades, actuals i futures, continuen protegides per la mateixa clau mestra».

Google va retirar aquest secret de la sortida de registre de FIDO després de l'avís dels investigadors. La frase que tanca aquest punt a la recerca és la que cal llegir a poc a poc: «el secret es continua enviant al client i continua sent accessible a la memòria del procés del Chrome». És a dir: es va arreglar que quedés escrit en un registre; no es va arreglar que hi sigui.

Una clau mestra de 32 bytes

Pensa en una sala de caixes de seguretat. Cada caixa té el seu pany, diferent de tots els altres i impossible de forçar amb la clau de la caixa del costat: això és exactament una passkey, un parell de claus únic per lloc que no val enlloc més. Però com que el client vol poder obrir la seva caixa des de qualsevol oficina de l'entitat, algú va decidir que existís una clau que les obre totes i que viatja amb ell. Aquesta clau és la comoditat. I aquesta clau són els 32 bytes.

Això no és un descuit de ningú: és el preu de la sincronització, i estava damunt la taula des del principi. Voler les passkeys al mòbil, al portàtil i a l'ordinador de casa obliga que existeixi un secret recuperable en algun lloc; si no existís, canviar de telèfon voldria dir perdre tots els comptes. El que ha fet aquesta recerca no és descobrir la clau mestra, és ensenyar que la tenim a tocar del terra: a l'abast d'un procés que s'executa amb l'usuari normal de Windows, sense més privilegis que els seus.

El que això NO és

Toca la part avorrida, que és la que evita decisions dolentes. Això no trenca WebAuthn ni FIDO2. No hi ha cap fallada matemàtica, cap clau privada endevinada, cap algorisme caigut. No n'hi ha prou amb visitar un web. No hi ha descrita cap campanya criminal fent-ho servir. I tot parteix d'una màquina que ja està perduda: els mateixos investigadors ho resumeixen dient que «tots els atacs presentats depenen que ja hi hagi malware al dispositiu de la víctima».

El matís que juga en contra del titular fàcil també és veritat: si tens un programa maliciós llegint la memòria del navegador, tenies un problema greu abans del 3 d'agost. Les galetes de sessió ja es robaven així, i amb una galeta de sessió vàlida tampoc no cal autenticar-se. Això no obre la bretxa. El que fa és ampliar el botí: on abans s'enduien les sessions obertes d'aquell equip, ara es poden endur les claus de tots els comptes sincronitzats, també els que no havies obert en aquell portàtil.

Per què importa igualment

Importa perquè la posició de partida que aquestes tres tècniques donen per suposada —un Windows amb malware executant-se com a usuari normal— no és una hipòtesi de laboratori: és un producte. Els números que publica SpyCloud sobre el 2025 descriuen aquesta indústria: 13,2 milions d'infeccions de programes lladres de credencials, 642,4 milions de credencials recuperades d'aquestes infeccions i 8.600 milions de galetes i artefactes de sessió recuperats de fonts criminals. Aquest últim número és el que importa aquí, perquè són exactament el mateix tipus de secret: material que es roba de la màquina, no de la persona.

Fa dos dies escrivíem sobre el token que no torna a demanar MFA. Allà el problema era a qui havies donat permís; aquí és on viu la prova que ets tu. La pregunta és diferent i el punt cec és el mateix, però l'escala no: una galeta robada et dona una sessió d'un servei, i aquests 32 bytes et donen la caixa sencera.

I tot i així: passkeys sí

Ens hi mullem, perquè un post que només fa por no serveix de res. Una passkey continua sent millor que qualsevol cosa que hi hagués abans, i per un motiu que aquesta recerca no toca: està lligada al domini. No es pot escriure en un web fals, no es pot dictar per telèfon, no es pot reenviar a ningú per WhatsApp. El phishing i l'enginyeria social es queden sense objecte. Per això Microsoft està retirant l'SMS com a segon factor i empenyent exactament cap aquí, i per això nosaltres les continuem recomanant.

El que cau no és la decisió: és l'afegitó que l'acompanyava. «Amb passkeys ja no cal preocupar-se del lloc de treball» mai no va formar part del tracte, encara que s'hagi repetit en moltes presentacions —incloses algunes on sèiem nosaltres. Substituir la contrasenya resol el robatori de la contrasenya. No resol el robatori del lloc on deses el que la substitueix.

Cinc coses que sí que es poden fer aquesta setmana

• Si publiques un servei amb WebAuthn, comprova el bit que torna. La recomanació dels investigadors és literal: posar userVerification a required i verificar la marca d'usuari verificat que retorna l'asserció, en comptes de refiar-se del que vas demanar en fer la petició. És un parell de línies al servidor i és el que separa eBay de GitHub en aquesta història.
• Decideix on viuen les passkeys de l'empresa. Una passkey d'un compte corporatiu sincronitzada al perfil personal del Chrome d'un empleat no està sota control de l'empresa: no s'audita, no es revoca des de cap tauler i no es queda al portàtil el dia que la persona se'n va. Això no és un problema tècnic nou, és de govern, i és el mateix que ja tenies amb les contrasenyes desades al navegador.
• Alerta sobre les altes, no només sobre els inicis de sessió. Dues de les tres tècniques passen per un reenrolament del dispositiu. Un dispositiu nou donat d'alta en un compte hauria de generar un avís com a mínim tan visible com un inici de sessió des d'un altre país. A la majoria de llocs, avui, no el genera —i no és una idea nostra: la sisena recomanació de la recerca és exactament aquesta, millorar la detecció d'ús anòmal de passkeys.
• Assumeix que netejar l'equip no tanca el cas. Aquest és el punt que més costa de pair: en la implementació actual de Google no hi ha manera de rotar ni revocar aquest secret —ho diuen els investigadors amb aquestes paraules—, així que crear una passkey nova no tanca el forat, perquè neix protegida per la mateixa clau mestra. Un equip que ha tingut un lladre de credencials obliga a tractar les passkeys sincronitzades d'aquell compte com a compromeses i a resoldre-ho al compte, no al portàtil. Formatar el portàtil és la part fàcil.
• Posa la detecció on passa l'atac. Cap d'aquestes tres tècniques no es veu des del portal d'identitat: no hi ha inici de sessió estrany, no hi ha país impossible, no hi ha repte d'MFA fallit. L'única capa que mira al lloc correcte és la que corre dins de l'equip. És la mateixa conclusió a què vam arribar amb l'agent de gestió d'un proveïdor: quan l'atac fa servir mecanismes legítims, el senyal no és al registre central, és a la màquina. El que no val com a resposta és tornar a la contrasenya amb SMS: seria canviar un risc que necessita malware al teu equip per un altre que només necessita una trucada de telèfon ben feta.

La baula s'ha mogut, no ha desaparegut

Durant vint anys la baula feble de la identitat va ser la contrasenya, i tota la indústria —nosaltres inclosos— va construir al voltant d'aquesta idea: polítiques de complexitat, gestors, caducitats, segons factors. Les passkeys s'emporten aquest problema per davant, i està molt bé. El que no s'emporten és la necessitat que algú miri l'equip des del qual treballa la persona, amb el seu navegador, les seves extensions, les seves descàrregues i el seu usuari amb pressa.

Per això la pregunta que separa una política d'identitat seriosa d'una diapositiva no és «ja tenim passkeys?». És «si demà un portàtil nostre s'emporta un lladre de credencials, quants comptes donem per compromesos i en quant de temps ho resolem?». Si la resposta és «cap, tenim passkeys», ja saps què cal revisar.

Fonts (verificades): recerca Pass the Passkey: A Novel Attack Surface in Passwordless Authentication, d'Unit 42 (Palo Alto Networks), 03-08-2026 — noms de les tres tècniques; abast («Google Password Manager al Chrome sobre Windows, en dispositius equipats amb TPM»); requisits (sense escalada de privilegis, sense desbloqueig del dispositiu i sense interacció de l'usuari a la primera tècnica; les altres dues passen pel reenrolament, durant el qual el Chrome demana a l'usuari el PIN de recuperació del gestor); la marca d'usuari verificat sense activar i el cas d'eBay —«després del nostre informe, eBay va corregir aquesta bretxa de verificació i ara valida correctament la marca d'UV»— davant de GitHub; l'esborrat del fitxer d'estat de l'enclavament, «sense proteccions incorporades que n'impedeixin l'eliminació»; el secret del domini de seguretat de 32 bytes extret de la memòria del procés del Chrome; «en la implementació actual de Google no hi ha manera de rotar ni revocar el secret…»; «tots els atacs presentats depenen que ja hi hagi malware al dispositiu de la víctima»; la retirada del secret de la sortida de registre de FIDO per part de Google amb la precisió que «el secret es continua enviant al client i continua sent accessible a la memòria del procés del Chrome»; i les sis recomanacions, inclosa la de millorar la detecció d'ús anòmal de passkeys (cites traduïdes per nosaltres de l'original en anglès). L'absència de CVE assignat i l'enquadrament com a tècniques de post-compromís, a la cobertura de The Hacker News, 03-08-2026 i BleepingComputer, 03-08-2026. Xifres del 2025 (13,2 milions d'infeccions de programes lladres de credencials, 642,4 milions de credencials recuperades d'aquestes infeccions i 8.600 milions de galetes i artefactes de sessió recuperats de fonts criminals): SpyCloud, 2026 Identity Exposure Report. El criteri, la lectura del cas i les opinions són nostres.