Discussione Passkeys: l'inizio della fine delle password?

[0xbro]

Google ha iniziato a distribuire ai propri utenti la possibilità di accedere ai loro account tramite l'utilizzo di "passkeys" anziché delle tradizionali password. Si tratta del passo definitivo verso un mondo password-less?

Passkeys: l'inizio della fine delle password?​

Tempo di lettura stimato: 5 min

---

In questi ultimi giorni Google ha annunciato il deploy della nuova funzionalità di login che introduce l'utilizzo delle passkeys al posto delle tradizionali passwords. La funzionalità non è una novità, era già stata in parte annunciata un anno fa quando, insieme ad Apple, Microsoft e la FIDO Alliance, era stata annunciata l'intenzione di muoversi verso un futuro in cui le password sarebbero state rimpiazzate in qualche modo.

Tra le prime società a distribuire questa funzionalità è stata Microsoft, che da diversi mesi permette ai propri utenti di accedere alle varie applicazioni di Office365 tramite l'invio di notifiche e rispettiva autenticazione biometrica, escludendo quindi password e pass-phrases dal processo.

A questo giro il passo in avanti l'ha fatto Google, abilitando l'autenticazione tramite passkeys per i propri utenti. Questo nuovo metodo di autenticazione è attivabile al link g.co/passkeys - ma non è al momento obbligatorio. I vecchi metodi di autenticazione, infatti, resteranno attivi ancora per almeno un anno, se non di più.
​

​

Cosa sono nel dettaglio queste "Passkeys"?​

Le passkeys sono, per dirla in maniera molto semplice, delle chiavi "trasparenti" agli occhi dell''utente, che client e server si scambiano con lo scopo di verificare e autenticare chi stia facendo l'accesso. Queste chiavi funzionano solamente se accoppiate univocamente tra loro, e sfruttano una logica di chiave pubblica e privata in cui una chiave resta segretamente custodita sul device che deve autenticarsi (chiave privata) mentre la chiave gemella (chiave pubblica) è custodita sul server predisposto per l'autenticazione.

Come detto sopra, le passkeys sono memorizzate sul proprio computer o dispositivo mobile, il quale richiederà i dati biometrici o un PIN di sblocco per confermare che si tratti proprio di voi. (NB: "I dati biometrici non vengono mai condivisi con Google o con terzi: il blocco schermo sblocca solo la chiave di accesso a livello locale.", Google Security Blog).

A differenza delle password, le passkey esistono solo sui vostri dispositivi fisici. Non possono essere scritte o consegnate accidentalmente a un malintenzionato. Quando si utilizza una chiave per accedere al proprio account Google, si dimostra a Google che si ha accesso al proprio dispositivo e si è in grado di sbloccarlo. In questo modo si è immuni ad attacchi di phishing o a pratiche poco consone come il ri-utilizzo delle stesse credenziali o, peggio, la condivisione con altre persone.
​

​

Come funzionano nel dettaglio?​

La passkey utilizza come ingrediente principale una chiave privata crittografica, la quale viene salvata sui dispositivi dell'utente. Durante la creazione di una passkey, la chiave pubblica associata viene invece caricata su Google. Quando si accede, il dispositivo viene sollecitato a firmare una challenge univoca con la chiave privata, ma ciò avviene solo previa approvazione dell'utente, tramite lo sblocco del dispositivo. Infine, la firma viene verificata tramite la chiave pubblica dell'utente.

Quando si necessita di utilizzare una passkey dal telefono per accedere ad un altro dispositivo, il procedimento inizia tipicamente con la scansione del codice QR visualizzato dal dispositivo. Successivamente, il dispositivo verifica la vicinanza del telefono tramite un breve messaggio Bluetooth anonimo e, tramite Internet, stabilisce una connessione crittografata end-to-end con esso. La connessione viene utilizzata dal telefono per fornire la firma della passkey una sola volta, la quale richiede l'approvazione dell'utente e l'identificazione biometrica o lo sblocco dello schermo del telefono. La verifica di prossimità fatta col Bluetooth impedisce che eventuali aggressori possano ingannare l'utente inducendolo a fornire la firma della chiave d'accesso, ad esempio, mostrando una schermata con un codice QR proveniente dal proprio dispositivo remoto.

Maggiori dettagli potete leggerli nel blogpost ufficiale di Google: So long passwords, thanks for all the phish (titolo che fa riferimento al romanzo "Guida galattica per gli autostoppisti").
​

