Domanda:
Archiviazione del database KeePass nel cloud. Quanto è sicuro?
dperry1973
2013-11-11 19:54:29 UTC
view on stackexchange narkive permalink

Sarebbe certamente più conveniente archiviare il mio database KeePass su S3, Dropbox o, meglio ancora, SpiderOak. La mia paura è che il mio account di archiviazione cloud venga compromesso e poi le credenziali vengano recuperate con forza bruta o qualche altro vettore di attacco. Quanto è sicuro questo? Quali rischi devo sapere?

Tredici risposte:
#1
+51
Matrix
2013-11-12 14:16:23 UTC
view on stackexchange narkive permalink

È possibile aumentare la resilienza del database KeePass alla forza bruta aumentando il numero di iterazioni PBKDF2 quando si ricava la chiave di crittografia del database dalla password. Puoi farlo in KeePass sotto File> Impostazioni database> Sicurezza. Personalmente, utilizzo circa 5.000.000 di colpi (1 s di ritardo). Ricorda che i dispositivi mobili sono più lenti.

Questa è in realtà la migliore risposta. In effetti, ciò che suggerisce @Matrix è ** cruciale ** per proteggere un database KeePass. Per impostazione predefinita è impostato su 6000 round di crittografia, il che non è sufficiente per contrastare un attacco di forza bruta. Non capisco perché sono l'unico a votare questa risposta.
@dr01 non solo tu. Ciò è accaduto anche con altri programmi di crittografia, impostati alla massima velocità invece che alla massima sicurezza. È quindi preferibile leggere lentamente ma rimanere al sicuro. Nessun problema per leggere a 50mb / s invece di 200mb / s. 50 MB sono per film e file mega grandi, non per dati sensibili.
Solo un aggiornamento del 2017: 1 secondo di ritardo sulla mia nuova macchina ora corrisponde a circa 28.000.000 di round.
Dovrebbe essere proprio all'inizio perché sono rimasto scioccato nel vedere i 6000 round predefiniti ** interrotti in soli 0,001 secondi **
Va notato che il nuovo Argon2 KDF, supportato da Keepass 2.35 e KBDX4, è probabilmente preferibile rispetto a AES KDF, in quanto può anche essere configurato per utilizzare quantità significative di memoria.
Dovremmo aggiungere che una password complessa è un prerequisito, è necessaria ma non sufficiente, abbiamo anche bisogno di un buon algoritmo + iterazione come detto.Personalmente uso una password con 20 caratteri davvero casuali.
dr_ e @Prof, con quale lunghezza della chiave?È ancora vero per una chiave di 64 caratteri alfanumerici casuali nel secondo slot di uno Yubikey?
Sembra che la risposta di @Adi's di seguito abbia lo stesso merito.Sarebbe utile fare un confronto tra le iterazioni aggiunte e la lunghezza dei caratteri casuale aggiunta.
Ecco un calcolo per una password casuale di 10 caratteri con 6000 iterazioni predefinite.Ci vogliono 50 milioni di anni .. https://security.stackexchange.com/questions/8476/how-difficult-to-crack-keepass-master-password
#2
+34
AJ Henderson
2013-11-11 20:20:04 UTC
view on stackexchange narkive permalink

È difficile quantificare esattamente, ma se si dispone del DB su un dispositivo mobile, non direi che sia particolarmente meno sicuro. KeePass crittografa il DB perché il file che rimane al sicuro non dovrebbe essere una garanzia. È certamente preferibile che il file DB non vada in libertà, ma se la tua sicurezza dipende dal fatto che il file crittografato rimanga confidenziale, allora hai problemi maggiori rispetto all'utilizzo o meno del cloud storage.

Un master sufficientemente forte la password dovrebbe impedire la forzatura bruta almeno abbastanza a lungo da consentire il rilevamento di una violazione e la modifica delle password al suo interno. In questo modo, potrebbe anche essere leggermente preferibile avere una copia locale su un dispositivo mobile poiché qualcuno potrebbe compromettere il file se distogli gli occhi dal tuo dispositivo anche solo momentaneamente e sarebbe molto più difficile identificare che si è verificata la violazione.

