How secure is a Windows password protected zip file?

Question

I need to send some sensitive information to a client. I thought I would email a password protected zip file I created using Windows XP and then call them with the password. Presuming I pick a good password, how secure is this approach? Specifically, how difficult is it to decrypt a password protected zip file?

Answer 1

If you want an alternative to Windows zip, consider 7-Zip. It's open source, and uses AES-256 (which is very unlikely to be broken any time soon :) It can also compress to .zip format, so anyone can read it.

Note - I just double-checked, and Windows XP's built-in zip can not decrypt AES. However, it's possible to use 7-Zip to make a self-extracting .exe file, so your client doesn't need the actual software.

Answer 2

It isn't that hard to decrypt a password protected ZIP file. There's plenty of apps out there to either figure out the password or just remove the password.

Odds are that no one will be intercepting the email between you and them. Public email servers have a massive amount of data flowing between them. Putting a password on the email is probably good enough. If you need something more secure then look at encrypting the email that the attachment is sent through, or post the file to a secure drop location like drop box (yes I'm aware of the issue they had a couple weeks ago) and send them the link.

Answer 3

With dual GTX 295s a 4-char password can be recovered in under an hour.

http://is.hut.vn/~phongph/uploads/publications/1277074631.pdf

Answer 4

For sensitive data, I'd be a little reluctant to use password-protected ZIP or 7ZIP archives. The current versions of encryption they use has not been well-studied or vetted by independent researchers. Older versions of the software had security weaknesses, which is mild cause for concern. The newer versions might be OK, but since they haven't been independently reviewed, I'm reluctant to place a lot of trust in them. Ideally, something like GPG or PGP is better.

Please be warned that encrypting with a password tends to be weak. Most people choose passwords that do not have enough entropy to be secure against offline search (e.g., dictionary attack, exhaustive search). Moreover, long and strong passwords are inconvenient to use, providing a further disincentive against them.

I recommend that you avoid sending people self-extracting .exe files. That is a security risk. When you send people self-extracting .exe files, you are training them to receive a .exe attachment by email and run it. That is very dangerous practice, from a security perspective. I think the fact that ZIP and 7ZIP encourage this practice is a sign of disregard for security.

If you must use password-based encryption, I recommend: Use GPG or PGP (e.g., gpg -c). The security of GPG's encryption has been well-studied and is strong. Use a long, strong password: e.g., use a utility to generate a cryptographically random password. You want a password that's about 14-16 random characters long, with no patterns whatsoever.

This is probably going to be the easiest option for your client to use, that also provides strong protection.

If you want extra security, store the encrypted data on a CD or DVD, and then send the CD or DVD by Fedex (rather than by email). That way, you get two layers of security: someone can steal the data only if they can get access to the CD or DVD, and if they have the password to decrypt it.

If your clients have trouble using PGP or GPG, you could use a recent version of ZIP or 7ZIP's password encryption. In that case, I would avoid a self-extracting .exe file and I would probably be more inclined to send the encrypted data through the mail (on a CD or DVD) rather than over the Internet.

Alternatively: If your client is technically savvy and you have frequent communications with them, another option is to have them use GPG or PGP to generate a random public keypair, send you their public key, and then you can encrypt data under their public key. This will provide stronger security, if they know how to use GPG or PGP. However, it is less intuitive and so probably not feasible for sending a piece of data to an average client.

Answer 5

I have used password protected zip files as an ad-hoc encryption mechanism (although I prefer to use GPG when possible). Much is made of password recovery for zip files, but as long as you are using a current version, the only practical recovery mechansim is brute force. I believe both 7-zip and Winzip both support AES-256. If you client already has Winzip, I would use that (just make sure you use AES and not "Legacy" encryption).

The most important aspect of using this is your password (I would recommend a passphrase, at least 16 characters, throw in some special characters). The passphrase has the advantage that brute force is difficult, and you can exchange it over the phone with relative ease.

This is not a perfect mechanism by any means, but it could be good enough for your purposes (depending on the sensitivity of data).

Answer 6

When creating a password-protected Zip file (with the "compressed folder" utility integrated in the OS), Windows XP uses the "standard" encryption algorithm for Zip files. This is a homemade stream cipher, and it is weak. With 13 bytes of known plaintext, the complexity of the attack is about 2³⁸ operations, which is doable in a few hours on a PC. 13 bytes are relatively easy to obtain (e.g. if one of the files in the archive is an image, it will probably be uncompressed and begin with a known header). The result has even been improved, notably because the files in an archive are encrypted separately but without proper key diversification. Some years ago (quite a few now, tempus fugit), I have seen a password cracking software by Ivan Golubev which put this science to good use, and could crack Zip encryption in an hour.

The attack on Zip encryption is actually:

• a nice introduction to cryptanalysis;
• a good exercise in programming;
• a reminder that you should not roll your own crypto. Phil Katz was very good in his domain, but the best cryptographers in the world will tell you that it takes much more than one extremely good cryptographer to make a secure algorithm -- it takes many cryptographers who feverishly propose designs and try to break the designs of the others, for a few years, until a seemingly robust design emerges (where "robust" means "none could find the slightest argument to support the idea that they may, possibly, make a dent in it at some unspecified date").

---

Now, if you use a tool which supports the newer, AES-based encryption, things will look better, provided that the format and implementation were not botched, and the password has sufficient entropy. However, such Zip files will not be opened by the stock WinXP explorer.

If an external tool is required, you might as well rely on a tool which has been thoroughly analyzed for security, both in the format specification and the implementation; in other words, as @D.W. suggests: GnuPG.

---

As for self-decrypting archives, they are all wrong, since they rely on the user doing exactly what should never be done, i.e. launching an executable which he received by email. If he does open a self-decrypting archive you send him, then he will just, by this action, demonstrate that he is vulnerable to the myriad of virus/worms/whatevers which roam the wild Internet, and he is probably already infected with various malware, including keyloggers.

Nevertheless, there is a way, in your specific situation, to make a self-decrypting archive reasonable. It still needs your client to install a new piece of software, but at least it is straight from Microsoft: the File Checksum Integrity Verifier -- a pompous name for a tool which computes file hashes. Send the self-decrypting archive to your client, and have him save it as a file (without executing it, of course). Then, have him run FCIV on it, to get the SHA-1 hash of the file. Do the same on your side. Finally, compare the two hashes by phone (it is not hard to dictate 40 hexadecimal characters). If the two hashes match, then your client will know that the file was not modified during the transfer, and he will be able to execute it with confidence.

(That is, if your client trusts you, and trusts that your machine is not clock full with virus which could have infected the archive on its way out.)