Passkeys e multi-accounting nel 2026: come non collegare gli account con le chiavi di accesso

Come è strutturata la passkey e perché rompe l'isolamento dei profili

La passkey è una coppia di chiavi crittografiche. La chiave pubblica è memorizzata dal sito, la chiave privata è conservata dall'"autenticatore". La chiave è legata al dominio (nella specifica è rpId), quindi il sito di phishing non la riceverà. La principale questione per il multi-accounting è dove si trova fisicamente la chiave privata. L'anti-detect isola i cookies, localStorage, IndexedDB e l'impronta. L'archivio delle chiavi si trova spesso fuori dal profilo del browser:

• Windows Hello memorizza le chiavi a livello dell'account Windows. Qualsiasi browser e qualsiasi profilo sotto questo account accede allo stesso archivio.
• Il legame delle chiavi iCloud su macOS appartiene all'Apple ID. Chrome e Safari su un Mac vedono lo stesso set di chiavi.
• Il gestore password di Google è legato all'account Google con cui è connesso il browser o il telefono. Un account Google di servizio su venti profili è un'unica cassaforte condivisa.
• Le estensioni-gestori (Bitwarden, 1Password e altri) memorizzano le chiavi nell'archivio del proprio account. Un'unica cassaforte per tutti i profili funziona come un unico punto, attraverso il quale si vede tutto.

Da qui il tipico errore. Clicchi su "Accedi con la chiave di accesso" nel profilo dell'account n. 7, e il sistema mostra le chiavi degli account n. 3 e n. 12 sullo stesso sito. Il sito non vede questa lista: riceve solo la chiave selezionata. Ma un clic errato — e l'account n. 3 accede dal profilo, IP e impronta dell'account n. 7. Tale collegamento non può più essere annullato.

Cosa sa realmente il sito quando si accede con la passkey

La passkey non annulla il rischio di scoring, sostituisce semplicemente la password. Quando ci si accede, la piattaforma vede ancora l'IP, l'impronta del browser e la cronologia delle sessioni. Inoltre riceve alcuni segnali propri di WebAuthn:

• Identificatore della chiave (credential ID). È unico per la coppia "account — autenticatore".
• AAGUID — identificatore del modello di autenticatore. Attraverso di esso, siti come Google firmano la chiave nelle impostazioni dell'account: "creato in iCloud Keychain", "nel gestore password di Google" e così via. Non è un numero unico del tuo dispositivo, ma è un'altra caratteristica che deve corrispondere alla leggenda del profilo.
• Flag BE e BS (backup eligibility e backup state) indicano se questa chiave è sincronizzabile o legata al dispositivo.

Conclusione: un profilo "mobile" che accede con una chiave da Windows Hello appare altrettanto illogico quanto un iPhone con il fuso orario del Brasile e IP dalla Germania. La chiave deve corrispondere alla stessa leggenda di proxy e impronta.

Schema passo-passo: un account — un profilo — un archivio — un IP

1. Fai un inventario. Elenca le piattaforme dove i tuoi account hanno già passkey o è comparsa l'offerta di crearle: Google, Microsoft, grandi marketplace e social network. Nelle impostazioni di sicurezza di ogni account puoi vedere quante chiavi sono registrate e dove sono state create. Tutte le registrazioni inaspettate "Windows Hello" e "iCloud Keychain" sono candidati per la rimozione.
2. Disabilita l'archiviazione delle chiavi di sistema per i profili di lavoro. Nel browser in cui operano i profili, disattiva il salvataggio di password e chiavi di accesso nel gestore integrato. Non creare chiavi in Windows Hello o nel legame iCloud su un computer di lavoro. Se la finestra di creazione della chiave offre "questo computer", scegli un altro metodo.
3. Scegli un archivio per ogni account. La regola è semplice: l'archivio deve essere separato proprio come i profili. Opzioni:
   • archivio separato del gestore password per account o per gruppo di account di un unico cliente;
   • chiave hardware (FIDO2) per i pochi account più preziosi;
   • per l'automazione — autenticatore software, di cui parleremo nel passo 6.
   Un'unica cassaforte per tutti — il modo più comune per collegare gli account tra loro.