Se desideri proteggerlo ulteriormente, puoi aggiungere un altro livello di sicurezza crittografando il file che archivi nel cloud storage online. La password principale fornisce una sicurezza abbastanza buona fintanto che si sceglie una password difficile da forzare (lunga e veramente casuale), ma non può comunque competere con una chiave di crittografia lunga effettiva. Se si crittografa il file che si archivia online e poi si tiene quella chiave protetta da una password principale simile, ora il solo componente online è molto, molto più difficile da decrittare (probabilmente impossibile se fatto correttamente) e se il file della chiave viene compromesso, devi semplicemente crittografare nuovamente il tuo DB online immediatamente con una nuova chiave. Sei ancora nei guai se qualcuno può prima compromettere il tuo account cloud e ottenere il file, ma sono necessari due punti di compromissione invece di uno.

Personalmente, probabilmente finirei per utilizzare il mio OwnCloud (che è ospitato autonomamente), ma ho il vantaggio di avere il mio server web personale e mi rendo conto che non è un'opzione che tutti possono sfruttare. (L'unico motivo per cui non l'ho fatto è che non ho una particolare esigenza di coordinare un database di chiavi in ​​quel modo.) Una soluzione basata su cloud pubblico dovrebbe funzionare come una buona seconda opzione.

Un VPS vale la pena avere per quasi ogni persona attenta alla sicurezza, IMHO. Vultr, DigitalOcean e altri partono da $ 5 / mese e puoi caricare una VPN, OwnCloud, ecc.
La sicurezza esiste solo su localhost. Una volta che metti i file in un server "di un altro", non lo controlli. L'opzione migliore è utilizzare una password complessa sui database, oltre a un file chiave all'interno del cellulare o della pendrive, oltre a un cambio annuale delle password per ripristinare qualsiasi tentativo di forza bruta.
@erm3nda è vero che non controlli il sistema di qualcun altro, ma non controlli completamente il tuo. È un'affermazione falsa dire che la sicurezza esiste solo sull'host locale. La tua pen drive è suscettibile di essere smarrita o rubata. Esistono fornitori basati su sla con garanzie di sicurezza che ti consentono di sapere cosa stanno facendo. Si desidera comunque avere le proprie misure di protezione (linea che memorizza i dati dopo la crittografia lato client) ma in alcune situazioni una terza parte è in una posizione migliore per riempire determinati elementi di sicurezza in modo più sicuro per meno costi e sforzi.
La perdita di una pendrive non è un problema se si esegue il backup del file di chiavi in ​​un altro sito, un altro sito più intelligente di un semplice dispositivo fisico USB. Non c'è possibilità di dropbox (ad esempio) per rafforzare la mia sicurezza se i file non sono mai stati sui loro server. Non posso essere più chiaro di, mescola le cose e il gioco è fatto. Non lasciare mai a nessuno i pezzi completi del puzzle.
@erm3nda ah, se stavi semplicemente suggerendo di usare qualcosa che tieni con te per impedire la decrittografia dei file archiviati online, allora sono d'accordo e penso che stiamo dicendo la stessa cosa. C'è una domanda su quando è sufficiente per le tue esigenze, ma è una chiamata personale.
@AJHenderson "usa qualcosa", dico esattamente usando keyfile. Keyfile è un file speciale creato da pass / parafrasi e non puoi leggere contenuto criptato senza sia passwd che file (sicurezza a 2 livelli). Non importa cosa possono leggere, hanno bisogno del tuo file speciale per poterlo forzare. Questa tecnica è utilizzata in tutto il mondo (di solito anche con smartcard o pendrive) e, ad esempio, Keepass ha questa opzione. Anche se Dropbox non hackera il tuo computer e non ha accesso alla tua pendrive fisica, il tuo file è al sicuro sui loro server.
Vedi la risposta @Adi di seguito, è la stessa cosa ed è la migliore opzione attuale.
@erm3nda - Dico "usa qualcosa" semplicemente perché esiste più di un modo valido per separare i pezzi di cui hai bisogno e puoi anche dividerlo potenzialmente in più punti. Potresti usare una protezione biometrica, potresti usare una chiave che porti con te, potresti portare i dati con te ma archiviare la chiave fuori sede (meno comune, ma impedisce che la forzatura bruta dei dati sia anche un'opzione senza compromettere la tua persona o un sistema utilizzato). La parte importante è rendere necessari più punti di compromesso. Il file chiave era ambiguo poiché si tratta di una password db ...
Dato che eri nuovo nel sito e stavi facendo una dichiarazione generale come "la sicurezza esiste solo su localhost" che non è vera né nel senso paranoico né nel senso realistico del termine, ho pensato che potresti fare un riferimento errato al password db stesso quando hai detto "file chiave". Vedo ora che è stato un errore da parte mia, anche se il chiarimento (che abbiamo fatto ora) è utile per evitare che altri commettano lo stesso errore. Adi e io stiamo dicendo la stessa cosa. Ha menzionato una password principale complessa. Sono appena entrato in un'ulteriore spiegazione del perché. Aggiungerò qualcosa sull'utilizzo di una chiave di crittografia locale effettiva.
`ma se la tua sicurezza dipende dalla riservatezza del file crittografato,` - a cosa ti riferisci?password Keepass incorporata?O una crittografia aggiuntiva da solo?
Mi dispiace, non sono sicuro di quello che stai chiedendo.
#3
+22
Adi
2013-11-11 22:41:11 UTC
view on stackexchange narkive permalink

Uso la combinazione KeePass-Dropbox. Il database delle password viene crittografato utilizzando una chiave derivata da una password principale complessa . Anche se qualcuno acquisisce il tuo database di password crittografate tramite il tuo account cloud, una password principale abbastanza forte rende impossibili gli attacchi di forza bruta.

In poche parole: utilizza una password principale complessa e smetti di preoccuparti su questo.

`Il database delle password è crittografato utilizzando una chiave derivata da una password principale complessa` - come si fa?Cripti il tuo file db KeepassX * in aggiunta *?O è la password del tuo KeepassX e nient'altro?
Questo è l'unico riferimento incrociato che ho trovato in un commento di Reddit, ma sarebbe bene avere un confronto quantitativo tra le iterazioni aggiunte e la lunghezza dei caratteri casuale aggiunta."La vera" forza bruta "(provare ogni possibile combinazione di caratteri) è completamente insostenibile dopo circa 12-14 caratteri indipendentemente dal conteggio delle iterazioni."https://www.reddit.com/r/KeePass/comments/886hm0/question_about_keepass_and_brute_force_attacks/
#4
+9
John Deters
2013-11-11 20:09:37 UTC
view on stackexchange narkive permalink

Il cloud è intrinsecamente inaffidabile e i file conservati dovrebbero essere considerati vulnerabili, quindi è necessaria una crittografia avanzata per proteggerti. KeePass lo offre. Tuttavia, devi quindi essere in grado di fidarti di ogni client 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 salvaguarda i tuoi fondi pensione? I tuoi punteggi di campionato di bowling fantasy? Il dissenso politico illegale nel tuo paese? In alcuni casi semplicemente non vale la pena rischiare di commettere un errore.

Quindi sì, fintanto che ti fidi di KeePass e dei tuoi dispositivi e ti fidi della tua capacità di mantenere al sicuro la tua chiave principale, non preoccuparti di mantenere il database in Dropbox.

Ogni crittografia che usi ora, sarebbe facilmente hackerabile in un paio d'anni con meno di un'ora di lavoro di elaborazione. Posso assicurare a tutti che utilizzare sia una password complessa che un file di chiavi è l'unico vero modo. Combina barriere digitali e fisiche. Dropbox non può leggere la tua chiavetta USB. Chiunque abbia rubato la tua pendrive potrebbe non conoscere la tua password. Il mix è la chiave, non lasciare che gli altri sappiano la tua strada.
#5
+7
HourOfTheBeast
2014-05-24 04:05:32 UTC
view on stackexchange narkive permalink

Anche se il tuo database KP dovesse essere compromesso da Dropbox, l'utilizzo sia di una password complessa sia di un file di chiavi non memorizzato in Dropbox dovrebbe darti sicurezza al di là di qualsiasi mezzo noto di attacco elettronico (purché poiché i tuoi dispositivi non sono già compromessi).

Il file di chiavi deve essere archiviato in una posizione sicura separata, come un'unità USB che puoi proteggere fisicamente. Ciò fornisce 3 livelli di protezione:

  1. Account Dropbox (presumere una bassa sicurezza)
  2. La tua password complessa (complessa)
  3. Il tuo file di chiavi (sicuro come lo fai tu)
Non dimenticare di avere due o tre chiavi USB con la chiave di crittografia. Preferibilmente in luoghi separati e affidabili.
#6
+5
Dmitry Grigoryev
2015-10-05 18:58:59 UTC
view on stackexchange narkive permalink

Anche se un codice sufficientemente potente dovrebbe essere in grado di resistere a un attacco di forza bruta, si consideri che archiviando il database delle password nel cloud si fornisce al potenziale aggressore molte più informazioni di quante ne potrebbe ottenere, ad es. un telefono smarrito con lo stesso database.

Ogni volta che modifichi una password, l'aggressore ottiene un nuovo database, che può utilizzare insieme alle versioni precedenti in attacchi di analisi differenziale. Avrai bisogno di un codice più forte per resistere a questo, rispetto al semplice COA. Se anche lui ha una delle tue password (ad esempio violando un database di password scarsamente protetto da uno dei siti che visiti), potrebbe essere in grado di identificare quella password nel tuo database. Ciò aprirebbe le porte a KPA che potrebbe essere quasi banale nel caso in cui riutilizzi le password.

Fornisci anche all'autore dell'attacco informazioni sulla tua attività relativa alle password. Saprà quanto spesso cambi le tue password e potrebbe essere in grado di dedurre quali password cambi.

Quindi, se decidi di memorizzare il tuo database delle password in un cloud pubblico,

  1. Scegli un algoritmo di crittografia potente, resistente alla crittoanalisi differenziale. Assicurati che ogni password nel database sia salata individualmente.

  2. Cambia la password principale regolarmente, preferibilmente tutte le volte che fai con la tua password più preziosa.

  3. Non riutilizzare le password.

#7
+4
user172957
2018-03-15 02:13:27 UTC
view on stackexchange narkive permalink

Suggerirei una soluzione che coinvolga quanto segue:

  • File di database KeePass archiviato sul computer locale con crittografia Full Disk (es. Veracrypt)
  • File di chiavi KeePass archiviato su un disco USB esterno
  • Cloud Storage 1 (es. Dropbox) per conservare il file di database
  • Cloud Storage 2 (es. Google Drive) per conservare un backup del file chiave
  • Abilita 2FA su entrambi gli account Cloud Storage (app di autenticazione mobile preferibile ai codici di messaggi di testo)

Come tutti hanno detto, avere una password principale complessa per il tuo file di database è molto importante per contrastare il bruto forza gli attacchi. Ma se lo combini con un file di chiave, diventa praticamente impossibile eseguire la forza bruta.

Se Cloud Storage 1 è compromesso, il file di database stesso senza il file di chiave sarà impossibile da forzare, a meno che c'è una grave vulnerabilità di sicurezza nell'implementazione della crittografia di Keepass.

Se Cloud Storage 2 è compromesso, il file della chiave stesso se inutile senza il file del database. È solo un'estensione della tua password principale, non contiene dati.

Direi che sarebbe altamente improbabile che entrambi gli archivi Cloud vengano compromessi contemporaneamente 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 (es. continui a dimenticare dove hai messo il maledetto disco USB), quindi archivia sia il file database che il file chiave sul computer locale. Tuttavia, in questo caso il computer locale diventa il punto debole, se compromesso, l'attaccante avrebbe accesso al file della chiave, quindi dovrebbe solo forzare brutemente la password principale sul database, quindi è meglio impostarne una forte. Sarebbe come non usare affatto un file chiave.

#8
+2
MikeB
2015-08-20 20:41:49 UTC
view on stackexchange narkive permalink

Se vuoi essere davvero serio, esegui Boxcryptor insieme a Dropbox. Boxcryptor crittografa tutto alla tua fine PRIMA dell'invio ai server di Dropboxs. Tutto ciò che è alla fine di Dropbox è un carico di cose crittografate. Il tuo database keepass finisce per essere crittografato doppiamente!

#9
+2
lokiys
2020-09-05 01:09:18 UTC
view on stackexchange narkive permalink

Personalmente utilizzo una password molto complessa di 35 caratteri mescolati con simboli e conservo il mio file DB su Google Drive. Se non tieni milioni di criptovalute o qualcos'altro che non puoi riavere dovresti stare bene. Quindi, anche se qualcuno ruberà il tuo Db e anche se qualcuno sarà in grado di crittografarlo (ne dubito fortemente) ci sono altri modi per proteggere i tuoi account e altre cose importanti. Io personalmente uso l'autenticazione a due fattori in ogni account relativo a Money e in ogni account importante, quindi è doppiamente sicuro da due lati. Penso di essere al sicuro. + durante la lettura di questo thread ho anche aumentato le mie iterazioni come suggerito da @Matrix, quindi ho aggiunto un altro livello di sicurezza. :) C'è un altro livello che aggiungerei se mi sentissi minacciato in qualche modo e si tratta di servizi come https://www.boxcryptor.com/en/ che crittografa in aggiunta i file nel tuo cloud.