Che sia la svolta definitiva?​

Prima Microsoft, poi Apple e infine Google. Tutti verso un nuovo futuro password-less. Secondo voi, quest'ultimo passo fatto da Big G, rappresenterà l'ultimo atto prima di una svolta totale verso questa nuova visione dei processi di autenticazione?

Ma soprattutto, gli utenti passeranno di loro spontanea volontà all'utilizzo di questo nuovo meccanismo, oppure dovranno essere "costretti con le cattive" maniere, come del resto per la maggior parte degli aggiornamenti?

Voi avete già adottato o adotterete in futuro questo nuovo meccanismo di protezione per i vostri account?
​

Ulteriori risorse​

• One step closer to a passwordless future, Google Blog​
• The beginning of the end of the password, Google Blog​
• So long passwords, thanks for all the phish, Google security Blog​
• Passwordless login with passkeys, Google Developer Documentation​
• You no longer need a password to sign in to your Google account, The Verge​
• Passwordless sign-in with passkeys is now available for Google accounts, Security Affairs​

---

Made with ❤ for Inforge​

---

 

[--- Ra ---]

Grazie della guida @0xbro! Scrivi sempre degli ottimi articoli: chiari e concisi. A livello di praticità sono molto comode queste keypass. In fin dei conti esse sfruttano il classico meccanismo di crittografia chiave privata-pubblica, però la chiave privata è protetta dall'accesso con credenziali biometriche. Rimango solo un po' perplesso del fatto che si possa usare un PIN per proteggere la chiave privata: non la vedo sicurissima come cosa perché un PIN, almeno quello minimale di 4 cifre, può essere trovato abbastanza facilmente da un bruteforce (ma sicuramente Google avrà implementato un controllo dei tentativi di accesso). Tutto il resto mi pare molto più veloce della password "tradizionale". Penso che a breve proverò le keypass, anche se mi dispiace abbandonare il mio caro password-manager Bitwarden.

 

[ElectricDreamer]

Sinceramente non ho capito in che modo possa avvenire il backup della passkey mantenendo allo stesso tempo privato ed in locale il tutto. Probabilmente caricando la chiave privata protetta dal PIN nel cloud Google, quindi spero che si possa disattivare, altrimenti non ha molto senso

 

[0xbro]

Rimango solo un po' perplesso del fatto che si possa usare un PIN per proteggere la chiave privata: non la vedo sicurissima come cosa perché un PIN, almeno quello minimale di 4 cifre, può essere trovato abbastanza facilmente da un bruteforce

Guarda, sono totalmente d'accordo e anche un po' perplesso, più che altro perchè anche Microsoft aveva fatto una cosa simile. Non ho ancora capito se il PIN sia necessario solamente per accedere al "vault" in cui è salvata la chiave o se effettivamente venga usato in qualche modo per decifrarla, ma ricordo che quando Microsoft rilasciò la funzionalità io impostai un PIN numerico di 6/8 cifre e non mi fece storie. Dopo qualche mese poi mi costrinsero a cambiarlo.

Sinceramente non ho capito in che modo possa avvenire il backup della passkey mantenendo allo stesso tempo privato ed in locale il tutto. Probabilmente caricando la chiave privata protetta dal PIN nel cloud Google, quindi spero che si possa disattivare, altrimenti non ha molto senso

Me lo sono chiesto anche io, ed effettivamente sul blogpost ufficiale è spiegato davvero male. Sinceramente una funzionalità del genere mi sembra proprio concettualmente sbagliata... perchè trasmettere in giro e condividere una cosa che deve restare segreta? Non avrebbe più senso che ogni dispositivo abbia la propria coppia di chiavi?

