Crashplan + TrueCrypt - Overkill?


9

Crashplan ha già un'opzione per crittografare i dati. E se selezionato, questo memorizza il file crittografato sul server.

Truecrypt ha sicuramente molte più opzioni, ma per un utilizzo di base non sarebbe sufficiente la crittografia di CrashPlan?

Aggiornamento : dopo aver provato CrashPlan, non sono sicuro che detta crittografia sia qualcosa di reale. Certo, crea un file contenitore che non è possibile aprire e cercare, ma se si accede al sito Web di CrashPlan, è possibile:

  • vedere l'intera struttura delle cartelle
  • vedere i singoli file
  • ripristinare singoli file o gruppi di file nel modo desiderato.

La crittografia dovrebbe essere un traffico a senso unico, se i dati sono disponibili in bella vista, non sono sicuro che si tratti di crittografia. Forse codificato ma non crittografato. Mi sto perdendo qualcosa qui?


Suppongo che dipenda da quanto sei paranoico. Ti interessa se Crashplan può decrittografare i tuoi dati? In tal caso, utilizzare TrueCrypt.
Aaron Miller,

1
Se Crashplan può decifrare senza la mia password e / o chiave, allora non è una vera crittografia, vero?
Mrchief,

1
@AaronMiller - Crashplan per impostazione predefinita crittografa tutti i dati caricati. Questa crittografia si basa sulla password dell'utente. Puoi anche crittografare i file che carichi utilizzando una password che non trasmetti mai a Crashplan, rendendo impossibile la decrittografia del file tramite Crashplan.
Ramhound,

1
Vedi support.crashplan.com/doku.php/faq/security dove indicano "non c'è assolutamente alcun modo per aiutarti a recuperare una password di archivio a cui non siamo mai a conoscenza." e "se perdi o dimentichi la tua chiave di crittografia, i tuoi dati di backup non possono essere recuperati e il supporto di CrashPlan non può aiutare con il recupero."
James,

1
Penso che quello che stanno dicendo sia che la crittografia viene eseguita fondamentalmente da una chiave privata (simile a quando ne generi una per SSH) e che se usi la chiave che forniscono (unica per il tuo account), mantengono una copia della chiave e può invertire la crittografia purché si ricordi la password. Se usi una chiave che hai creato e la perdi, non possono aiutarti ...
James,

Risposte:


12

Informativa: sono CEO e socio fondatore di Code42

È eccessivo. A peggiorare le cose, rallenterà i tuoi backup e ritarderà la protezione dei dati poiché il monitoraggio in tempo reale non funzionerà e i dati crittografati non saranno comprimibili.

