Per rispondere a questa domanda, ci deve essere una migliore definizione di "sicuro" e / o "sicuro". Deve sempre essere definito alla luce dello scopo della protezione e del rischio per il sistema. Non c'è una taglia che vada bene per tutti qui, ciò che è "abbastanza sicuro" per un sistema, può essere estremamente debole per un altro. E ciò che è "abbastanza sicuro" su un altro può essere un costo proibitivo o addirittura poco pratico in un caso diverso.

Quindi, prendendo le preoccupazioni tipiche una per una:

• Riservatezza : marginale nella migliore delle ipotesi. La riservatezza è generalmente valutata in termini di tempo necessario per ottenere l'accesso al materiale protetto. Potrei essere in grado di modificare il file zip, ma come hacker mi ci vorrà un po 'di tempo per decifrare la password o forzarla. Non molto tempo, le password sono una delle protezioni più deboli e, dato il modo in cui i file zip sono spesso condivisi, il modo in cui si fa l'ingegneria sociale per la password di solito non è difficile.

• Integrità - no - come fa notare il richiedente - è facile cambiare il pacchetto e farlo sembrare legittimo.

• Disponibilità - generalmente non applicabile a questo tipo di controllo di sicurezza - questo di solito si riferisce al rischio di rendere un servizio non disponibile - l'archiviazione / confezionamento dei dati di solito non influisce sulla disponibilità in un modo o nell'altro.

• Non ripudio - no, nessuna protezione - chiunque può modificare il pacchetto, quindi chiunque contribuisca ha una probabile negabilità.

Il trucco è: quanto di meglio vuoi ottenere? L'email crittografata è un'opzione, come protezione migliore. Anche se pone problemi di connettività. E ci sono molti modi migliori per crittografare i dati, ma le opzioni migliori comportano anche sfide di distribuzione chiave che possono aggiungere problemi di tempo e costi.

Come un modo rapido per impacchettare e condividere alcuni dati che non vuoi rendere completamente pubblici - è meglio di niente, ea volte è l'unico denominatore comune che puoi elaborare. Per qualsiasi cosa ad alto rischio, troverei un'opzione migliore.

La password ha lo scopo di garantire la riservatezza, non l'integrità o l'autenticità.

Questo è uno di quei casi in cui la sicurezza è limitata dall'usabilità e dalle intenzioni umane. Il gestore dell'archivio non ha modo di sapere se il file modificato doveva essere crittografato in primo luogo. Essenzialmente si tratta di un attacco di ingegneria sociale, in quanto hai indotto l'utente a credere che il file originale fosse a posto. Tuttavia, la vera vulnerabilità di sicurezza sarebbe che tu avessi accesso in lettura / scrittura a un archivio sensibile in primo luogo.

Per quanto riguarda la mitigazione, ci sono alcuni modi per aumentare la sicurezza:

• Utilizza un formato di archivio che supporti la crittografia del nome file (ad es. 7Zip, RAR)
• Firma l'archivio con una chiave privata, ad es. tramite GPG.

No. Per creare un file crittografato (in modo non sicuro poiché la password viene ripetuta):

  $ cd - "$ (mktemp --directory)" $ echo secret > 1.txt $ echo super secret > 2 .txt $ zip -e -P dIg4BuOTFh secret.zip 1.txt 2.txt aggiunta: 1.txt (memorizzato 0%) aggiunta: 2.txt (memorizzato 0%)  

A scopri quali file sono inclusi:

  $ unzip -l secret.zipArchive: secret.zip Lunghezza Data Ora Nome --------- --------- - ----- ---- 7 2013-05-14 10:15 1.txt 13 2013-05-14 10:14 2.txt --------- ------- 20 2 file  

Per sovrascrivere un file con dati falsi senza conoscere la password:

  $ echo lie > 2.txt $ zip -u secret.zip 2.txtupdating: 2.txt (memorizzato 0%)  

Verifica:

  $ unzip -o -P dIg4BuOTFh secret.zipArchive: estrazione secret.zip : Estrazione 1.txt: 2.txt $ cat 2.txtlie  

man zip non menziona n questo avvertimento nella descrizione dell'opzione -e , ma quanto segue è dalla documentazione di -P:

