Google ha recentemente annunciato la semplificazione del processo di abilitazione dell’autenticazione a due fattori (2FA) per gli utenti con account personali e Workspace.
Nota anche come 2-Step Verification (2SV), punta ad introdurre un nuovo livello di sicurezza, da aggiungere agli account degli utenti per prevenire attacchi di takeover in caso di furto delle password.
“Il recente miglioramento del setup dell’autenticazione a due fattori da parte di Google“, commenta Fabrizio Vacca, MSS Operations Director Tinexta Cyber, “sia per account personali che aziendali, introducendo metodi di autenticazione aggiuntivi come app per autenticatori e chiavi di sicurezza hardware, rappresenta un passo significativo verso la semplificazione e il rafforzamento della sicurezza degli utenti”.
Ecco però quali criticità rimangono aperte, in caso di attacchi di tipo Adversay-in-The-Middle. E come difendersi.
Indice degli argomenti
Google facilita l’impostazione dell’autenticazione a due fattori: come funziona
La nuova modifica prevede infatti un secondo metodo, come un’app di autenticazione o una chiave di sicurezza hardware, prima di abilitare la 2FA, eliminando così la necessità di sfruttare l’autenticazione via SMS, notoriamente la meno sicura.
“Ciò è particolarmente utile per le organizzazioni che utilizzano Google Authenticator (o altre applicazioni equivalenti di password monouso a tempo – TOTP)”, ha dichiarato l’azienda. “In precedenza, gli utenti dovevano abilitare 2SV con un numero di telefono prima di poter aggiungere Authenticator”.
Gli utenti che possiedono chiavi di sicurezza hardware hanno due opzioni per aggiungerle ai loro account: la registrazione di una credenziale FIDO1 sulla chiave hardware o l’assegnazione di una passkey (cioè una credenziale FIDO2) a una di esse.
Il motore di ricerca osserva che agli account Workspace potrebbe ancora essere richiesto di inserire la password insieme alla chiave di accesso se il criterio di amministrazione “Consenti agli utenti di saltare le password all’accesso utilizzando le chiavi di accesso” è disattivato.
Ma in un altro rilevante aggiornamento, gli utenti che scelgono di disattivare la 2FA dalle impostazioni dell’account non vedranno più rimossi in automatico i second step registrati.
“Quando un amministratore disattiva il 2SV per un utente dalla console di amministrazione o tramite l’Admin SDK, la rimozione dei second factor avverrà come in precedenza, per garantire che i flussi di lavoro di off-boarding degli utenti non vengano influenzati”, ha dichiarato Google.
Nuova criticità in caso di attacco man-in-the-middle
Oltre 400 milioni di account Google hanno iniziato a utilizzare i passkeys nel corso dell’ultimo anno per effettuare l’autenticazione senza password.
I nuovi metodi e standard di autenticazione, come FIDO2, sono nati per resistere, fin dalla progettazione, agli attacchi di phishing e dirottamento delle sessioni, sfruttando le chiavi crittografiche generate e collegate a smartphone e computer per la verifica degli utenti. Al contrario di una password che può essere facilmente oggetto di furto tramite un malware di raccolta delle credenziali o rubata direttamente.
“Questa mossa strategica non solo riduce i rischi associati all’autenticazione basata su SMS, meno sicura, ma si allinea anche alle tendenze più ampie dell’industria verso opzioni senza password più resilienti”, spiega Fabrizio Vacca.
“Tuttavia”, mette in guardia Fabrizio Vacca, “nonostante questi avanzamenti, la recente ricerca sulle minacce di attacchi di tipo Adversay-in-The-Middle evidenzia le sfide continue nel proteggere le identità digitali contro minacce cibernetiche sofisticate”.
Infatti, da una nuova ricerca di Silverfort emerge che un attore delle cyber minacce potrebbe aggirare FIDO2, mettendo in atto un attacco adversary-in-the-middle (AitM) in grado di dirottare le sessioni degli utenti nelle applicazioni che utilizzano soluzioni single sign-on (SSO) come Microsoft Entra ID, PingFederate e Yubico.
“Un attacco MitM riuscito espone l’intero contenuto delle richieste e delle risposte del processo di autenticazione”, ha dichiarato Dor Segal, ricercatore di sicurezza: “Al termine, l’avversario può acquisire il cookie di stato generato e dirottare la sessione dalla vittima. In parole povere, non c’è alcuna convalida da parte dell’applicazione al termine dell’autenticazione”.
I dettagli
L’attacco è reso possibile dal fatto che la maggior parte delle applicazioni non protegge i token di sessione creati dopo il successo dell’autenticazione, consentendo così a un malintenzionato di ottenere un accesso non autorizzato.
Inoltre, non viene effettuata alcuna convalida sul dispositivo che ha richiesto la sessione, il che significa che qualsiasi dispositivo può utilizzare il cookie fino alla sua scadenza. Ciò rende possibile aggirare la fase di autenticazione acquisendo il cookie tramite un attacco AitM.
Come proteggersi
Per garantire che la sessione autenticata sia utilizzata esclusivamente dal client, si consiglia di adottare una tecnica nota come token binding, che consente alle applicazioni e ai servizi di legare crittograficamente i propri token di sicurezza al livello di protocollo Transport Layer Security (TLS).
Mentre il token binding è attualmente limitato a Microsoft Edge, il mese scorso Google ha annunciato una nuova funzione in Chrome chiamata Device Bound Session Credentials (DBSC) per aiutare a proteggere gli utenti dal furto di cookie di sessione e dagli attacchi di hijacking.