EDIT: mentre scrivevo il commento ho riletto un attimo con più attenzione ed effettivamente sul blog dicono che ogni dispositivo può avere la propria chiave e che è possibile fare il backup delle chiavi esistenti con servizi come iCloud (però credo che si intenda solamente per evitare di rimanere bloccati fuori, un po' come si fa con le chiavi SSH):

Using passkeys does not mean that you have to use your phone every time you sign in. If you use multiple devices, e.g. a laptop, a PC or a tablet, you can create a passkey for each one. In addition, some platforms securely back your passkeys up and sync them to other devices you own. For example, if you create a passkey on your iPhone, that passkey will also be available on your other Apple devices if they are signed in to the same iCloud account. This protects you from being locked out of your account in case you lose your devices, and makes it easier for you to upgrade from one device to another.
...
The private key behind the passkey lives on your devices and in some cases, it stays only on the device it was created on. In other cases, your operating system or an app similar to a password manager may sync it to other devices you own. Passkey sync providers like the Google Password Manager and iCloud Keychain use end-to-end encryption to keep your passkeys private.

Però boh, così a caldo non so cosa pensare, nei prossimi giorni sicuramente usciranno fuori (se mai ci saranno), eventuali criticità

 

[--- Ra ---]

Per quanto riguarda la sincronizzazione c'è scritto esplicitamente che si possono collegare più dispositivi allo stesso account e, di conseguenza, usare la stessa keypass. Oppure si possono creare più passkey per ogni dispositivo. Nel primo caso mi pare ovvio che sia necessario per Google utilizzare dei server per il trasferimento della chiave privata da un dispositivo ad un altro.

Per quanto concerne i backup la situazione è sempre più o meno la stessa, come diceva il buon @ElectricDreamer, le chiavi private vanno sempre a finire sui server Google, ma crittografate e la chiave per la decrittazione rimane solo sul dispositivo dell'utente, quindi Google non può accedervi in alcun modo. Questa è la conferma:

"Passkeys in the Google Password Manager are always end-to-end encrypted: When a passkey is backed up, its private key is uploaded only in its encrypted form using an encryption key that is only accessible on the user's own devices. This protects passkeys against Google itself, or e.g. a malicious attacker inside Google. Without access to the private key, such an attacker cannot use the passkey to sign in to its corresponding online account."

Conferma che potete trovare qui: https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html?m=1

 

[TheWorm91]

Se non ho capito male praticamente funziona in maniera inversa al processo di firma digitale di un documento (chi firma appone la chiave privata per dimostrare la propria identità), oppure in maniera simile alla crittografia sempre di un documento sempre tramite le chiavi pubbliche e private

 

[--- Ra ---]

oppure in maniera simile alla crittografia sempre di un documento sempre tramite le chiavi pubbliche e private

Esatto, funziona sfruttando alcuni meccanismi della crittografia a chiave pubblica, ossia l'utilizzo di chiave privata e pubblica.

 

[St3ve]

Non ne so un granché sull'argomento quindi non ho ancora forti opinioni a riguardo, però a primo impatto mi sembra molto interessante e credo davvero che potrebbe essere l'inizio della fine delle password. Il target primario è la tipica persona non-esperta che usa password deboli ed è facilmante raggirabile ma, tolti alcuni aspetti che ancora non mi convincono moltissimo, non fatico a credere che un meccanismo simile possa andare a rimpiazzare le password anche per gli utenti smanettoni che già prestano le dovute attenzioni alla sicurezza informatica. Sostanzialmente, mi pare di aver capito che "passkeys" sia un fancy name per FIDO2 / WebAuthn, che per capirci è lo stesso meccanismo che c'è dietro alle security keys (Yubikey, Solokey, Nitrokey, Onlykey, etc.) ma usato come single-factor authentication, perché il loro obiettivo è di rimpiazzare completamente le password in modo di diventare uno strumento pratico oltre che sicuro.

Tra i vantaggi principale c'è il fatto che se usi queste passkey al posto della password non sei più soggetto a phishing e a vari attacchi man-in-the-middle. L'autenticazione è regolata da un protocollo intergato nel browser, quindi non basta un sito falso con nome e grafica simile per ingannare un utente a inviare le credenziali perché URL e certificato SSL giocano un ruolo importante: se il browser non è stato compromesso, non c'è modo di fare phishing. Non funzionano nemmeno attacchi man-in-the-middle perché l'okay col telefono dev'essere dato a distanza bluetooth dal device che richiede l'accesso: se un truffatore, fingendosi un membro dell'assistenza tecnica, ti videochiama e ti convince a scansionare il suo codice QR e dare l'okay sul telefono, non riuscirà comunque ad completare l'accesso perché il suo computer è fisicamente troppo distante dal tuo telefono. Allo stesso modo via tutti gli attacchi di social engineering automatizzati del tipo "invia periodicamente notifiche di MFA requests, prima o poi l'utente non capirà cosa sta succedendo e ti da l'autorizzazione". Bruteforce, dictionary attack, MFA fatigue attack, MITM, credential stuffing e phishing sono alcuni degli attacchi più efficaci al giorno d'oggi e questa roba li mitiga completamente.

Bene per l'utente comune, però vabbé, diciamo che questo a noi interessa solo relativamente perché già usiamo password sicure, diverse per ogni sito e non ci facciamo fregare né dal sito scam e né dall'indiano che ti chiede ti chiede la password del tuo account bancario. In un certo senso il meccanismo dietro a FIDO interessa anche a noi perché il fatto che l'inserimento delle credenziali sia dettato da un protocollo va a mitigare anche i problemi dovuti a keylogging e clipboard stealing. Quindi, ammettendo che per dare l'autorizzazione usi una master password invece di dati biometrici, l'idea è quella di un "password manager" che si occupa di mantere chiavi invece di password. E se ti fregano la master password hai comunque il culo parato perché per effettuare l'accesso non basta something you know (la password) o something you are (i dati biometrici), ma dev'esserci anche un something you have (il device), che mitiga gli attacchi in remoto ed è a prova di "truffandomi, mi hai convinto a premere okay".

Adesso passiamo ai lati che, da ignorante, per adesso mi convincono un po' meno. Richiede supporto hardware, che sarebbe il famoso TPM che è stato antipatico a molta gente perché è nei requisiti minimi di Windows 11 e, per esempio, il mio computer non ha e quindi non ho ancora avuto modo di provare. L'idea di questo TPM è che le chiavi non escono mai da li, quindi in teoria ha senso, però in pratica io preferisco fare affidamento a soluzioni software (open source) piuttosto che a soluzioni hardware che potrebbero o non potrebbero contenere backdoors, sono impegnative aggiornare, lasciano poche scelte agli utenti e sono soggette a usura e danneggamenti. La soluzione più sicura è indubbiamente quella di tenersi tutto in locale, senza cloud sync, ma i fornitori di hardware FIDO compliant (e.g., Yubikey e le sopra citate) partono fin da subito a consigliarti di comprarne almeno due e di registrare ogni volta entrambe perché se ne hai solo una e disgraziatamente la perdi o ti si rompe, sei completamente tagliato fuori dai tutti i tuoi account, magari (e.g., wallet bitcoin) anche in modo irrecuperabile. Per farla breve, a me sembra che gli utenti poco avvezzi alla sicurezza informatica saranno meno suscettibili ad attacchi in remoto ma più fragili ad attacchi in locale, dove il parente o l'amico riesce ad avere accesso a tutti i tuoi account in un colpo solo. Gli utenti esperti, che continueranno ad usare una master password invece di dati biometrici, magari saranno più protetti verso i keyloggers a scapito di una maggiore difficoltà nel mantenere dei backup.

Io per adesso mi tengo strette le vecchie password, niente Yubikey et simili e niente passkeys. In futuro si vedrà... sicuramente c'è del potenziale.

Se non ho capito male praticamente funziona in maniera inversa al processo di firma digitale di un documento (chi firma appone la chiave privata per dimostrare la propria identità), oppure in maniera simile alla crittografia sempre di un documento sempre tramite le chiavi pubbliche e private

È proprio firma digitale. Supponiamo che vuoi fare accesso a inforge: quando ti registri invii ad inforge la tua chiave pubblica, quando vuoi fare login inforge ti invia una stringa random che tu dovrai firmare con la tua chiave privata (che non lascia mai il TPM) e rispedire indietro, poi inforge usa la tua chiave pubblica per verificare che sei veramente tu e che non hai firmato qualcosa di vecchio. Il tutto viene gestito da un protocollo implementato direttamente nel browser, quindi se il sito è lnforge.net o inforge.com invece di inforge.net e se non sarà in https non sarai tu a dover prestare attenzione. L'unico modo per fare "phishing" è attraverso un browser compromesso, collegandoti a un sito che si chiama veramente inforge.net e che ha un certificato SSL valido, ma che non è il vero inforge anche se ha l'aspetto del vero inforge; cioè, praticamente non possiamo più parlare di phishing.

P.S. Lo chiamo single-factor authentication anche se, per riportarmi all'esempio che presentano, devi dare l'okay con il telefono per fare accesso con il computer perché il presunto secondo fattore (i.e., il telefono) non raggiunge mai i server su cui stai facendo accesso. Per come la vedo io, il telefono è single-factor per il computer e il computer è single-factor per il server. Tecnicamente non sono sicuro se sia corretto chiamarla single-factor authentication o se conta comunque come multi-factor authentication, a me sembra un po' una via di mezzo.

 

[--- Ra ---]

per riportarmi all'esempio che presentano, devi dare l'okay con il telefono per fare accesso con il computer

Questo è vero, ma soltanto la prima volta che si registra un nuovo dispositivo. Dopodiché si potrà accedere senza conferma del cellulare, quindi, nel nostro esempio, direttamente da Computer, a patto di aver registrato la chiave privata sul nuovo dispositivo. Il concetto è che si possono creare più chiavi private per più dispositivi, ma si può anche sincronizzare su più dispositivi una singola chiave, attraverso una piattaforma come iCloud (tanto per fare un esempio).

P.s: fai bene a chiamarlo single-factor authentication perché alla fine la procedura di accesso si fa con un solo dispositivo, quindi sarebbe giusto chiamarla così, poi se la chiamano in modo diverso...beh...il concetto è sempre quello...chissenefrega del nome puntualmente corretto alla fine

 

[0xbro]

Questo è vero, ma soltanto la prima volta che si registra un nuovo dispositivo. Dopodiché si potrà accedere senza conferma del cellulare, quindi, nel nostro esempio, direttamente da Computer, a patto di aver registrato la chiave privata sul nuovo dispositivo.

Non credo, anche io avevo inteso così e premetto che non ho ancora avuto tempo di provare le passkeys sul mio account di test Google, ma facendo delle prove con WebAuthn (che dovrebbe avere lo stesso funzionamento dell'implementazione fatta da Google) ho iniziato a pensare che quelli di Google abbiamo sbagliato a descrivere il processo o che comunque non siano stati chiari. Infatti se con WebAuthn provi prima a registrare il tuo pc usanto il cell come fattore di verifica, e poi provi a fare il login dal PC, ti verrà chiesto comunque di confermare il login tramite cellulare. Lo stesso non accade se provi ad accedere da smartphone, in quel caso ti chiede solo l'impronta/master-password e ti fa entrare

 

[St3ve]

Non credo, anche io avevo inteso così e premetto che non ho ancora avuto tempo di provare le passkeys sul mio account di test Google, ma facendo delle prove con WebAuthn (che dovrebbe avere lo stesso funzionamento dell'implementazione fatta da Google) ho iniziato a pensare che quelli di Google abbiamo sbagliato a descrivere il processo o che comunque non siano stati chiari. Infatti se con WebAuthn provi prima a registrare il tuo pc usanto il cell come fattore di verifica, e poi provi a fare il login dal PC, ti verrà chiesto comunque di confermare il login tramite cellulare. Lo stesso non accade se provi ad accedere da smartphone, in quel caso ti chiede solo l'impronta/master-password e ti fa entrare

No, credo che abbia ragione CrazyMonk. L'importante è che il tuo dispositivo abbia un TPM, poi che sia un cellulare o un computer non fa differenza. Io ho fatto un po' di confusione perché ho parlato di FIDO2, WebAuthn e Passkeys come se fossero la stessa cosa senza fare distinzioni tra l'usare hardware FIDO compliant integrato (e.g., smartphone o computer recenti) o rimovibile (e.g., Yubikey). Ho fatto meno prove di te (zero), ma da quello che ho capito l'autenticazione a "doppio single-factor" serve solo se il dispositivo non è stato registrato:

Using passkeys does not mean that you have to use your phone every time you sign in. If you use multiple devices, e.g. a laptop, a PC or a tablet, you can create a passkey for each one.

Cioè, se da smartphone riesci ad entrare solo con impronta/pin allora lo puoi fare anche da computer. Di fatto puoi usare le passkeys anche se il cellulare non ce l'hai proprio, l'importante è avere il chip TPM e un sistema operativo configurato per usarlo.

L'idea che volevo far passare con quel "doppio single-factor" che diverso da un "vero two-factor" è un po' diversa. Ammettiamo che per fare login dal computer devi dare l'okay dal cellulare, cosa sicuramente vera se ti metti nello scenario in cui stai usando un computer non tuo:

If you want to sign in on a new device for the first time, or temporarily use someone else's device, you can use a passkey stored on your phone to do so.

In questo scenario non vuoi salvare la chiave pubblica del computer, perché quel dispositivo è usato anche da altra gente, e ogni volta che vorrai effettuare l'accesso devi dare l'okay dal cellulare. Hai qualcosa che sembra un two-factor, però il two factor vero avviene in parallelo mentre questo "finto two-factor" avviene in seriale: il cellulare si autentica in single-factor verso il computer e il computer si autentica in single-factor verso il server. Nel "vero two-factor" hai due dispositivi che si autenticano verso il server (con un solo dispositivo chiede l'accesso).

Le citazioni vengono da So long passwords, thanks for all the phish. WebAuthn lo puoi anche usare per fare 2FA, come probabilmente stavi facendo, ma se non lo usi per rimpiazzare completamente la password sei ancora soggetto ad alcuni degli attacchi che le passkeys riescono a mitigare.

 

[fennek]

Nel "vero two-factor" hai due dispositivi che si autenticano verso il server (con un solo dispositivo chiede l'accesso).

Stiamo parlando di semantica, ma il two factor non dice che ci sono due dispositivi. 2 factors richiede due dei seguenti tre fattori: qualcosa che sei, qualcosa che sai, qualcosa che hai.

Vogliamo togliere qualcosa che sai, quindi ci teniamo qualcosa che hai e qualcosa che sei. Il qualcosa che hai e' il device, il qualcosa che sei e' l'impronta digitale per sbloccarlo (oppure falldown to qualcosa che sai: la password quando accedi e sblocchi il TPM).

Full disclaimer: lavoro in Google ma non ho collaborato a questo progetto, ne ho informazioni che non siano pubbliche. Personalmente uso TitanKeys fisiche, quindi la mia esperienza sul topic e' comunque zero

 

[St3ve]

Stiamo parlando di semantica, ma il two factor non dice che ci sono due dispositivi. 2 factors richiede due dei seguenti tre fattori: qualcosa che sei, qualcosa che sai, qualcosa che hai.

Sì, hai ragione a precisare. Di fatto anche io la TOTP, quando posso, la faccio direttamente dal computer perché non voglio fare affidamento sul mio smartphone. Volevo più che altro sottolineare che l'implementazione in passkeys (nel contesto "temporarily use someone else's device") non è come la classica two-factor authentication perché sebbene entra in gioco qualcosa che sei/sai (e.g., impronta/pin) e qualcosa che hai (e.g., smartphone) la doppia autenticazione viene fatta in daisy-chain: se fai multi-factor authentication in questo modo, ti basta rompere un nodo della catena per invalidare la sicurezza data da tutti i suoi predecessori. La multi-factor authentication vera, fatta nel modo classico usando anche più device, ti da qualche sicurezza in più.

Poi di fatto, come ha fatto notare CrazyMonk, le passkey sono state pensate per rimpiazzare le password. Vogliono essere pratiche, quindi non vanno considerate come fossero step da aggiungere alla già presente multi-factor authentication. Sono principalmente pensate per l'uomo comune che vuole cose pratiche e semplici, non per lo smanettone che si complica la vita.

Full disclaimer: lavoro in Google ma non ho collaborato a questo progetto, ne ho informazioni che non siano pubbliche. Personalmente uso TitanKeys fisiche, quindi la mia esperienza sul topic e' comunque zero

In un certo senso allora le stai già usando. Io le passkeys le ho buttate dentro al mucchio FIDO, di cui fanno parte anche le TitanKeys, perché sostanzialmente di questo si tratta: cambia l'implementazione, ma i protocolli sono gli stessi. Usando questa roba di google immagino che dovresti essere in grado di attaccare la chiavetta, premere il pulsante e autenticarti (in "single-factor" senza password) saltandoti tutto il passaggio "password manager -> password" che rimane soggetto a keylogging, clipboard stealing e man-in-the-middle. Le passkeys, per come l'ho capita, sono un po' la variante pseudo-software della tua chiavetta.

P.S. Come ti trovi con le TitanKeys? Le usi per sbloccare un password manager o ti capita di fare accessi diretti con WebAuthn? Come stai gestendo il problema "se la perdo o mi si rompe, addio chiave privata"?

 

[fennek]

Poi di fatto, come ha fatto notare CrazyMonk, le passkey sono state pensate per rimpiazzare le password. Vogliono essere pratiche, quindi non vanno considerate come fossero step da aggiungere alla già presente multi-factor authentication. Sono principalmente pensate per l'uomo comune che vuole cose pratiche e semplici, non per lo smanettone che si complica la vita.

Verissimo. Mi aspetto infatti che in ambito enterprise non verranno attivate e verranno usate chiavette fisiche.

P.S. Come ti trovi con le TitanKeys? Le usi per sbloccare un password manager o ti capita di fare accessi diretti con WebAuthn? Come stai gestendo il problema "se la perdo o mi si rompe, addio chiave privata"?

Le uso principalmente per lavoro, dove tutto passa attraverso Google SSO. Ho due chiavette, una con me, e una a casa. Se le perdo entrambe posso sempre andare in ufficio con un documento e farmene dare un'altra.

Per uso personale le ho aggiunte solo a qualche sito a cui tengo in maniera particolare. In generale, uso Bitwarden come password manager, e Authy per il SSO, backuppato su Nextcloud. Su Bitwarden la mia compagna e' il mio contatto d'emergenza: https://bitwarden.com/help/emergency-access/

La possibilità che io perda tutto esiste, ma e remota: sia io che la mia compagna dovremmo perdere accesso a tutti i nostri dispositivi elettronici in maniera irreparabile nello stesso momento. Considerando che alcuni di questi dispositivi non sono in casa nostra, direi che e' abbastanza remota...
Alla fine in questo modo ho 3 password che conosco a memoria: Google SSO per lavoro, Bitwarden, e sblocco del mio PC.

 

[0xbro]

FAQ interessante per chi volesse addentrarsi ulteriormente sull'argomento:

Passkeys may not be for you, but they are safe and easy—here’s why

Answering common questions about how passkeys work.

arstechnica.com

 

[MiLimat]

Relativamente alle passkeys su Google, qualcuno ha attivato la crittografia on-device?
Se sì, qualcuno potrebbe spigarmi i benefici e i rischi?

(link: https://support.google.com/accounts/answer/11350823?hl=it)

 

[ElectricDreamer]

Relativamente alle passkeys su Google, qualcuno ha attivato la crittografia on-device?
Se sì, qualcuno potrebbe spigarmi i benefici e i rischi?

Visualizza allegato 70111
(link: https://support.google.com/accounts/answer/11350823?hl=it)

Come funziona la crittografia delle password standard​

Attualmente, le password salvate vengono criptate quando vengono inviate tramite qualsiasi rete e quando vengono salvate su Google. La chiave di crittografia, che viene usata per accedere alle tue password, viene archiviata in sicurezza nel tuo Account Google. Google usa poi questa chiave per accedere alle tue password (decriptarle) quando:

• Vi accedi all'indirizzo passwords.google.com sui tuoi dispositivi Android o nelle impostazioni di Chrome.
• Le password vengono controllate per rilevare eventuali problemi di sicurezza tramite la funzionalità Controllo password.

Come funziona la crittografia on-device​

Se è configurata la crittografia on-device, i dati come le tue password possono essere sbloccati sul dispositivo soltanto usando la tua password di Google o il blocco schermo di un dispositivo Android idoneo, mentre le passkey possono essere sbloccate sul dispositivo soltanto usando il blocco schermo di un dispositivo Android idoneo. Con la crittografia on-device, nessuno oltre a te potrà accedere ai tuoi dati criptati.

Quindi in poche parole è sempre meglio attivarla, in questo modo solo tu puoi sbloccare il Gestore delle password di Google

 

[nfvblog]

Google Chrome ancora oggi ha problemi con il password manager che comunque può essere clonato insieme alle sessione, cosa che ha reso molto semplice ai vari attaccanti recuperare delle credenziali, soprattutto sui sistemi Microsoft

 

[☣ᴋɪʟʟ ꜰᴏʀ ᴛʜᴇ ᴛʜʀɪʟʟ☣]

Le uso in realtà da un bel po' e devo studiarci su riguardo possibili falle e vulnerabilità che si potrebbero riscontrare e dipendono anche dalla piattaforma di deployment.

Intanto però, dopo il ripristino dello smartphone sono rimasta chiusa fuori in modo irreversibile dall'account PayPal, protetto da 2FA con chiave di autenticazione su PC e smartphone: la passkey del laptop non ha mai funzionato (non è un problema di cross-site cookies o autorizzazioni del sito, avendo disabilitato tutti gli scudi e le protezioni del browser in fase di login) e ora vede il mio smartphone come un nuovo dispositivo, quindi tenta di inviare la notifica di accesso a quello "precedente", che non esiste più da nessuna parte, poiché come dicevo è soltanto stato fatto il ripristino di fabbrica e poi reinseriti tutti i dati, anche relativi a passwords' storage e cronologia, ma niente da fare.