2010-03-05 13 views
6

Abbiamo un'app client basata su server che salva i dati relativi all'utente in un file zip e imposta la passwd nel file zip in modo programmatico. Mi chiedo solo se potrebbe essere considerato sicuro. Grazie NFile zip con sicurezza passwd?

risposta

13

La crittografia "classico" per i file Zip è considerato debole. È fragile, rapidamente, con metodi noti. Vedi: "A Known Plaintext Attack on the PKZIP Stream Cipher" per la carta originale, di Biham e Kocher, del 1994. Sì, 16 anni fa.

Più recentemente ci sono stati altri exploit descritti, ad esempio, la carta Yet another Plaintext Attack on ZIP's Encryption Scheme (WinZIP) dice che un classico-zip file crittografato con 3 voci, e creato da WinZip, può essere violata in 2 ore su una "pentium". Questo è stato basato su un exploit di una debolezza nel generatore di numeri casuali allora attuale WinZip v9.0. Sono sicuro che andrebbe molto più veloce ora, sui processori attuali, ma allo stesso tempo, sono abbastanza sicuro che WinZip, ora alla v12.0, ha risolto questo problema nel loro generatore di numeri casuali. Tuttavia, anche senza l'exploit specifico su WinZip-v9, la crittografia ZIP classica rimane debole.

Questa debole crittografia zip che è stata violata è anche nota come "crittografia ZIP 2.0" o "crittografia PKZIP".

Molti moderni toolkit di avviamento postale supportano anche la crittografia AES di voci di avviamento postale. Questo è considerato come una forte crittografia, ed è abbastanza sicuro (** Vedi nota). WinZip, XCeed e DotNetZip sono tre di questi strumenti che supportano la lettura e la scrittura di file zip con questo livello di crittografia. Tra i tre, DotNetZip è l'unica opzione gratuita.

Non hai menzionato la libreria che usi per produrre il file zip a livello di programmazione. Se si utilizza DotNetZip, producendo un file ZIP AES criptato in C# è facile come questo:

using (var zip = new ZipFile()) 
{ 
    zip.AddFile("MySensitiveFile.doc"); 
    zip.Encryption = EncryptionAlgorithm.WinZipAes128; 
    zip.Password = "Very.Secret!"; 
    zip.Save("MyEncryptedArchive.zip"); 
} 

** Nota: Yoshi ha pubblicato un documento intitolato Attacking and Repairing the WinZip Encryption Scheme, descrivendo gesta di crittografia AES di WinZip per sostenere che la crittografia AES di WinZip non è sicura.Tuttavia, gli exploit che descrive si basano su social engineering o precedenti compromessi o su entrambi. Ad esempio, l'exploit principale descritto nel documento coinvolge un utente malintenzionato che intercetta il file zip crittografato, lo modifica, invia la copia modificata al destinatario previsto, induce il destinatario a tentare di decrittografarlo e quindi restituisce il risultato di tale crittografia a l'autore dell'attacco, che può quindi decrittografare il file originale. Questo cosiddetto "exploit" comporta numerosi salti di fede, accumulati sul precedente compromesso della comunicazione intercettata in entrambe le direzioni. Nessuno ha descritto alcun exploit strutturale di WinZip AES, alla pari degli exploit di ZIP classic encryption.

+0

ho la stessa situazione di base del PO ha e vogliamo essere sicuri che l'utente non può accedere alla zip file sulla macchina anche se il software gira sul loro computer. In questo caso, non possono semplicemente decompilare l'exectuable per ottenere il "Very.Secret!" parola d'ordine? Al momento siamo solo protetti da password con la crittografia "classica" e vogliamo iniziare a utilizzare DotNetZip. – CincinnatiProgrammer

+1

@PaulBrown - beh sì, questo è un rischio se si codifica la password nel programma che produce lo zip. Normalmente non è un problema. Nel tipico design, l'app per la creazione di zip richiederebbe all'utente una password, impiegherà tale password solo durante la creazione dello zip e quindi scarterà la password in seguito. In tal caso, decompilare l'exe non recupererebbe la password. Se non è possibile chiedere all'utente la password, è possibile sostituirla con un'altra fase analoga, ad esempio "chiedi" a un generatore di password remota, tramite una chiamata REST, per una password e utilizzala. – Cheeso

+0

"vogliamo essere sicuri che l'utente non possa accedere al file zip sulla macchina anche se il software gira sul loro computer" <- È impossibile. Finché il software contiene le informazioni necessarie per decodificare il file, l'utente può decodificare il file. – Antimony

0

Sicuro a quale livello? Ci sono programmi là fuori che possono rompere la crittografia della password su un file zip molto rapidamente, quindi se deve sopportare qualsiasi tipo di sforzo, allora no.

Se è solo una questione di garantire che qualcuno con una password può aprirlo e per tenere lontano gli occhi indiscreti casuali, allora forse.

Se si vuole avere un po 'a metà strada ragionevolmente sicurezza mi piacerebbe guardare in zippare il backup dei dati e quindi eseguire attraverso una corretta software di crittografia come gpg.

0

Si dovrebbe chiedere un paio di domande a te stesso.

  • Dove si memorizzano i file zip?
  • Quali autorizzazioni sono associate al file zip?
  • è la password una forte Password ?

Di solito, è una buona abitudine per memorizzare i dati degli utenti in una cartella che si trova fuori del webroot, non direttamente accessibili. I generatori di password sono anche disponibili e dovrebbero essere utilizzati.

2

uso 7zip, che ha una migliore sicurezza delle password - e anche selezionare l'opzione 'i nomi dei file crittografare'

+0

indebolisce l'archivio se i nomi file non sono crittografati? (eccetto che puoi vedere i nomi) – ItsmeJulian

+0

@Julianemailde nomi di file visibili possono dare indizi che potrebbero aiutare un attacco di stile di dizionario sui file stessi – SteelBytes