4. Registra la chiave solo dal profilo "nativo". Stesso profilo, stessa impronta, stesso proxy con sessione fissata, stesso geo, come durante il normale utilizzo dell'account. La registrazione della chiave è un'azione sensibile, e le piattaforme la osservano attentamente. Cambiare IP nel mezzo della procedura porta spesso a un controllo aggiuntivo. Come mantenere un indirizzo per profilo, abbiamo esaminato in dettaglio nell'articolo sticky-session o rotazione per il profilo anti-detect.
5. Lascia un accesso di riserva. Un archivio mancante significa un account perso. Per ogni account è necessario un secondo metodo di accesso: una seconda passkey in un altro archivio, una password con TOTP o codici di recupero, che sono conservati separatamente dalla chiave. Microsoft in Entra richiede esplicitamente di trasferire gli utenti a metodi resistenti al phishing entro febbraio 2027. Non aspettare che la finestra di registrazione smetta di chiudersi.
6. Nell'automazione utilizza un autenticatore virtuale. Nel Chrome DevTools Protocol esiste il dominio WebAuthn. Il metodo addVirtualAuthenticator crea un autenticatore software con protocollo ctap2 e trasporto internal (di piattaforma) o usb/hybrid. I parametri hasResidentKey e hasUserVerification includono la memorizzazione della chiave sull'autenticatore e la verifica dell'utente. getCredentials dopo la registrazione restituisce la chiave interamente: credentialId, rpId, userHandle, signCount e chiave privata in formato PKCS#8. addCredential al successivo avvio la reinserisce. Si ottiene una chiave che vive solo nel tuo archivio segreto e si collega alla sessione di un account specifico. Due avvertenze: il dominio è contrassegnato come sperimentale e creato per testare WebAuthn, e la chiave privata esportata è un segreto di livello password, e deve essere conservata di conseguenza.
7. Trasferisci le chiavi tramite Credential Exchange, non manualmente. Se cambi gestore o distribuisci gli account in diversi archivi, utilizza l'esportazione integrata secondo lo standard FIDO: è supportata in Apple Passwords, 1Password, Bitwarden, Dashlane, DuckDuckGo, Devolutions. Tieni presente che su macOS alcune applicazioni non hanno ancora implementato questo meccanismo.

Insidie

• Sincronizzazione per impostazione predefinita. Una chiave creata "su questo dispositivo" può immediatamente andare nel cloud di iCloud o Google e apparire su tutti i dispositivi di quell'account, incluso il tuo telefono personale.
• Accesso cross-device tramite QR. Lo scenario "scansiona il QR con il telefono" (trasporto ibrido) collega alla sessione del profilo un telefono reale con le proprie chiavi. Per i profili di lavoro, questo rappresenta un collegamento superfluo.
• Identico AAGUID per l'intera fattoria — è normale. Milioni di persone utilizzano lo stesso gestore. Non è pericoloso avere lo stesso fornitore, ma una chiave comune o un archivio comune.
• La passkey non risolve l'accesso "sporco". Se un account accede con un IP che è già apparso su account vicini, o da un data center che la piattaforma non gradisce, una forte crittografia non aiuterà. Il rischio è valutato sulla base di un insieme di segnali.
• Il secondo fattore deve essere isolato. Se l'accesso di riserva è TOTP, i segreti sono distribuiti anche tra gli account, e non sono conservati in un'unica applicazione sul telefono personale. Come collegare 2FA e proxy, ne abbiamo discusso nel materiale sulla autenticazione a due fattori nel lavoro tramite proxy.

Quale proxy è necessario e perché

Per accedere con la chiave, la cosa più importante è la costanza: l'account deve registrare la chiave e poi accedervi dalla stessa rete, nello stesso geo. Pertanto:

• Profili web in anti-detect — proxy residenziali con sessione fissata nel paese dell'account. Questi sono indirizzi di provider domestici, e corrispondono alla leggenda "utente normale a casa".
• Piattaforme mobili e account con leggenda mobile — proxy mobili. Un profilo mobile che registra una chiave da una rete domestica dall'altra parte del paese si discosta dalla sua storia.
• Rotazione ad ogni richiesta è adatta per il parsing, ma non per accedere agli account. Imposta un intervallo con margine per l'intera sessione di lavoro.

Conclusione

Le passkey rendono l'accesso resistente al phishing, ma spostano il punto di collegamento tra gli account da cookies e password all'archivio delle chiavi. Questo punto si trova spesso al di fuori del profilo anti-detect: in Windows Hello, iCloud, account Google o archivio comune del gestore. Lo schema di lavoro appare così: ogni account ha il proprio profilo, il proprio archivio chiave, il proprio IP fisso e un metodo di accesso di riserva. Per l'automazione, esiste un autenticatore virtuale nel CDP. Occupati di questo entro febbraio 2027, quando Microsoft smetterà di consentire di posticipare la registrazione. Dopo dovrai affrontare la situazione in fretta e direttamente su account attivi.