How to Password Protect a Shared File (and Why It Probably Won't Save You)

You have a sensitive document. A contract, a tax return, medical records, source code. You need to send it to someone today. The instinct is obvious: slap a password on it. ZIP it, PDF-lock it, email it, done. But if you want to know how to password protect a shared file in a way that actually resists a motivated attacker, the answer is more complicated than the right-click menu suggests. Most default password protection is, to put it plainly, theater.

Key Takeaways

• The default encryption on most ZIP files (ZipCrypto) is trivially crackable with commodity tools, often in minutes. You need AES-256 via a tool like 7-Zip, and you need to enable file-name encryption manually.
• PDF password protection ranges from instant-crack (older Acrobat versions) to reasonably strong (AES-256 in modern Acrobat), but "permission" passwords that restrict editing or printing are decorative, not protective.
• Sending the password over the same channel as the file (same email thread, same Slack DM) collapses two factors into one. The password is only as private as the least private channel it travels through.
• Even properly encrypted archives leak metadata: file names, sizes, directory structure. The envelope tells a story even when the contents are sealed.
• Password protected file sharing is being replaced by end-to-end encrypted platforms with identity-bound access and link expiration, because the structural problems with "file plus password" are not fixable by choosing a longer password.

Is a Password-Protected ZIP File Actually Secure?

Usually not. The reason is a specific, well-documented flaw in the default encryption algorithm most ZIP tools use.

When you right-click a folder in Windows and select "Send to > Compressed (zipped) folder," or use most built-in OS compression tools, the resulting archive uses ZipCrypto, a proprietary cipher designed in the early 1990s. It predates modern cryptographic standards by decades. Off-the-shelf cracking tools can break ZipCrypto passwords in minutes to hours, depending on password length, using known-plaintext attacks that exploit the algorithm's structure rather than brute-forcing the password itself.

This is not a theoretical concern. Senator Ron Wyden formally wrote to NIST warning that many people incorrectly believe password-protected ZIP files can protect sensitive data, when the default algorithms are trivially broken with freely available hacking tools. He asked NIST to publish guidance. The fact that a sitting senator felt this needed federal attention tells you how widespread the misconception is.

The fix exists, but it requires deliberate choices. You need to use a dedicated archiver like 7-Zip, select the .7z format, choose AES-256 encryption, and check the "Encrypt file names" box. That last step matters because without it, the archive leaks the names and sizes of every file inside, even if the contents are unreadable. More on that shortly.

What About Password-Protected PDFs?

PDF password protection is a spectrum, and most of it is worse than people think.

There are two kinds of PDF passwords. The "open" password prevents someone from viewing the document at all. The "permissions" password restricts actions like printing, copying, or editing. The permissions password is essentially decorative: dozens of free tools strip it instantly because the document content itself is not encrypted, only the permission flags are set. If your goal is preventing someone from reading the file, a permissions password does nothing.

Open passwords are stronger, but only if the PDF was created with a modern version of Acrobat using AES-256 encryption. PDFs created with older Acrobat versions used weak RC4 or early RSA-based encryption that can be cracked instantly. The cracking tools are commodity software. They use dictionary attacks fed by leaked-password databases, rule-based mutations, and brute force. If your password is "Company2024!" it will fall in seconds because that pattern appears in every wordlist on the internet.

So: a PDF with AES-256 encryption and a genuinely random, long password is reasonably resistant to offline attack. A PDF from Acrobat 9 with "password123" is not protection. It is a suggestion.

Why Does Sending the Password Separately Not Actually Help?

Every guide on password protected online file sharing says the same thing: send the password through a different channel than the file. Email the ZIP, text the password. This is better than putting both in the same message, but the improvement is smaller than it sounds.

The password is only as private as the least private channel it travels through. If you email the file and send the password over SMS, the password now sits in plaintext on a cell carrier's infrastructure, in the recipient's message history, possibly in an iCloud or Google backup. If you send it via Slack DM, it is stored in Slack's servers, searchable by workspace admins, subject to Slack's data retention policies and any legal process served on Slack.

Attackers know this. Phishing campaigns routinely put the password in the same email body as the attachment because they have observed that this is what real humans do. The "send the password separately" advice is so rarely followed in practice that attackers exploit the pattern, not the exception.

The structural problem is that a password is a shared secret, and shared secrets have to be transmitted somehow. Every transmission creates a copy. Every copy is a potential leak. This is why the industry is shifting toward identity-bound access (the recipient authenticates as themselves, and the system grants access without a shared secret ever crossing a wire) rather than continuing to refine the "file plus password" model.

What Metadata Leaks Even from a Properly Encrypted Archive?

This is the part that surprises most people. Even if you use AES-256 encryption on a ZIP archive, the standard ZIP format stores file names, directory paths, and file sizes in the clear. The archive header is not encrypted.

That means an attacker (or anyone who intercepts the file) can see that your archive contains merger_agreement_draft_v3_FINAL.docx and due_diligence_financials_2025.xlsx without knowing the password. The file sizes tell them roughly how much content is inside. The directory structure can reveal project names, client names, internal codenames.

This is not an edge case. It is the default behavior. If you are sending something sensitive enough to encrypt, the metadata is often sensitive too. The fix in 7-Zip's .7z format is the "Encrypt file names" checkbox, which encrypts the archive header along with the contents. Standard .zip format does not support this at all. You must use .7z.

Real privacy-first design has to account for the envelope, not just the contents. A zero-knowledge architecture means the service cannot see what you are sending, who you are sending it to (beyond what is needed for delivery), or what it is called. Password-protecting a file and emailing it exposes all of that to the email provider, the recipient's email provider, and any security appliance in between.

How Do Attackers Exploit Password-Protected Files?

Here is the irony: the same encryption that makes password-protected files feel safe to you makes them invisible to your security tools.

Password-protected files are now a favored malware delivery mechanism. The most common payload types are Word documents, Excel spreadsheets, PDFs, and ZIP archives. The password encrypts the contents, which means the organization's email gateway, antivirus scanner, DLP system, and sandbox cannot inspect what is inside. The file sails through every automated defense. The attacker includes the password in the email body or in a follow-up message, and the recipient opens it manually.

Barracuda's 2026 Email Threats Report found that archive files like ZIP and RAR have a relatively low overall malicious rate (0.13%), but attackers use them specifically to bypass attachment inspection, especially when the archives are nested or password-protected. The low rate is partly because the technique works: it does not need volume when evasion is reliable.

A 2026 analysis by Ironscales found that Secure Email Gateways miss an average of 67.5 phishing emails per 100 mailboxes per month. Password-protected attachments are one of the hardest categories for static scanning to address, because the scanner literally cannot open the file. One documented case involved a password-protected PDF phishing email that passed SPF, DKIM, DMARC, and ARC authentication checks using a legitimate state government education domain. Every automated trust signal said "this is fine."

A March 2026 case documented by Malwarebytes showed a fake purchase-order PDF that was actually an HTML file. Opening it displayed a password prompt with the recipient's email address pre-filled, mimicking the familiar "this PDF is protected" dialog. In the background, a script harvested the victim's IP address, geolocation, and browser fingerprint. The "password protection" UI itself was the weapon.

So when you password-protect a file to "be safe," you are simultaneously blinding every automated safety net that sits between you and the recipient. You are also training the recipient to expect password prompts on attachments, which makes them more susceptible to phishing attacks that mimic that exact experience. The security model undermines itself.

Does Windows Handle ZIP Passwords Correctly?

Not in a way that inspires confidence. A widely-read post on Microsoft's "Old New Thing" dev blog examined how Windows caches passwords for recently-opened ZIP files, creating UX quirks that add confusion rather than security. The operating system's built-in ZIP handling does not support AES-256 at all. It only supports ZipCrypto. If you are relying on the built-in Windows ZIP feature for any kind of sensitive file sharing, you are getting the weakest possible encryption by default, with no warning that this is the case.

macOS is marginally better in that the zip -e command in Terminal uses ZipCrypto too, but at least the Finder does not offer a false sense of security by presenting a "password protect" option in the GUI. The absence of a feature is, in this case, more honest than the presence of a bad one.

What Is the Actual Secure Way to Share a Sensitive File?

The honest answer has a few layers.

If you must use a password-protected archive today, right now, because your workflow requires it: use 7-Zip, choose .7z format, select AES-256, enable "Encrypt file names," use a password that is at least 20 characters of random output from a password manager, and transmit the password over a channel that is genuinely separate from and at least as secure as the file's channel. A Signal message for the password while the file goes over email is a reasonable minimum. Same email thread is not a second channel. Same Slack workspace is not a second channel.

But the better answer is to stop using the "file plus password" pattern entirely for anything that matters.

Security professionals increasingly recommend end-to-end encrypted sharing platforms over password-protected archives. The reasons are structural, not just about convenience. A well-built sharing platform can offer:

• Identity-bound access: the recipient authenticates as themselves. No shared secret to transmit or intercept.
• Link expiration: the file becomes inaccessible after a set time, automatically.
• Revocable access: you can kill the link after the recipient has downloaded it, or before, if you change your mind.
• Zero-knowledge encryption: the platform operator cannot read the file contents, so a server breach does not expose your data.
• Minimal metadata: a well-designed system does not need to store file names, recipient email addresses, or access logs beyond what is operationally necessary.

Recent roundups of secure file sharing tools consistently highlight these features as the category standard, with multiple publications positioning zero-knowledge platforms as the replacement for password-ZIP habits.

How Does This Relate to Sending Files Through an AI Assistant?

If you use an AI assistant that can send files on your behalf, the encryption architecture of that assistant matters more than whether you slapped a password on the file first.

When you upload a file into SelinaSEND, the file is zero-knowledge encrypted before it leaves your device. We cannot read it. The recipient gets a link. The link can expire. Access can be revoked. No shared password travels over a separate channel because the access control is identity-bound, not secret-bound. The file contents are never visible to us, which means a compromise of our infrastructure does not expose your document.

This is a structurally different model from "encrypt a ZIP, email it, text the password, hope for the best." It eliminates the shared-secret problem, the metadata leakage problem, and the scanner-blindness problem in one move. The recipient does not need to install 7-Zip or remember which checkbox to tick.

When Is a Password-Protected File Good Enough?

For completeness: there are scenarios where password protection on a file is a reasonable trade-off, even knowing its limits.

If you are archiving files locally on an encrypted drive and want a second layer in case someone gains physical access, a strong AES-256 encrypted .7z archive with a long random password stored in your password manager is fine. The threat model is different when the file never leaves your machine.

If you are sharing something low-sensitivity (a draft blog post, a photo album) and the password is just to prevent casual access rather than resist a determined attacker, ZIP encryption of any kind is adequate. Not everything is a state secret.

If regulatory compliance requires "encrypted in transit" and your auditor accepts password-protected archives, the checkbox may be sufficient for the compliance requirement even if it is insufficient against the actual threat. This is common and also slightly depressing.

But if the file contains financial data, health records, legal documents, credentials, source code, or anything where exposure has real consequences: a password on a file is the wrong abstraction. You need a system where the encryption is not separable from the access control, where the key management is not "I texted it to you," and where the metadata is protected alongside the contents.

What Should You Actually Do Today?

If you need to send a sensitive file in the next ten minutes:

1. Do not use the built-in ZIP encryption on Windows or macOS. It uses ZipCrypto. It is breakable.
2. If you must archive, use 7-Zip with .7z format, AES-256, file-name encryption enabled, and a 20+ character random password from a password manager.
3. Send the password over Signal or another end-to-end encrypted channel. Not the same email. Not SMS. Not Slack.
4. If you are sending a PDF, verify it was saved with AES-256 encryption (Acrobat's security settings will tell you). Do not use a permissions-only password and assume it protects the contents.
5. Better yet, use an end-to-end encrypted file sharing service with link expiration and identity-bound access. This removes the shared-secret problem entirely.

The core issue is not that passwords are bad. Passwords are fine as authentication factors in the right context. The issue is that password-protected files conflate encryption with access control, transmit shared secrets over insecure channels, leak metadata by default, and train users to open password-prompted attachments from strangers. Each of those problems is individually fixable. Together, they make the pattern structurally unsound for anything that actually matters.

If you want to try a different approach: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io