Clay Tech

"clay-works make things real"

translated from clazytech.com

Password-protected ZIP files must be abolished

The other day, the Journal of Information Processing Society of Japan ran a special feature on this topic.

Around the same time, I found myself going through the following process with a certain large company:

– sending a password-protected ZIP with the extension changed to .zi_ – sending the password in a follow-up email

I ran into all kinds of trouble in that process (and honestly, who even uses email for this anymore), and the exhaustion of struggling just to receive a few kilobytes of data lined up perfectly with the timing of that feature.

Plenty of people have already written about why password-protected ZIPs are harmful, so this might feel a bit stale, but I want to lay it out simply enough that anyone can follow.

Here’s the short version of why it’s pointless:

Anyone who can intercept the attachment can also intercept the follow-up email carrying the password.

That’s the whole argument. Five seconds of thought gets you there. Even my second grader could probably follow it.

Sure, there are edge cases where only one of the two emails leaks for some reason (a misdirected send, say), and in that narrow case it does help.

But that’s not a security measure by any stretch. The business process itself needs rethinking.

Now let me explain, as concisely as I can, why it’s actually harmful.

– It slips past virus checks

A standard trick in password-protected ZIP workflows is changing the file extension from .zip to something like .zi_ or .a. This often lets the attachment slip past virus scanning entirely. “Slips past” doesn’t mean “no virus was found” — it means “we couldn’t tell what this was, so absolutely do not open it!!!” But people open it anyway. Because it’s an email from a business partner.

And spoofing the sender address, by the way, is basic-level stuff for anyone with bad intent.

So declaring “we send things as password-protected ZIPs” is essentially the same as saying “we’re going to render your company’s security measures meaningless, hope that’s fine (wink).” I doubt the people doing this even realize it.

– It can’t be opened on mobile

As mentioned, password-protected ZIP workflows usually involve changing the file extension. That means mobile devices usually can’t decompress the file at all, even if you know the password. Checking email on mobile while out and about is, for today’s working professional, generally something that improves work efficiency. Deliberately undermining that is a rather contemptible thing to do.

– It’s just depressing

It makes you feel the harshness of how society actually works.

I can picture the scene: the security staff at the company knew ages ago that this was pointless, but they keep running it reluctantly anyway, saying things like “it’s hard to change a system that’s already in place” or “management told us to do it.” It makes me feel the sheer irrationality of it all.

Next, let me talk about why password-protected ZIPs are believed to be a good thing. Plenty of people have adopted them, so there must be some grain of reasoning behind it.

For example:

– Having a “password entry” step keeps files from being opened carelessly

The logic goes like this: because of that step, someone who receives a misdirected email thinks, “Huh? From so-and-so? What is this file? Oh, it’s password protected,” which buys enough time for a follow-up like “Sorry, I sent that by mistake. Please delete the earlier file!”

Honestly, that’s just a “be more careful” argument.

Also, in practice, it’s rare for a company to protect only special emails with passwords. Almost always, every single email gets turned into a password-protected ZIP. In that case everyone just enters the password and opens the file without a second thought.

There are plenty of other practical countermeasures for misdirected sends, so this is a weak justification for using password-protected ZIPs specifically.

Another example:

– Sending the password through a separate channel makes it a security measure

This part is true. But how many people actually do this in practice?

Some companies use an “automatic password-ZIP system,” and of course the password gets sent in a follow-up email through that same system.

Even if you skip such a system and manually create a password-protected ZIP, then tell the recipient in a follow-up email that “the password is your company’s name,” anyone who hacked their way to the information obviously already knows that too. Something like “it’s your birthday” raises the bar a bit, but it’s not something that can’t be looked up — and besides, who even knows the birthday of some random guy at a business partner? And relaying something like “the password for that attachment is aXg2JGsGEsxhhjlesSO” over the phone is brutal from an operational standpoint.

The only thing that seems like it would actually work is if both parties mailed each other a cipher table in advance and derived the password from that, changing the table irregularly. Sounds like something the FBI or MI6 would do? Ha.

Also, offline password cracking can always be done, given enough determination and a bit of time.

So taken on its own, the password-protected ZIP itself has almost no practical value.

Also — and this isn’t something I witnessed personally —

– There seems to be a misunderstanding that “introducing password-protected ZIPs is mandatory” to obtain Privacy Mark certification

apparently this belief exists in some places. It’s almost certainly a myth. I regularly exchange files with companies that already hold Privacy Mark certification, and I have no memory of password-protected ZIPs ever coming up.

I won’t answer the question “so if you take away our trusty password-protected ZIP, what are we supposed to do?” here. I’m not a security expert. I’ll leave that to the people who actually do this for a living.

That said, if anyone wants to hear my own personal take, I’m happy to offer it separately, strictly as unofficial advice. Ha.


Originally published in Japanese at https://clazytech.com/2020/06/360/. Translated with LLM assistance and reviewed before publication.