Utilizzando la password di dati privati ​​(consigliata) o generando la propria chiave, si garantisce la privacy. (Sì, devi fidarti di noi nel dire questo, ma se non sei un esperto di software / sicurezza che studia / verifica personalmente il codice TrueCrypt, devi fidarti di qualcosa / qualcuno.

Se disponi di dati così preziosi da non fidarti di nessuno, è ragionevole raddoppiare la crittografia. Tuttavia, lo farei solo per quel set di dati specifico: lascia che CrashPlan gestisca il resto.


La tua risposta sembra farti venire da Crashplan. È così?
Mrchief,

Se sei un dipendente di CrashPlan, ti preghiamo di rivelare la tua affiliazione come richiesto dal faq .
Afrazier

5
Forza ragazzi. Perchè chiedere? Google lui. Matthew Dornquast è lo stesso Mr. CrashPlan. Il fondatore del codice 42, che sono i creatori di CrashPlan e vari altri prodotti. Interesse acquisito? Beh, le sue risposte sono sempre e solo su CrashPlan e potrebbe essere un po 'di parte (per qualche ragione sconosciuta!), Ma non dirmi che non pensi che sia bello che i CREATORI di prodotti siano anche su questo sito. Probabilmente conosce quel prodotto meglio di chiunque altro! minnpost.com/politics-policy/2011/08/…
Austin '' Danger ''

1
Ah! L'umile Mr. Crashplan !! Punta del cappello enorme dallo sviluppatore dentro di me. Prendo finalmente il tuo consiglio!
Mrchief,

4
Mi dispiace, "Fidati di noi" non è mai la risposta giusta quando si tratta di crittografia.
Michael Kohne,

4

Sono un utente TrueCrypt, ma se stavo usando CrashPlan eviterei sicuramente di crittografare i miei dati con un altro prodotto prima di inviarli a CrashPlan per gestirli, quindi spingere su Internet (poiché le prestazioni molto probabilmente andrebbero da buone -> dolorose). Se si crittografa una cartella da 1 GB, che contiene numerosi piccoli documenti di Word, improvvisamente tutto ciò che si ha è un blob omogeneo di dati da 1 GB che non può essere gestito in modo efficiente dal software di backup. Quindi, se aggiungi un singolo periodo in più a uno di quei documenti di Word, quindi ri-salva, il tuo file di archivio TrueCrypt ora è INTERAMENTE diverso e l'intero oggetto deve essere nuovamente sottoposto a backup. Sarei propenso a fidarmi della crittografia di CrashPlan (devi fidarti della crittografia di questi servizi o trovarne uno di cui ti fidi). Se avessi un piccolo file di testo con password di amministratore di dominio e puoi " dormire di notte senza crittografarlo due volte, va bene, ma dovresti evitare qualsiasi file crittografato di massa (TrueCrypt o altro) poiché l'impatto sulle prestazioni sarà un aumento della larghezza di banda della rete e backup molto più lenti - tutto per un aumento della sicurezza che (probabilmente) non è necessario. Se sei un avvocato o hai informazioni di carattere medico, potresti avere l'obbligo legale di crittografare due volte, o forse puoi ottenere una sorta di rassicurazione legale dal codice 42 che la crittografia può essere considerata attendibile per quel tipo di dati ( forse avresti il ​​dovere di farlo in una situazione del genere, non sono sicuro- non ho ancora trovato personalmente questo tipo di dati sul lavoro). Se stavi utilizzando Dropbox (una società che ammette che il 5% dei propri dipendenti ha accesso ai dati memorizzati dagli utenti al fine di mantenere e risolvere i problemi!

O la risposta breve:

... sì, probabilmente è eccessivo.


L'aggiunta di un 'punto' non cambierà l'intero file. Pochi blocchi nella migliore delle ipotesi e Crashplan caricherà solo quei blocchi. Il backup della prima volta sarà lento, ma in seguito avrà un impatto trascurabile (a meno che non scarichi giga o tera byte di dati ogni giorno).
Mrchief

3

Risposta breve

Probabilmente sì, a meno che tu non sia un obiettivo di alto profilo.

Risposta lunga

CrashPlan crittografa i dati utilizzando certificati protetti da password o nessuna crittografia. In questo riepilogo, puoi pensare a un certificato come sostanzialmente un'enorme password che si trova in un file con il tuo nome allegato. Questo file di certificato è comunemente crittografato, solo per garantire che una copia rapida del file non sia sufficiente per accedere ai dati: è necessaria anche la password del file di certificato.

La maggior parte degli utenti di CrashPlan probabilmente usano quella che viene chiamata archiviazione dei certificati di deposito a garanzia, dove Code42 memorizza i file dei certificati per te in forma crittografata. Quando si fornisce la password, questi file di certificato vengono decifrati e quindi utilizzati per decrittografare i dati non elaborati. Questo è il motivo per cui l'interfaccia web di CrashPlan può permetterti di sfogliare i tuoi dati - dopo aver fornito la password del certificato, il loro software può accedere ai dati usando il certificato. I principali buchi di sicurezza con questo:

  • Ti fidi dei dipendenti Code42 + per conservare il tuo certificato in modo sicuro
  • Ti fidi dei dipendenti Code42 + di non archiviare mai in modo sicuro la password del certificato
  • Ti fidi dei dipendenti di Code42 + di non fornire il file del certificato o la password a qualsiasi agenzia (come un governo) che lo richieda (ad esempio, una citazione)
  • Come accennato in precedenza, il tuo certificato è una password molto grande . Se qualcuno mette le mani su quel file, l'unica cosa che impedisce loro di usarlo è la password del certificato, quindi se lo hai creato hunter42sei piuttosto fregato. Fondamentalmente, rompere la password del certificato è probabilmente abbastanza facile se qualcuno è davvero motivato e non hai scelto una buona password.

È inoltre possibile utilizzare una "chiave personalizzata" (ad es. Quando si fornisce il file del certificato). Ciò significa che Code42 non memorizza il proprio certificato sui propri server. Conservano ancora i dati crittografati sui loro server, ma se si desidera vederli nell'interfaccia Web, è necessario fornire al proprio software sia il file del certificato che la password del certificato. Ora ecco la parte strana: questo non offre quasi nessuna sicurezza aggiuntiva realistica rispetto all'opzione sopra, è principalmente utile per un sistema con molti account utente che si desidera mantenere separati. Tu ancora:

  • Affidati all'applicazione CrashPlan di non archiviare o trasmettere il file del certificato o la password del certificato
  • Affidati a Code42 per non tentare di archiviare questi dati

Il vantaggio principale qui è che Code42 non può rispondere a una richiesta esterna per il tuo certificato con la stessa facilità con cui se utilizzi certificati di deposito a garanzia, dovrebbero istruire intenzionalmente l'applicazione CrashPlan locale per recuperare la chiave del certificato dal tuo computer e consegnarglielo . Questo sarebbe naturalmente un grosso rischio per loro a causa del fallout commerciale se una tale decisione diventasse di dominio pubblico.

Un altro punto rilevante: apparentemente memorizzano sempre il file del certificato in forma non crittografata sul computer locale. Quindi, se sei un target di alto profilo, è possibile che qualcuno possa acquisire i tuoi dati crittografati da CrashPlan e quindi eseguire un semplice attacco sul tuo personal computer per recuperare il file di certificato non crittografato.

Quindi la risposta alla tua domanda si riduce a "ti fidi di Code42 con la protezione dei tuoi dati da minacce sia interne che esterne?" Se la risposta è no, crittografare i dati usando qualcosa come TrueCrypt come secondo livello di protezione è un'ottima idea.

PS - Per quello che vale, adoro il fatto che CrashPlan crittografi abbastanza pesantemente per impostazione predefinita, quindi non interpretarlo come un pessimo post di CrashPlan - Voglio solo aiutare gli utenti a capire di chi si fidano :-)


