È arrivato BreachWatch di Keeper

BreachWatch è un add-on potente e sicuro che monitora Internet e il dark web alla ricerca di account violati che corrispondono ai dati memorizzati all’interno della Keeper Vault.

Con un database di oltre un miliardo di voci e l’architettura di sicurezza zero-knowledge di Keeper, BreachWatch offre le più avanzate funzionalità di monitoraggio del settore attualmente disponibili.

Panoramica

BreachWatch ti avvisa in modo che tu possa intraprendere azioni immediate per proteggerti dagli hacker. Una volta attivato, BreachWatch monitora continuamente i dati alla ricerca di eventuali credenziali compromesse, traccia oltre un miliardo di password conosciute e integra continuamente nuove informazioni a seguito di ogni nuova violazione scoperta sul dark web.

Iscriversi

Iscriversi è facile. Dal tuo dispositivo mobile, vai alla schermata BreachWatch e segui le istruzioni sullo schermo. Puoi anche acquistare BreachWatch direttamente dal sito di Keeper Security.

Dopo l’iscrizione, BreachWatch esegue una scansione in locale delle password attualmente archiviate nella Keeper Vault e avvisa i clienti se alcune delle informazioni dei loro account corrispondono a credenziali a rischio.

Funzionalità di BreachWatch

1. I clienti vengono automaticamente avvisati se una qualsiasi delle password nella cassaforte corrisponde a una password violata.
2. La correzione della password violata viene eseguita all’interno dell’app ruotando la password sul sito o sul servizio interessato.
3. Keeper tiene traccia della cronologia delle risoluzioni di ogni password violata per l’auditing.

Video demo

Ecco BreachWatch in azione su iOS.

BreachWatch è disponibile anche per la cassaforte web e con l’app desktop di Keeper.

Architettura di sicurezza di BreachWatch

Panoramica sulla sicurezza

L’architettura zero-knowledge di BreachWatch utilizza una serie di tecniche a più livelli per proteggere le informazioni dei clienti. In sintesi:

1. Per eseguire un confronto delle password con un database di informazioni di account violati vengono utilizzati una funzione di hash crittografica, sicura e con chiave, e un processo di anonimizzazione (descritto di seguito).

2. Le password dei clienti vengono elaborate con un modulo di sicurezza hardware (HSM) e una chiave segreta non esportabile prima di essere confrontate con le password violate o archiviate sui server di BreachWatch.

3. I clienti Keeper interagiscono con BreachWatch utilizzando ID BreachWatch anonimi che non sono associati ad altri ID cliente Keeper.

4. BreachWatch separa i nomi utente e le password in servizi distinti con ID differenti e anonimi per disassociare i nomi utente e i domini dalle password.

5. I clienti BreachWatch si limitando a scaricare i domini senza mai eseguire l’upload delle relative informazioni, in questo modo, il recupero delle informazioni private avviene nel modo più sicuro possibile.

Figura 1. Il percorso dei dati delle password con hash di un cliente attraverso BreachWatch. Sui server BreachWatch vengono archiviate solo le password rinforzate con un HSM e una chiave non esportabile. I clienti BreachWatch utilizzano ID anonimi per le interazioni con i server BreachWatch.

Individuazione sicura degli account violati

Confrontare in modo privato le credenziali dei clienti con un ampio database di informazioni violate è tecnicamente impegnativo. Infatti, la soluzione deve essere sicura e computabile in modo efficiente con i mezzi attuali, risorse di calcolo e larghezza di banda incluse. In pratica, questo è il classico esempio di intersezione di set privati o di problema di recupero di informazioni private. I clienti Keeper hanno un database locale di nomi di dominio, nomi utente e password. BreachWatch ha un ampio database degli stessi elementi. Un requisito critico della nostra soluzione è avere a disposizione un modello di sicurezza in grado di determinare le password vulnerabili senza esporre le informazioni al servizio di BreachWatch.

La soluzione più semplice al problema del recupero delle informazioni private è che l’applicazione client scarichi il set di dati ed esegua il confronto in locale. Tuttavia, questo tipo di soluzione può essere implementata per i confronti di domini in cui il set di dati è limitato, ma non quando il set di nomi utente e password violati supera il miliardo di punti dati. Va da sé che non sarebbe pratico o nemmeno possibile trasferire tutte queste informazioni direttamente ai dispositivi del cliente.

Tecniche come i filtri Bloom crittografati [1] possono aiutare a ridurre le dimensioni dei download e mantenere comunque l’elaborazione sul lato client al fine di preservare i massimi livelli di sicurezza dei dati. Tuttavia, creare un ulteriore filtro Bloom su set di dati di questa portata è ancora troppo impegnativo per la maggior parte dei dispositivi. Inoltre, il filtro Bloom deve essere aggiornato ogni settimana man mano che il database delle violazioni viene modificato.

