I principali distributori di Managed Service Provider (MSP) non si limitano ad aggiungere strumenti di gestione delle identità al loro marketplace. Stanno ridefinendo i criteri per
I gestori di password, tra gli strumenti di sicurezza più utili disponibili, offrono la generazione di password efficaci e l’archiviazione crittografata delle credenziali. Tuttavia, gli hacker stanno iniziando a prendere di mira i gestori di password sfruttando il flusso di registrazione del dispositivo, ovvero il processo utilizzato per verificare e approvare un nuovo dispositivo prima che possa accedere alla cassaforte di un utente. Attraverso attacchi di forza bruta alle password monouso (OTP) che proteggono questa fase, gli hacker possono registrare dispositivi non autorizzati e scaricare copie di casseforti crittografate.
Questo è ciò che è successo a Dashlane nel maggio 2026: gli hacker hanno forzato i codici a sei cifre utilizzati per registrare nuovi dispositivi, aggiungendo dispositivi non autorizzati a meno di 20 account e scaricando copie delle casseforti di tali utenti. La crittografia in sé non è mai stata violata, ma la vulnerabilità risiedeva nella procedura di approvazione dei nuovi dispositivi. Gli attacchi di forza bruta che prendono di mira la registrazione dei dispositivi nei gestori di password sono una minaccia informatica in crescita, ma sono inefficaci contro l’architettura zero-trust e zero-knowledge di Keeper, che garantisce che conoscere una password non sia mai sufficiente per registrare un dispositivo e accedere a una cassaforte.
Come funzionano gli attacchi di forza bruta nella fase di registrazione dei dispositivi
Quando aggiungi un nuovo dispositivo a un gestore di password, il provider deve verificare che il dispositivo sia tuo prima di concederti l’accesso alla tua cassaforte. Questa fase di conferma nel flusso di registrazione del dispositivo è l’obiettivo di questi attacchi di forza bruta. Per capire perché alcuni gestori di password come Dashlane sono vulnerabili a questo attacco mentre altri come Keeper® no, è utile sapere come funzionano in genere questi attacchi:
- Viene emesso un codice: dopo aver aggiunto un nuovo dispositivo a un account, il servizio deve verificare l’identità dell’utente, in genere inviando un codice OTP a sei cifre via e-mail o generandolo con un’app di autenticazione. L’inserimento di questo codice dimostra che la persona che registra il dispositivo è il legittimo proprietario dell’account.
- L’endpoint viene sovraccaricato: poiché un OTP a sei cifre ha solo 1 milione di combinazioni possibili, un hacker può inviare un elevato volume di richieste automatizzate all’endpoint API di registrazione dei dispositivi. Se l’endpoint non applica limiti di frequenza, finestre di scadenza del codice o blocchi dopo tentativi falliti, l’hacker può provare rapidamente diverse combinazioni fino a individuare il codice valido.
- Viene individuato un codice valido: dopo un numero sufficiente di tentativi contro un endpoint non sufficientemente protetto, l’hacker riesce a individuare il codice corretto. Poiché quel codice è la prova dell’identità dell’utente, il dispositivo dell’hacker viene accettato come legittimo.
- Il dispositivo viene registrato: il fornitore di servizi autorizza il nuovo dispositivo e sincronizza su di esso la cassaforte crittografata dell’utente. Sebbene i dati della cassaforte rimangano criptati, l’hacker ora possiede una copia dei dati crittografati e può tentare di decrittografarli offline senza limiti di tempo.
Questo processo non è ipotetico, ma ripercorre esattamente l’attacco condotto contro Dashlane. È per questo che proteggere il flusso di registrazione dei dispositivi è importante quanto proteggere le casseforti.
Perché la registrazione non autorizzata dei dispositivi crea un rischio
La registrazione non autorizzata di un dispositivo introduce seri rischi per la sicurezza, poiché una volta che un nuovo dispositivo viene registrato a un account di un gestore di password, può accedere alla cassaforte dell’utente e apparire come un utente autenticato e legittimo. L’hacker non ha bisogno di bypassare, indebolire o violare la crittografia della cassaforte per eseguire questo tipo di attacco di forza bruta. Tutto ciò di cui ha bisogno è che il fornitore di servizi si fidi del suo dispositivo, consentendo la sincronizzazione diretta dei dati crittografati della cassaforte con l’hardware sotto il suo controllo.
Il fatto che un hacker possieda una copia della cassaforte crittografata di un utente ha implicazioni a lungo termine, poiché può tentare di decrittografarla offline a suo piacimento per tutto il tempo necessario a ottenere l’accesso. Sebbene una crittografia efficace della cassaforte renda statisticamente difficile riuscire in questa impresa, la probabilità di successo dipende in larga misura da un fattore che l’utente può controllare: l’efficacia della sua password principale. Una password principale lunga, complessa e univoca può impedire che una cassaforte sottratta venga decrittata, ma una password principale debole o riutilizzata ha molte più probabilità di essere compromessa se si dispone di tempo sufficiente. È fondamentale rendere sicuro il processo di registrazione dei dispositivi, in modo che la protezione della cassaforte di un utente non dipenda esclusivamente dalla sicurezza della sua password principale.
In che modo Keeper aiuta a prevenire gli attacchi di forza bruta durante la registrazione dei dispositivi
Gli utenti di Keeper non potrebbero cadere vittime dello stesso tipo di attacco di forza bruta che ha colpito Dashlane, perché Keeper garantisce che il semplice fatto di conoscere la password di un utente o di riuscire a forzare un OTP non sia sufficiente per registrare un nuovo dispositivo o accedere a una cassaforte.
Approvazione dei dispositivi
Con Keeper, ogni nuovo dispositivo deve essere esplicitamente approvato prima di poter accedere a una cassaforte. Questa approvazione è un passaggio separato e intenzionale, non qualcosa che avviene automaticamente non appena si inserisce un codice. Per i singoli utenti, l’approvazione viene data dal titolare dell’account tramite un dispositivo già considerato affidabile; per le aziende, un amministratore può approvare i nuovi dispositivi per conto degli utenti autorizzati. In questo tipo di attacco, è sufficiente indovinare un OTP valido per completare la registrazione del dispositivo, ma con Keeper non esiste un singolo endpoint API il cui codice possa essere forzato per completare il processo.
Autenticazione a più fattori (MFA)
Keeper supporta una varietà di metodi MFA o Autenticazione a due fattori (2FA), tra cui chiavi di sicurezza hardware FIDO2/WebAuthn, dati biometrici, app di autenticazione e SMS. Tuttavia, non tutti questi metodi sono ugualmente resistenti agli attacchi di forza bruta. I codici inviati via email o SMS sono i più vulnerabili, poiché possono essere indovinati o intercettati durante la trasmissione. Le app di autenticazione offrono una protezione maggiore perché il codice viene generato localmente sul dispositivo dell’utente, ma si basano comunque su codici brevi e a tempo, e quindi dipendono da limiti di frequenza e altri controlli per impedire tentativi di attacco di forza bruta. Le chiavi di sicurezza hardware offrono la protezione più efficace perché si basano sull’autenticazione crittografica challenge-response anziché su un codice breve. Dato che non esiste un valore prevedibile che un hacker possa inviare ripetutamente a un endpoint API, gli attacchi di forza bruta mirati alla registrazione dei dispositivi diventano inefficaci.
Sicurezza zero-trust:
Keeper è basato su un modello di sicurezza zero-trust, il che significa che ogni richiesta di accesso deve essere verificata indipendentemente dalla posizione di rete o dalla cronologia delle autenticazioni precedenti. Con Keeper, a un dispositivo non viene concessa una fiducia implicita e permanente semplicemente perché è già stato registrato o verificato; ogni richiesta viene valutata in modo indipendente. Questo modello di sicurezza implica che, anche se un malintenzionato riuscisse in qualche modo a registrare un dispositivo, tale singolo successo non gli garantirebbe un accesso continuativo. Con un framework zero-trust, non esiste alcun meccanismo attraverso cui un hacker possa sfruttare la registrazione del dispositivo per ottenere un accesso illimitato.
Modulo per segnalazioni e avvisi avanzati (ARAM)
Il Modulo per segnalazioni e avvisi avanzati (ARAM) di Keeper offre agli amministratori visibilità sui comportamenti sospetti nel loro ambiente, incluse anomalie durante l’autenticazione e tentativi di registrazione dei dispositivi. I tentativi di verifica che avvengono in un breve intervallo di tempo o un elevato numero di tentativi falliti di registrazione dei dispositivi sono esattamente i tipi di eventi che l’ARAM può rilevare. Avere piena visibilità sulle attività insolite consente agli amministratori di agire rapidamente, invece di lasciare che comportamenti sospetti passino inosservati fino a quando un dispositivo non autorizzato non viene registrato.
Per saperne di più su come l’architettura di approvazione, autenticazione e crittografia dei dispositivi di Keeper si distingue da quella di Dashlane, visita la nostra pagina di confronto Keeper vs Dashlane.
Perché l’architettura zero-knowledge di Keeper è importante
I controlli di accesso di Keeper sono progettati per impedire a un hacker di registrare un dispositivo, ma un ulteriore livello di protezione rafforza maggiormente la sicurezza: un’architettura zero-knowledge. In pratica, zero knowledge significa che tutto ciò che è archiviato nella cassaforte di un utente è crittografato end-to-end in ogni momento, quindi nemmeno Keeper può decrittografarlo. Poiché le chiavi di crittografia vengono generate sul dispositivo dell’utente, i dati vengono crittografati e decrittografati localmente, garantendo che la cassaforte rimanga interamente sotto il controllo dell’utente. Anche se un hacker riuscisse in qualche modo a ottenere una copia della cassaforte crittografata di un utente, si troverebbe di fronte a una sfida pressoché impossibile, poiché le chiavi di crittografia necessarie per sbloccare una cassaforte Keeper non sono presenti nell’infrastruttura di Keeper.
Proteggi i tuoi dati dagli attacchi di forza bruta con Keeper
L’incidente di sicurezza di Dashlane dimostra che una crittografia robusta della cassaforte da sola non è sufficiente. Dal momento che gli hacker spostano la loro attenzione dalla decifrazione di casseforti crittografate allo sfruttamento dei flussi di lavoro che ne consentono l’accesso, comprendere come prevenire gli attacchi di forza bruta e proteggere i processi di registrazione e autenticazione dei dispositivi è fondamentale. Un gestore di password deve proteggere sia le casseforti degli utenti sia il flusso che gestisce chi può accedervi.
La violazione dei dati di LastPass del 2022 ha avuto un esito simile, ma attraverso un percorso diverso: gli hacker hanno compromesso l’infrastruttura dell’azienda e rubato copie di casseforti crittografate, ma i ricercatori di sicurezza hanno successivamente ricondotto il furto a casseforti protette in modo debole. Gli incidenti di Dashlane e LastPass dimostrano che, una volta ottenuto l’accesso alla cassaforte crittografata di un utente, quest’ultimo può essere attaccato indefinitamente, sottolineando l’importanza di utilizzare un gestore di password sicuro per proteggere i propri dati.
Keeper è progettato per difendersi da questo tipo di attacchi tramite l’approvazione del dispositivo, garantendo che un codice indovinato non possa registrare un nuovo dispositivo autonomamente; molteplici metodi MFA; e un modello di sicurezza zero-trust, che garantisce che nessun dispositivo sia implicitamente affidabile. Queste misure di protezione funzionano all’interno di un’architettura zero-knowledge che mantiene le chiavi di crittografia sotto il controllo dell’utente.
Inizia una prova gratuita di Keeper per scoprire come la sua sicurezza a più livelli garantisce che i dati della tua cassaforte siano crittografati con chiavi che solo tu controlli.