Certamente sarebbe più conveniente memorizzare il mio KeePass database su S3, Dropbox o ancora meglio su SpiderOak. La mia paura è che il mio account di archiviazione su cloud venga compromesso e che le credenziali vengano ripristinate da una forza bruta o da un altro vettore di attacco. Quanto è sicuro questo? Di quali rischi ho bisogno di sapere?
È difficile quantificare esattamente, ma se si ha il DB su un dispositivo mobile, non direi che questo è particolarmente meno sicuro. KeePass crittografa il DB perché non ci si aspetta che il file protetto sia una garanzia. È senz'altro preferibile che il file DB non vada in the wild, ma se la tua sicurezza dipende dal fatto che il file crittografato rimanga confidenziale, allora hai problemi più grossi se utilizzare o meno il cloud storage.
Una password master sufficientemente strong dovrebbe impedire la forzatura bruta almeno abbastanza a lungo per rilevare una violazione e per poter cambiare le password al suo interno. In questo modo, potrebbe anche essere leggermente preferibile avere una copia locale su un dispositivo mobile in quanto qualcuno potrebbe compromettere il file se togli gli occhi dal tuo dispositivo anche momentaneamente e sarebbe molto più difficile identificare tale violazione.
Se vuoi proteggerlo ancora di più, puoi aggiungere un altro livello di sicurezza crittografando il file archiviato nello storage cloud online. La password principale fornisce una sicurezza piuttosto buona purché si scelga una password di forzatura bruta e difficile (lunga e veramente casuale), ma non può ancora competere con una chiave di crittografia lunga e reale. Se si cripta il file che si archivia online e si mantiene tale chiave protetta da una password master simile, ora il componente online è molto più difficile da decifrare (probabilmente impossibile se eseguito correttamente) e se il file chiave viene compromesso, semplicemente riattivi il tuo DB online immediatamente con una nuova chiave. Sei ancora nei guai se qualcuno può compromettere prima il tuo account cloud e ottenere il file, ma richiede due punti di compromissione invece di uno.
Personalmente, probabilmente finirò per usare il mio OwnCloud (che è auto-ospitato), ma ho il vantaggio di avere il mio server web personale e mi rendo conto che non è un'opzione che tutti possono sfruttare. (L'unica ragione per cui non ho è che non ho un particolare bisogno di coordinare un database di chiavi in quel modo.) Una soluzione basata su cloud pubblico dovrebbe funzionare come una seconda opzione eccellente.
Puoi aumentare la resilienza del tuo database KeePass alla forza bruta aumentando il numero di iterazioni PBKDF2 quando si ottiene la chiave di crittografia del database dalla tua password. Puoi farlo in KeePass sotto File > Impostazioni del database > Sicurezza. Personalmente, uso circa 5.000.000 di colpi (1 secondo di ritardo). Ricorda che i dispositivi mobili sono più lenti.
Uso la combinazione KeePass-Dropbox. Il database delle password è crittografato utilizzando una chiave derivata da una password principale strong . Anche se qualcuno acquisisce il tuo database di password crittografato tramite il tuo account cloud, una password master sufficientemente potente rende gli attacchi a forza bruta non fattibili.
In poche parole: utilizza una password master avanzata e non preoccuparti di questo.
Il cloud è intrinsecamente inaffidabile e i file conservati su di esso dovrebbero essere considerati vulnerabili, quindi è necessario disporre di una crittografia avanzata per proteggerti. KeePass offre questo. Tuttavia, devi essere in grado di fidarti di ogni cliente in cui inserisci la tua password. Se li leggi su un iPhone, ti fidi della piattaforma? Proteggi la tua password dalle telecamere della metropolitana quando la inserisci, ogni volta? E il tuo laptop?
Devi anche considerare il valore di ciò che stai proteggendo. Questo è salvaguardare i vostri fondi pensione? I tuoi punteggi nel campionato di bowling fantasy? Dissenso politico illegale nel tuo paese? In alcuni casi non vale la pena rischiare di sbagliare.
Quindi sì, se ti fidi di KeePass e ti fidi dei tuoi dispositivi e ti fidi della tua capacità di proteggere la tua chiave principale, non preoccuparti di mantenere il database in Dropbox.
Anche se il tuo database KP dovesse essere compromesso da Dropbox, utilizzando sia una password complessa, sia un file di chiavi non memorizzato in Dropbox dovrebbe darti sicurezza al di là di qualsiasi mezzo noto di attacco elettronico (come perché i tuoi dispositivi non sono già stati compromessi.
Il file di chiavi dovrebbe essere archiviato in una posizione sicura separata, ad esempio un'unità USB che è possibile proteggere fisicamente. Questo fornisce 3 livelli di protezione:
Mentre un cifrario sufficientemente strong dovrebbe essere in grado di resistere all'attacco della forza bruta, considera che memorizzando il tuo database delle password nel cloud offri al potenziale aggressore molte più informazioni di quante ne possa ricavare, ad es. un telefono perso con lo stesso database.
Ogni volta che modifichi una password, l'utente malintenzionato riceve un nuovo database, che può utilizzare insieme alle versioni precedenti in attacchi di analisi differenziale . Avrai bisogno di un codice più potente per resistere a questo, rispetto al semplice COA . Se anche lui ha una delle tue password (ad esempio rompendo un database delle password scarsamente protetto da uno dei siti che visiti), potrebbe essere in grado di identificare quella password nel tuo database. Ciò aprirà le porte per KPA che potrebbe essere vicino a banale nel caso in cui riutilizzi le password.
Stai anche fornendo informazioni sull'utente malintenzionato sulla tua attività legata alla password. Saprà con quale frequenza cambierai le tue password e potrebbe essere in grado di dedurre quali password modificare.
Quindi, se decidi di memorizzare il tuo database di password in un cloud pubblico,
Scegli un algoritmo di crittografia strong, resistente alla criptoanalisi differenziale. Assicurati che ogni password nel database sia salata individualmente.
Modifica la password principale regolarmente, preferibilmente tutte le volte che usi la tua password più preziosa.
Non riutilizzare le password.
Suggerirei una soluzione che implichi quanto segue:
Come menzionato da tutti, avere una password master strong per il tuo file di database è molto importante per contrastare gli attacchi di forza bruta. Ma se lo combini con un file chiave, diventa praticamente impossibile alla forza bruta.
Se Cloud Storage 1 è compromesso, il file di database stesso senza il file chiave sarà impossibile da forzare, a meno che non ci sia una seria vulnerabilità alla sicurezza nell'implementazione della crittografia di Keepass.
Se Cloud Storage 2 è compromesso, il file chiave stesso se inutile senza il file di database. È solo un'estensione della tua password principale, non contiene dati.
Direi che sarebbe altamente improbabile che entrambi i Cloud Storage venissero compromessi allo stesso tempo dallo stesso aggressore. Dovresti essere un individuo di alto profilo per questo (ad esempio politico, miliardario, agente segreto ecc.):)
Se non sei uno di quelli sopra e sei disposto a sacrificare un po 'di sicurezza in cambio della facilità di accesso (ad esempio continui a dimenticare dove metti quel maledetto disco USB), quindi archivia entrambi File di database e File chiave su il computer locale. Tuttavia, in questo caso il computer locale diventa il punto debole, se compromesso, l'utente malintenzionato avrebbe accesso al file chiave, quindi dovrebbe solo forzare la master password sul database, quindi è meglio impostarne uno strong. Sarebbe come non usare affatto un file chiave.
Sono un strong sostenitore della difesa in profondità su questo.
Non importa quanto sia strong la tua password, è anche quella che non può essere cambiata.
Quindi per proteggere il mio database Keepass, sto usando tre livelli:
On perché la password non può essere cambiata: naturalmente puoi cambiare la password, e in effetti riedificherà il database Keepass, ma non potrai cambiarlo retroattivamente con le vecchie copie.
Specialmente (ma non solo) se si archivia il database nel cloud, si deve presumere che un avversario abbia ottenuto una sospensione del database in un momento precedente, con una vecchia password. Questo potrebbe darle le informazioni che sta cercando.
Se vuoi essere veramente serio sulle cose, esegui Boxcryptor insieme a Dropbox. Boxcryptor crittografa tutto alla tua estremità PRIMA di inviarlo ai server di Dropboxs. Tutto ciò che è alla fine di Dropbox è un carico di cose criptate. Il tuo keepass db finisce doppiamente crittografato!
Un'altra opzione: usa il cloud solo per trasferire il tuo database sul dispositivo successivo e poi cancellarlo dal cloud storage. Questo esporrà il tuo database per un periodo di tempo limitato. Non esattamente quello che stavi chiedendo, ma un'opzione che può essere presa in considerazione a seconda del tuo livello di sicurezza richiesto.
Dico andare con la soluzione cloud "crittografata al client" di tua scelta, crittografare con la maggior parte delle iterazioni PBKDF2 con cui ti trovi a tuo agio, il più grande file di chiavi con cui puoi convivere e, soprattutto, conservare le informazioni che ti sono vicine ( localmente) su un drive SELF ENCRYPTING. Metti in cima un filesystem crittografato, se necessario, ma la crittografia dei dati soggetti a perdita o furto, come un'unità USB, deve essere automatica.
Se un gruppo è in grado di compromettere un servizio cloud abbastanza da scoprire di avere un kdb da crackare, potrebbe avere più motivi per installare un key logger / root kit sui dispositivi personali. Ovviamente, se un gruppo di questo tipo può vederti scaricare il software da sourceforge o da un app store, ottengono informazioni simili. In realtà, questo post è un suggerimento molto più facile, quindi la preoccupazione per questo vettore di attacco potrebbe essere per gli individui più paranoici di noi stessi.
Leggi altre domande sui tag passwords cloud-storage keepass