Nota a margine: probabilmente KeePass genera un hash dalla password e quindi lo utilizza come chiave di crittografia simmetrica.Se è così, allora la tua password lunga rende difficile trovare il (attendi fino a quando non viene fuori un crack contro l'algoritmo di crittografia utilizzato da KeePass)
#10
+1
Kevin Keane
2015-08-03 07:45:19 UTC
view on stackexchange narkive permalink

Sono un forte sostenitore della difesa in profondità su questo.

Non importa quanto sia forte la tua password, è anche una che non può essere modificata.

Quindi, per proteggere il mio Keepass DB, sto usando tre livelli:

  • Il database ha una passphrase forte (non solo una password). Non sto utilizzando un file chiave perché, per me, il rischio di perdere il file chiave supera i vantaggi per la sicurezza.
  • Il database è archiviato su un file system crittografato (sto usando encfs. Di per sé, ovviamente si è dimostrato insicuro, ma aggiunge ancora un livello di protezione).
  • La versione crittografata viene caricata su un server cloud, in esecuzione sul mio hardware e, ovviamente, su HTTPS.

Sul motivo per cui la password non può essere cambiata: ovviamente puoi cambiare la password, e in realtà ricodificherà il database Keepass, ma non puoi cambiarla retroattivamente su vecchie copie.

Soprattutto (ma non solo) se archivi il database nel cloud, devi presumere che un avversario si sia impossessato del database in un momento precedente, con una vecchia password . Questo potrebbe fornirle le informazioni che sta cercando.

Ti consiglio davvero di caricare il tuo keyfile hide come altro tipo di file, in modo che nessuno possa capire che è la tua chiave. Il file di chiavi ha lo scopo di aggiungere una barriera fisica, non dovresti mai mettere il file di chiavi all'interno della stessa unità / servizio del database. Perdere la tua chiave è come dimenticare la password, quindi non capisco davvero perché ne hai paura. Di solito, usare la chiave è solo più "lavoro" per aprire i file, ma aggiunge MOLTA sicurezza in più.
@erm3nda A meno che il tuo file di chiavi non sia effettivamente un file valido in un altro formato di file, sarebbe piuttosto facile da trovare.
Questo è vero in una certa misura.Puoi nascondere le cose in molti modi, potresti anche creare un binario con intestazioni exe reali, quindi dividere quella parte quando leggi i tuoi dati binari, che è la tua chiave.Questo argomento è per niente così ampio ... ma grazie per il tuo commento: D
#11
  0
globetrotter
2016-07-04 02:08:23 UTC
view on stackexchange narkive permalink

Un'altra opzione: usa il cloud solo per trasferire il tuo database sul tuo prossimo dispositivo e poi cancellalo dal cloud storage. Ciò esporrebbe il 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 livello di sicurezza richiesto.

#12
  0
G DeMasters
2018-10-24 13:06:48 UTC
view on stackexchange narkive permalink

Dico di andare con la soluzione cloud "crittografata sul client" di tua scelta, crittografa con il maggior numero di iterazioni PBKDF2 con cui ti trovi a tuo agio, il file di chiavi più grande con cui puoi convivere e, soprattutto, archivia le informazioni che tieni vicino a te ( localmente) su un'unità AUTOCRIPTANTE Se necessario, aggiungi un filesystem crittografato, ma la crittografia dei dati che sono soggetti a perdita o furto, come un'unità USB, deve essere automatica.

#13
-4
mathigami
2014-09-20 21:45:15 UTC
view on stackexchange narkive permalink

Se un gruppo è in grado di compromettere un servizio cloud abbastanza da scoprire che hai un kdb da violare, potrebbe essere più motivato a installare un key logger / root kit sui tuoi dispositivi personali. Ovviamente, se un tale gruppo può vederti mentre scarichi il software da sourceforge o da un app store, ottiene informazioni simili. In effetti, questo post è un suggerimento molto più semplice, quindi la preoccupazione per questo vettore di attacco potrebbe essere per gli individui più paranoici di noi.

Non sono sicuro che questa sia una risposta.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...