How to test your excel password before sending encrypted files to external partners
- Step 1Open the auditor before you encrypt — The Excel password-tester redirects to the Password Entropy Auditor at
/security-tools/password-entropy-auditor. There's no file upload — you're vetting the password you'll put on the file you send to the partner. - Step 2Paste your distribution password — Enter it in the Password field (placeholder
Type or paste a password). It displays in plain text and never leaves your browser — vet it at your desk, not on a shared screen during a partner call. - Step 3Click Run Password Auditor — zxcvbn scores it locally. Even the password you're about to text to a counterparty is safe to test here, because nothing is transmitted.
- Step 4Require Score 4 · centuries for external files — Anything you send outside the building should hit Score 4 · Excellent with a crack time of centuries. A weak password on a file in a partner's inbox is outside your control entirely.
- Step 5Encrypt the file in Excel — Apply the certified password via File → Info → Protect Workbook → Encrypt with Password, which wraps the workbook in AES-256 keyed from your strong password.
- Step 6Send the file and the password on separate channels — Email the encrypted file, but deliver the password by phone, SMS, or a secure messaging app — never in the same email. A unique password per partner makes revocation and tracking far easier.
Distribution-ready password checklist
What a password must clear before an Excel file goes to an external partner, expressed in the auditor's own terms.
| Check | Pass condition (auditor) | Why it matters for distribution |
|---|---|---|
| Strength score | Score 4 · Excellent | The file lives in someone else's inbox; it must withstand offline attack |
| Crack time | centuries (offline fast hash) | You can't revoke a forwarded email — assume unlimited offline guessing |
| Warning line | Blank (no warning) | A common-password warning means it's effectively pre-cracked |
| Not your firm / partner name | No company or codename in the password | External parties can guess these trivially; they score low anyway |
| Unique per partner / file | Not reused from another distribution | One leaked password shouldn't unlock every file you've ever sent |
Partner-distribution passwords: real auditor results
Typical choices for files sent to suppliers and partners, scored by the tool. Crack times are the offline fast-hash figures it reports.
| Candidate | Score / crack time | Verdict for external distribution |
|---|---|---|
Acme2026 | 2 · Fair · less than a second | Reject — sender name + year is the first thing a partner-side attacker tries |
PriceList!1 | 1 · Weak · less than a second | Reject — describes the file and follows a common pattern |
Tr0ub4dor&3 | 4 · Excellent · 10 seconds | Reject — Score 4 but cracks in seconds; never leave this in an inbox |
xK9#mL2vQp | 3 · Strong · 1 second | Reject for external use — too short to survive offline guessing |
cedar-lantern-brisk-9-fathom | 4 · Excellent · centuries | Send it — strong, and unique per partner |
Cookbook
Real auditor output for passwords people put on files headed out the door. Each result is the genuine zxcvbn verdict for that exact string.
Describing the file in the password
Naming the contents (PriceList, Contract, Quote) plus a digit feels mnemonic but is exactly what a guesser starts with, especially when they already know what the email contained. The auditor flags it instantly.
Password: PriceList!1 Result: Score 1/4 · Weak Crack time (offline fast hash): less than a second → Don't name the file's contents in its password.
Sender name + year, the distribution default
The reflexive choice when sending to a partner: your company name and the year. Predictable to anyone who received the email, and sub-second to crack offline.
Password: Acme2026 Result: Score 2/4 · Fair Crack time (offline fast hash): less than a second → A partner-side attacker knows the sender. Avoid names entirely.
Score 4 isn't automatically safe to send
Even the famous 'Tr0ub4dor&3' scores 4 yet cracks in 10 seconds. For a file you can't recall once it's sent, that's a fail. Always confirm the crack time reads centuries before distributing.
Password: Tr0ub4dor&3 Result: Score 4/4 · Excellent Crack time (offline fast hash): 10 seconds → Score 4 ≠ safe to leave in a partner's inbox. Demand 'centuries'.
A distribution-grade password
Four uncommon, unrelated words with separators and a digit clear the bar: Score 4, centuries. Generate a fresh one per partner so a single leak is contained.
Password: cedar-lantern-brisk-9-fathom Result: Score 4/4 · Excellent Crack time (offline fast hash): centuries → Encrypt with this, send the file, deliver the password separately.
The full secure-distribution sequence
Strength is only half of it. The complete workflow vets the password, encrypts, and crucially splits the file and password across two channels.
1. Audit: birch-anchor-plush-4-mesa → Score 4 · centuries ✓ 2. Encrypt: Excel → Encrypt with Password 3. Send: encrypted .xlsx by email 4. Deliver: password by SMS / phone (NOT the same email) 5. Track: unique password logged per partner
Edge cases and what actually happens
Sending the password in the same email as the file
Defeats encryption (fail)The single most common distribution failure. If the email is forwarded, intercepted, or sits in a compromised inbox, the password is right there beside the file — the AES-256 protects nothing. Always deliver the password out-of-band: SMS, a phone call, or a separate secure channel.
Reusing one password across all partner files
Distribution riskA single shared distribution password means one leak — or one partner's careless forward — exposes every file you've ever sent. Audit and use a unique strong password per partner or per file. The tool scores each candidate; your process must enforce uniqueness and track which partner got which.
Naming the sender or the file in the password
Always rejectedAcme2026, PriceList!1, ContractQ4 and similar describe the sender or contents — exactly what a recipient-side attacker already knows. They score 1–2 with sub-second crack times. Use unrelated words that reveal nothing about the file or its origin.
A Score 4 that cracks in seconds
Read the crack timeTr0ub4dor&3 scores 4 but cracks in 10 seconds; correcthorsebatterystaple scores 4 but cracks in 8 hours. For a file you can't recall once sent, the 0–4 score isn't enough — require a crack time of centuries before anything leaves the building.
The partner can't open it because Excel Online won't decrypt
Recipient frictionExcel for the web cannot open files encrypted with Encrypt with Password — only desktop Excel can. If your partner works in the browser, they'll need desktop Excel (or a compatible app) to enter the password. Warn them, or agree on a workflow, so the strong password doesn't become a delivery failure.
You forget the password you sent
UnrecoverableA Score 4 · centuries password is, by design, not feasible to brute-force — including by you, and JAD can't recover it. If you re-send or the partner loses it, you must re-encrypt from your source copy. Log each distribution password in a password manager keyed to the partner.
The auditor never transmits the password
Expectedzxcvbn runs in your browser, so the password you're about to send to a counterparty is scored locally and goes nowhere. This matches the whole point of secure distribution: vetting the password must not itself become the leak.
Strong password, but the file still leaks metadata
Clean before sendingEncryption protects the cells, but once the partner decrypts, hidden sheets, tracked comments, and document properties are all visible. Before encrypting for distribution, strip them. Run the hidden-sheet destroyer, the comment and note purger, and the application-metadata wiper.
l33t substitutions don't make a sendable password
Low impactPr1ceL!st and similar substitutions are the first thing an attacker tries, so zxcvbn discounts them heavily — P@ssw0rd scores 0. For a file leaving your control, leaning on substitutions is a false comfort. Use length and unrelated words.
Relying on the email channel's security alone
InsufficientTransport encryption (TLS) protects the email in transit, not at rest in the recipient's mailbox or after forwarding. The file-level password is your control once the message is delivered — which is why it must be strong and why the password must travel separately.
Frequently asked questions
How should I share the decryption password with an external partner?
Never in the same email as the encrypted file — that defeats the encryption if the message is forwarded or intercepted. Use a separate channel: a phone call, SMS, a secure messaging app, or a different email account the recipient controls. Splitting the file and the password across two channels is the core principle of secure distribution.
What score should I target for a file going to an external partner?
Score 4 · Excellent with a crack time of centuries. Once the file is in someone else's inbox you've lost all access control, so it must withstand unlimited offline guessing. Anything below centuries — even a Score 4 that cracks in hours — is inadequate for commercially sensitive files leaving the building.
Is encrypted email better than a password-protected Excel file?
End-to-end encrypted email (S/MIME or PGP) is stronger overall because it protects the whole message and avoids the separate-channel password dance. Password-protected .xlsx is a pragmatic alternative when you and the partner don't share encrypted-email infrastructure. If you go the Excel route, a strong audited password and out-of-band delivery are non-negotiable.
Can the auditor read the file I'm about to send?
No — there's no file upload. It scores a password string only. You vet the candidate password here, then apply it to the file in Excel yourself. To clean the file's contents before distribution — redacting PII, for example — use a dedicated tool such as the email and phone scrubber.
Should I use a different password for each partner?
Yes. A unique password per partner (or per file) means a single leak or careless forward doesn't unlock everything else you've distributed, and it lets you revoke and track access cleanly. Audit each new password to Score 4 · centuries and log it in a password manager keyed to that partner.
Why does our standard 'SenderName + Year' distribution password fail?
Because the recipient already knows the sender, so the firm name plus a recent year is the very first guess a partner-side attacker makes — and zxcvbn models exactly that. Acme2026 scores 2 with a sub-second crack time. Pick words that reveal nothing about who sent the file or what it contains.
Is it safe to test the password I'm about to text to a partner?
Yes. zxcvbn runs entirely in your browser; the password is scored locally and never transmitted. Testing it here creates no network exposure. The only caution is the on-screen display — vet it where no one can read your screen, especially not during a call with the partner.
My partner says they can't open the encrypted file — what happened?
Most likely they tried to open it in Excel for the web, which cannot decrypt Encrypt-with-Password files — that's a desktop Excel feature. They'll need desktop Excel or a compatible application to enter the password. Confirm their setup before sending, or agree on a delivery method that suits a browser-only recipient.
What if I need to prove the file wasn't tampered with in transit?
Encryption protects confidentiality, not integrity proof. Generate a hash of the encrypted file with the SHA-256 fingerprinter and send the hash on the same out-of-band channel as the password. The partner re-hashes on receipt to confirm the file is byte-identical to what you sent.
Does the auditor check the password against known breach databases online?
It doesn't make any network call. zxcvbn ships its own internal dictionaries and common-password lists and runs them locally in your browser, so it can flag a This is a very common password warning without sending anything anywhere. That local-only design is what makes it safe for vetting a real distribution password.
What should I strip from the file before encrypting it for a partner?
Everything that the partner shouldn't see once they decrypt: hidden and very-hidden sheets, reviewer comments and notes, VBA macros, and document metadata. Run the hidden-sheet destroyer, the comment and note purger, and the VBA macro stripper before you apply the password and send.
If I lose the strong password, can I still recover the file I sent?
Not by cracking it — a Score 4 · centuries password is designed to be infeasible to brute-force, and JAD provides no recovery. Your recovery path is your own source copy plus the password manager entry. Log every distribution password against the partner and file so 'strong' never turns into 'lost'.
Privacy first
Every JAD Excel tool runs entirely in your browser using SheetJS and ExcelJS. Your spreadsheets, formulas, and data never leave your device — verified by zero outbound network requests during processing.