2

Un'alternativa interessante potrebbe essere usare EncFS , in particolare con il flag --reverse . Apparentemente c'è una porta per Windows, quindi potresti essere in grado di fare la stessa cosa lì.

   --reverse
       Normally EncFS provides a plaintext view of data on demand.  Normally it stores enciphered
       data and displays plaintext data.  With --reverse it takes as source plaintext data and pro-
       duces enciphered data on-demand.  This can be useful for creating remote encrypted backups,
       where you do not wish to keep the local files unencrypted.

       For example, the following would create an encrypted view in /tmp/crypt-view.

           encfs --reverse /home/me /tmp/crypt-view

       You could then copy the /tmp/crypt-view directory in order to have a copy of the encrypted
       data.  You must also keep a copy of the file /home/me/.encfs5 which contains the filesystem
       information.  Together, the two can be used to reproduce the unencrypted data:

           ENCFS5_CONFIG=/home/me/.encfs5 encfs /tmp/crypt-view /tmp/plain-view

       Now /tmp/plain-view contains the same data as /home/me

       Note that --reverse mode only works with limited configuration options, so many settings may
       be disabled when used.

MODIFICA - Assicurati di salvare i tuoi file .encfs5 o encfs6.xml, si troveranno nella directory di testo normale originale e non nella directory di backup, quindi dovrai essere sicuro di afferrarli quando non sarai in grado di recuperare il tuo file crittografati senza di essi. (sarebbe bello se encfs includesse quelli con i file crittografati in modo da poter creare un archivio di backup autonomo)


Davvero interessante! Sai quali sono i normali numeri delle prestazioni di lettura / scrittura? L'uso di eCryptFS sul mio Synology NAS ha ridotto le prestazioni fino al 50%.
Mrchief,

Non sono sicuro, anche se ci si potrebbe aspettare che le prestazioni siano simili. Dipenderebbe anche dall'algoritmo di crittografia che stai utilizzando e dalla dimensione della chiave. Sono andato con l'opzione standard con la mia. Vale anche la pena notare che se si desiderano nomi di file in chiaro e capacità di deduplicazione, è possibile farlo modificando alcune opzioni quando si crea per la prima volta il volume crittografato.
jonmatifa,

Simile alla velocità non crittografata o ridotta? Se hai qualche numero, sarebbe di grande aiuto.
Mrchief,

0

A meno che tu non disponga di informazioni sul tuo PC relative a un brevetto multimilionario, i documenti relativi ad azioni legali (come una causa legale) o di avere informazioni classificate sulla crittografia del crashplan del tuo PC dovrebbero essere sufficienti.

Se la posta in gioco è abbastanza alta, gli hacker potrebbero essere assunti per forzare la tua password.


0

Il problema a mio avviso è la velocità / efficienza rispetto alla sicurezza. Crittografando con Truecrypt prima gli aggiornamenti saranno probabilmente lenti e inefficienti come precedentemente menzionato. Tuttavia, dopo Snowden, l'altro problema è che anche se crei la tua chiave personalizzata da una password complessa devi fidarti che questa non sarà mai trapelata. Per caso o perché l'NSA ha costretto la società americana proprietaria di Crashplan a inserire un meccanismo per farlo. La crittografia sul client locale è un punto positivo, ma a meno che tu (o piuttosto la community in generale) non riesca a vedere il codice client, non c'è modo di essere sicuro che la tua chiave, e quindi i tuoi dati, siano al sicuro.

Sebbene non segua la rigorosa teoria del backup 3-2-1, userò un HDD crittografato offsite popolato usando rsnapshot e ruotato regolarmente con altre copie. Ho considerato Crashplan su tutte le altre opzioni cloud, ma la natura non verificabile del client mi ha scoraggiato. Se avessero un'API e il FEP o altra fonte FOSS fornissero il client, riconsidererei.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.