Are password-protected ZIP files secure?

To answer this, there needs to be a better definition of "secure" and/or "safe". It's always got to be defined in light of the purpose of the protection and the risk to the system. There's no one size fits all here, what's "safe enough" for one system, may be abysmally weak on another. And what's "safe enough" on another may be cost prohibitive or down right impractical in a different case.

So, taking the typical concerns one by one:

  • Confidentiality - marginal at best. Confidentiality is usually rated in terms of how long it will take to gain access to the protected material. I may be able to change the zip file, but as a hacker it'll take me some amount of time either crack the password or brute force it. Not a lot of time, passwords are one of the weaker protections, and given the way zip files are often shared, social engineering one's way to the password is usually not hard.

  • Integrity - nope - as the asker points out - it's easy to change the package and make it look legitimate.

  • Availability - generally not applicable to this sort of security control - this usually refers to the risk of making a service unavailable - the data storing/packaging usually doesn't affect availability one way or the other.

  • Non repudiation - nope, no protection - anyone can modify the package, so anyone contributing to it has probable deniability.

The trick is - how much better do you want to get? Encrypted email is an option - as a better protection. Although it poses it's own connectivity concerns. And there's many better ways to encrypt data - but the better options also involve key distribution challenges that can add time and cost concerns.

As a quick way to package and share some data that you don't want to make completely public - it's better than nothing, and it's sometimes the only common denominator you can work out. For anything high-risk, I'd find a better option.


The password is meant to ensure confidentiality, not integrity or authenticity.

This is one of those cases where security is limited by usability and human intent. The archive manager has no way of telling whether or not the file you modified was meant to be encrypted in the first place. Essentially this is a social engineering attack, in that you tricked the user into believing that the original file was in place. However, the real security vulnerability would be that you had read/write access to a sensitive archive in the first place.

As far as mitigation goes, there are a few ways to increase security:

  • Use an archive format that supports filename encryption (e.g. 7Zip, RAR)
  • Sign the archive with a private key, e.g. via GPG.

No. To create an encrypted file (insecurely since the password is echoed):

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

To find out which files are included:

$ unzip -l secret.zip
Archive:  secret.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        7  2013-05-14 10:15   1.txt
       13  2013-05-14 10:14   2.txt
---------                     -------
       20                     2 files

To overwrite a file with fake data without knowing the password:

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

Verify:

$ unzip -o -P dIg4BuOTFh secret.zip
Archive:  secret.zip
 extracting: 1.txt                   
 extracting: 2.txt     
$ cat 2.txt
lie

man zip doesn't mention this caveat in the description of the -e option, but the following is from the documentation of -P:

(And where security is truly important, use strong encryption such as Pretty Good Privacy instead of the relatively weak standard encryption provided by zipfile utilities.)

Known weak encryption should be removed from the utility to avoid a false sense of security, but that's another story.

Tags:

Passwords

Zip

Recent Posts