Devo inviare alcune informazioni sensibili a un cliente. Ho pensato di inviare un file zip protetto da password che ho creato utilizzando Windows XP e chiamarlo con la password. Presumendo che scelgo una buona password, quanto è sicuro questo approccio? In particolare, quanto è difficile decrittografare un file zip protetto da password?
Durante la creazione di un file Zip protetto da password (con l'utilità "cartella compressa" integrata nel sistema operativo), Windows XP utilizza l'algoritmo di crittografia "standard" per i file Zip. Questa è una codifica stream in casa ed è debole . Con 13 byte di testo in chiaro noto, la complessità dell'attacco è di circa 2 38 operazioni, che è possibile in poche ore su un PC. 13 byte sono relativamente facili da ottenere (ad esempio se uno dei file nell'archivio è un'immagine, probabilmente sarà decompresso e inizierà con un'intestazione conosciuta). Il risultato è stato anche migliorato , in particolare perché i file in un archivio sono crittografati separatamente ma senza un'adeguata diversificazione delle chiavi. Alcuni anni fa (alcuni adesso, tempus fugit ), ho visto un software per decifrare la password di Ivan Golubev che ha fatto buon uso di questa scienza e potrebbe crackare la crittografia Zip in un'ora.
L'attacco alla crittografia Zip è in realtà:
Ora, se si utilizza uno strumento che supporta la più recente crittografia basata su AES, le cose andranno meglio, a condizione che il formato e l'implementazione non siano stati compromessi e che la password disponga di sufficiente entropia. Tuttavia, tali file Zip non verranno aperti dal WinXP Explorer di riserva.
Se è necessario uno strumento esterno, si può anche fare affidamento su uno strumento che è stato accuratamente analizzato per sicurezza, sia nelle specifiche di formato che nell'implementazione; in altre parole, come @ D.W. suggerisce: GnuPG .
Per quanto riguarda gli self-decrypting archives , sono tutti sbagliati, poiché si basano sull'utente che fa esattamente ciò che non dovrebbe mai essere fatto, cioè a lanciare un eseguibile che ha ricevuto via email. Se fa apre un archivio auto-decrittante che gli mandi, allora, con questa azione, dimostrerà di essere vulnerabile alla miriade di virus / worm / whatevers che vagano per la selvaggia Internet, e probabilmente è già stato infettato da vari malware, inclusi i keylogger.
Tuttavia , c'è un modo, nella tua situazione specifica , per rendere ragionevole un archivio auto-decrittante. Ha ancora bisogno del tuo client per installare un nuovo software, ma almeno è direttamente da Microsoft: il Verificatore di integrità del checksum del file - un nome pomposo per uno strumento che calcola gli hash dei file. Invia l'archivio auto-decifrabile al tuo cliente e chiedigli di salvarlo come un file ( senza eseguirlo, ovviamente). Quindi, fagli eseguire FCIV su di esso, per ottenere l'hash SHA-1 del file. Fai lo stesso dalla tua parte. Infine, confronta i due hash per telefono (non è difficile dettare 40 caratteri esadecimali). Se i due hash corrispondono, il tuo client saprà che il file non è stato modificato durante il trasferimento e sarà in grado di eseguirlo con sicurezza.
(Cioè, se il tuo cliente si fida di te e crede che il tuo computer non sia pieno di virus che potrebbe aver infettato l'archivio mentre usciva.)
Per i dati sensibili, sarei un po 'riluttante a utilizzare archivi ZIP o 7ZIP protetti da password. Le attuali versioni della crittografia che usano non sono state studiate o esaminate da ricercatori indipendenti. Le versioni precedenti del software presentavano punti deboli di sicurezza, il che è motivo di preoccupazione. Le versioni più recenti potrebbero essere OK, ma dal momento che non sono state esaminate in modo indipendente, sono riluttante a riporre molta fiducia in esse. Idealmente, qualcosa come GPG o PGP è meglio.
Si noti che la crittografia con una password tende a essere debole. La maggior parte delle persone sceglie password che non hanno abbastanza entropia per essere sicure contro la ricerca offline (ad esempio, attacco dizionario, ricerca esauriente). Inoltre, le password lunghe e solide sono scomode da usare, fornendo un ulteriore disincentivo nei loro confronti.
Ti consiglio di evitare di inviare file .exe autoestraenti. Questo è un rischio per la sicurezza. Quando si inviano file .exe autoestraenti, li si sta addestrando a ricevere un allegato .exe tramite e-mail ed eseguirlo. Questa è una pratica molto pericolosa, dal punto di vista della sicurezza. Penso che il fatto che ZIP e 7ZIP incoraggiano questa pratica è un segno di disprezzo per la sicurezza.
Se è necessario utilizzare la crittografia basata su password, è consigliabile: utilizzare GPG o PGP (ad esempio gpg -c ). La sicurezza della crittografia di GPG è stata ben studiata ed è strong. Utilizza una password lunga e sicura: ad esempio, utilizza un'utilità per generare una password crittograficamente casuale. Vuoi una password che sia lunga circa 14-16 caratteri casuali, senza pattern di sorta.
Probabilmente questa sarà l'opzione più semplice da usare per il tuo client, che fornisce anche una protezione avanzata.
Se si desidera maggiore sicurezza, memorizzare i dati crittografati su un CD o DVD, quindi inviare il CD o il DVD tramite Fedex (anziché tramite e-mail). In questo modo, ottieni due livelli di sicurezza: qualcuno può rubare i dati solo se possono accedere al CD o DVD e se hanno la password per decrittografarlo.
Se i tuoi clienti hanno problemi con l'utilizzo di PGP o GPG, puoi utilizzare una versione recente di ZIP o la crittografia della password di 7ZIP. In tal caso, eviterei un file .exe autoestraente e probabilmente sarei più propenso a inviare i dati crittografati tramite posta (su un CD o DVD) anziché su Internet.
In alternativa: se il tuo cliente è tecnicamente esperto e hai frequenti comunicazioni con loro, un'altra opzione è di usare GPG o PGP per generare una coppia di chiavi pubbliche casuali, inviarti la loro chiave pubblica, e quindi puoi crittografare i dati sotto la loro chiave pubblica. Ciò fornirà maggiore sicurezza, se sapranno come usare GPG o PGP. Tuttavia, è meno intuitivo e probabilmente non è fattibile per l'invio di un dato a un cliente medio.
Non è così difficile decrittografare un file ZIP protetto da password. Ci sono un sacco di app là fuori per capire la password o semplicemente rimuovere la password.
Le probabilità sono che nessuno intercetterà l'email tra te e loro. I server di posta pubblici hanno una grande quantità di dati che scorre tra di loro. Mettere una password sull'e-mail è probabilmente abbastanza buono. Se hai bisogno di qualcosa di più sicuro, controlla la crittografia dell'e-mail con cui viene inviato l'allegato o postalo in una posizione sicura come una cassetta di sicurezza (sì, sono a conoscenza del problema che hanno avuto un paio di settimane fa) e inviale il link.
Ho usato i file zip protetti da password come meccanismo di crittografia ad hoc (anche se preferisco usare GPG quando possibile). Molto è fatto di recupero della password per i file zip, ma fino a quando si utilizza una versione corrente, l'unico meccanismo pratico di recupero è la forza bruta. Credo che sia 7-zip sia Winzip supportino entrambi AES-256. Se il client ha già Winzip, lo userei (assicurati di utilizzare AES e non la crittografia "Legacy").
L'aspetto più importante dell'utilizzo di questa è la tua password (ti consiglio una passphrase, almeno 16 caratteri, inserire alcuni caratteri speciali). La passphrase ha il vantaggio che la forza bruta è difficile e puoi scambiarla al telefono con relativa facilità.
Questo non è un meccanismo perfetto con qualsiasi mezzo, ma potrebbe essere abbastanza buono per i tuoi scopi (a seconda della sensibilità dei dati).
Leggi altre domande sui tag encryption file-encryption