Alcuni sistemi utilizzano la k-anonymity [2] tramite hash delle password troncati e senza salt, ma questa tecnica non è sicura. In breve, invece di caricare le password (o gli hash delle password) sul server per eseguire il controllo, i client caricano un hash troncato di ogni password (ad esempio, i primi 20 bit) sul server. Questo hash troncato corrisponderà a un set leggermente più grande di password che verranno scaricate e controllate sul dispositivo client. Il problema di questo approccio è che le dimensioni del set scaricato va di pari passo con l’ambiguità del server (o con l’autore dell’attacco). Pertanto, se si prevede che un client scarichi 100 password per ogni hash troncato caricato, se l’hash troncato di un client viene esposto (o rubato da un server), l’utente malintenzionato ha solo 100 password distinte da controllare. Quindi, se un utente malintenzionato riesce a testare 5 password al giorno senza bloccare l’account, potrebbe accedervi in 20 giorni.

Figura 2. I domini dei clienti vengono controllati localmente: la tecnica più sicura del settore per il recupero di informazioni private.

BreachWatch

Per garantire la massima sicurezza, Keeper ha suddiviso BreachWatch in tre servizi di controllo distinti, uno per i domini, uno per i nomi utente e uno per le password. Le applicazioni client Keeper contattano ciascuno di questi servizi di backend utilizzando un’API REST crittografata.

Controllo dei domini

La verifica dei domini è la soluzione più semplice tra i tre controlli che eseguiamo. I clienti BreachWatch scaricano un elenco di domini violati ed eseguono il controllo in locale. Questa è la soluzione più semplice (e sicura) al problema del recupero di informazioni private. Inoltre, periodicamente, i client scaricano elenchi aggiornati di nuovi domini man mano che vengono aggiunti al servizio BreachWatch.

Controllo dei nomi utente e delle password

I servizi di controllo dei nomi utente e delle password sono più complessi per via delle dimensioni ingenti di questi set di dati. Per poter avvisare i clienti quando una nuova violazione ha compromesso un account, dobbiamo testare i nomi utente e le password offline. Per questi servizi, i dispositivi client si connettono a BreachWatch e caricano un elenco di nomi utente (o password) con hash insieme a un ID casuale selezionato dal client (con ID separati per i servizi di controllo dei nomi utente e delle password). Tali hash delle password vengono elaborati in fase di caricamento con HMAC [3] utilizzando un modulo di sicurezza hardware (HSM) e una chiave segreta archiviata nell’HSM contrassegnata come non esportabile (in pratica, l’HSM elaborerà l’HMAC solo in locale e la chiave non potrà essere estratta). Questi input HMAC (nomi utente o password) vengono confrontati con i set di dati delle violazioni elaborati con la stessa chiave e lo stesso HMAC. Tutte le corrispondenze vengono segnalate al dispositivo client, mentre tutti i valori che non corrispondono vengono archiviati insieme all’ID anonimo del client.

Man mano che vengono aggiunti al sistema nuovi nomi utente e password violati, questi vengono elaborati con l’HMAC sull’HSM, aggiunti al set di dati BreachWatch e confrontati con i valori dei client archiviati. Tutte le corrispondenze mettono in coda un messaggio per quel determinato ID client.

I client effettuano un controllo periodico con BreachWatch e presentano i propri ID BreachWatch. Tutti i messaggi in coda vengono scaricati e i client caricano nomi utente e password nuovi o modificati che verranno elaborati allo stesso modo.

La sicurezza dei servizi BreachWatch è basata sul modello Fiducia al primo utilizzo (TOFU). In altre parole, i client devono presumere che il server BreachWatch non sia dannoso (ovvero che non sia compromesso attivamente da un utente malintenzionato) quando caricano i valori con hash. Una volta elaborati con un HSM, questi valori vengono protetti dai tentativi di violazione offline. In pratica, se un utente malintenzionato ruba il set di dati dei valori dei client archiviati, non può violare tali valori offline senza la chiave HMAC archiviata nell’HSM.

La soluzione più sicura del settore

Keeper BreachWatch consente ai clienti di individuare e di essere avvisati degli account a rischio a causa di una violazione delle password. Un controllo del genere in un ambiente zero-knowledge è estremamente difficile da implementare, ma il team di Keeper dà la priorità alla sicurezza dei clienti rispetto a tutto il resto.

BreachWatch è più sicuro dei sistemi che archiviano hash semplici (o troncati) o che richiedono ai client di ricaricare tutte le credenziali ogni volta che viene rilevata una nuova violazione. BreachWatch consente di individuare in modo sicuro le violazioni offrendo, al contempo, una sicurezza elevata.

Domande frequenti

Contatti

In caso di domande sul servizio Keeper BreachWatch o sull’infrastruttura di sicurezza, contatta il nostro team di sicurezza all’indirizzo security@keepersecurity.com. Keeper Security offre un programma di divulgazione pubblica delle vulnerabilità con Bugcrowd a cui è possibile accedere all’indirizzo https://bugcrowd.com/keepersecurity.

Riferimenti

[1] Privacy-Enhanced Searches Using Encrypted Bloom Filters. https://mice.cs.columbia.edu/getTechreport.php?techreportID=483

[2] https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/

[3] HMAC. https://cseweb.ucsd.edu/~mihir/papers/kmd5.pdf