(E dove la sicurezza è veramente importante, usa una crittografia forte come Pretty Good Privacy invece della crittografia standard relativamente debole fornita dalle utility zipfile.)

La crittografia debole nota dovrebbe essere rimossa dall'utilità per evitare un falso senso di sicurezza, ma questa è un'altra storia.

Non è sicuro nel senso che non puoi dipendere dall'integrità del file zip. La riservatezza è ancora in ordine poiché non è possibile accedere ai contenuti dei file (solo i nomi dei file).

Questo inconveniente in zip è stato discusso in precedenza, personalmente uso sempre rar proprio a causa di questo problema. Un'altra soluzione alternativa sarebbe firmare il file zip con PGP.

Oltre ai rischi che hai già indicato, IMHO uno dei maggiori problemi con gli strumenti di compressione è legato all'uso di cartelle temporanee per archiviare i file non compressi. Poiché i file di input possono essere di dimensioni arbitrarie, i file di output non compressi potrebbero non essere contenuti nella RAM. Viene utilizzata una cartella di output temporanea (spesso quella predefinita del sistema operativo).

Quindi non importa quanto sia potente l'algoritmo di crittografia se dimentichi di distruggere correttamente le cartelle temporanee ogni volta che decomprimi un file protetto da psw. La maggior parte degli strumenti non pulisce automaticamente la directory di output né avvisa l'utente in merito. Stessa cosa durante la compressione: assicurati di distruggere il file originale.

Se dovessi usare la definizione generale di sicuro per indicare che applica privacy, autenticazione, integrità e non ripudio, direi che non è sicuro per un certo numero di punti. Ma poiché la protezione tramite password su un file ZIP crittografato intende fornire solo la privacy (impedendo la visualizzazione del contenuto di un file tranne che dalle parti previste), direi che fa il suo lavoro.

La specifica del formato .ZIP ufficiale consente di nascondere l'elenco dei nomi di file (ma non il numero di file), oltre a nascondere i metadati come la dimensione del file originale e il CRC del file originale. Ma non puoi usare WinZip o Info-Zip per farlo. Inoltre, l'integrità nelle specifiche ufficiali .ZIP viene fornita attraverso l'uso di una o più firme digitali oltre alla crittografia. La mia raccomandazione personale, tuttavia, è di evitare le password e invece di utilizzare le chiavi pubbliche. Le funzioni di derivazione chiave stanno diventando sempre più veloci e non credo che nessun fornitore abbia nemmeno provato a tenere il passo.

Se si dispone di una versione non crittografata di uno dei file in uno zip protetto da password, è possibile utilizzare un attacco in chiaro noto per ottenere la password per tutti gli altri file.

Quindi la conclusione è che, a meno che non ci sia una vulnerabilità o una backdoor nel codice di crittografia, è sicuro quanto la tua passphrase è resistente agli attacchi di forza bruta. Esistono vari siti su Internet in cui è possibile prototipare lo schema che si intende utilizzare, per verificare approssimativamente quanto tempo ci vorrebbe per decifrare. (Non usare QUELLO che intendi usare)

Tutto ciò a cui chiunque può accedere fisicamente è crackabile, dato abbastanza tempo. Tuttavia, puoi avere una sicurezza pratica se il costo e / o il tempo necessari per accedere alle informazioni supera il loro valore probabile. A meno che non si tratti di informazioni finanziarie, spesso c'è una grande differenza tra ciò che è prezioso per un hacker e ciò che è prezioso per te. Se il nome del file all'interno dello zip è Allegato_1 e il contenuto non crittografato dell'e-mail non descrive il contenuto dell'allegato, non dà molto a un hacker su cui basarsi. È improbabile che un hacker sia disposto a spendere molto tempo, e certamente non denaro, per ottenere l'accesso a qualcosa che non ha un'elevata probabilità convincente di contenere qualcosa di valore per lui.

Non tutto ciò che è protetto da password può essere violato da attacchi di forza bruta. Tuttavia, i file zip possono essere violati dalla forza bruta. Altri sistemi dispongono di controlli, come ad esempio blocco dopo tre tentativi, verifiche passkey ecc.

Ho sentito parlare di modi in cui i file zippati protetti da password possono essere violati. Di solito con attacchi di forza bruta, quindi in breve non sono molto sicuri per i dati riservati segreti di &.