Microsoft Office has protected documents with passwords since Word 2.0 in 1991, and for most of that history the protection was weaker than stated. The word “password” in Office covers two completely different things. One is encryption, and it can be strong. The other is a flag that tells the application to refuse an edit, and it has never been strong, because it cannot be. Confusing the two is the most common mistake we see, and it is the reason a document someone was sure they had locked often opens in seconds.
The short answer is this. A password that only restricts editing, printing, or a single worksheet comes off almost instantly, no matter how long or complex it is. A password that encrypts the whole file is a different problem, and on a current version of Office it can be hard. The long answer takes the rest of this article.
Office offers two kinds of password.
The first is a password to open, sometimes called a password to encrypt. Set one, and the contents of the file are actually encrypted. Without the password there is no readable data, only ciphertext. This is the kind that can be strong.
The second covers everything else: a password to modify, worksheet and workbook protection in Excel, the “restrict editing” options in Word, the lock on a VBA macro project. None of these encrypt anything. The text, the numbers, and the formulas sit in the file in the clear. All that is stored is a small verifier, and the application checks it before it lets you make a change.
There is a plain reason the second kind has to be weak. The application must display the content to you. If Excel can open a “protected” worksheet and show you every cell without asking for anything, then the worksheet was never encrypted; the lock is on the door handle, not on the room. Microsoft says as much in its file format specification, [MS-OFFCRYPTO].
Here is how the protection changed over thirty years. We wrote a longer version of this timeline in an earlier article; this is the compressed one.
Word 2.0 through 95, and Excel up to 95. The encryption was an XOR operation, which is obfuscation rather than encryption. Every password from this era can be recovered outright, with no attack worth the name.
Office 97 and 2000. These used the RC4 cipher with a 40-bit key and a single iteration of MD5 for hashing. Forty bits was deliberately weak, a concession to the United States export restrictions on cryptography that were in force at the time. The same scheme was carried into Office 2000 even after those restrictions had effectively lapsed, for compatibility. The short key was not the only problem; the implementation reused the same RC4 keystream when a document was saved again, a flaw documented by Hongjun Wu in 2005 in “The Misuse of RC4 in Microsoft Word and Excel”.
Office XP and 2003. The same 40-bit RC4 by default. Starting with Office XP you could select an external cryptographic service provider, a plug-in that supplies a longer key; in practice almost nobody did, again for compatibility. When a provider was used you had to attack the password instead of the key, but the protection was still weak.
Office 2007. This is the turning point. Microsoft moved to AES with a 128-bit key, and ran the password through 50,000 iterations of SHA-1 before deriving that key. The long key put the key itself out of reach; from here on you have to recover the password, not the key.
Office 2010. The same scheme, with the iteration count doubled to 100,000. That one change makes every guess twice as expensive.
Office 2013, 2016 and 2019. AES with a key of up to 256 bits, SHA-512 for hashing, and 100,000 iterations. The exact defaults shifted between these releases, and Microsoft’s [MS-OFFCRYPTO] specification is the place to check a specific version; what matters here is the direction. Every release since 2007 has made the same file harder to open by lengthening the key, strengthening the hash, or adding iterations.
Today there is no boxed “Office 2022” or “Office 2025” to reason about. Microsoft 365, the subscription that replaced perpetual Office and that Microsoft largely renamed from Office 365 in 2020, updates itself continuously; the application changes under everyone quietly and often, rather than once every three years. That change in delivery did not bring a new way of encrypting documents. A password to open on a Microsoft 365 Word or Excel file uses the same scheme, which Microsoft calls agile encryption, that it introduced with Office 2013 and had settled by 2016: AES with a 256-bit key in cipher block chaining mode, a key derived from the password with 100,000 iterations of SHA-512, and a 16-byte salt. These are not our figures; you can read them straight out of a protected file, and Microsoft printed a real example of exactly these values in a recent post on its own blog, while its Office cryptography documentation still lists them as the defaults.
The subscription model changes the risk in a way. Since strengthening now arrives as a silent background update rather than a new product, the assumption is that a current file is at least as strong as the last named release, and never weaker. Microsoft has recently begun writing about crypto-agility and post-quantum algorithms for Office, which is where the next real change will come from; none of it has replaced the 2016 scheme as the default yet, and I will not guess the date when it does. Until then, a Microsoft 365 password to open behaves exactly like an Office 2019 one.
Everything in the second category from earlier: the password to modify, worksheet and workbook protection, the VBA project lock. None of it is encryption, so there is nothing to decrypt.
In the old .xls binary format, the protection password is stored as a 16-bit verifier. Sixteen bits, with the top bit always set, leaves about 32,768 possible values, which means many different passwords produce the same verifier. You do not need the original password; you only need any password that collides with it, and collisions are trivial to find. Researchers have published lists that contain a match for every possible verifier; see Didier Stevens’ write-up for the mechanics.
In the modern DOCX and XLSX formats the job is simpler still. These files are ZIP archives full of XML. Unzip the file, delete the element that carries the protection, zip it back up, and the restriction is gone. The content was sitting there in the clear the whole time.
Because none of this touches encryption, the length of the password is irrelevant. A hundred-character worksheet password comes off exactly as fast as “123”.
Note that removing the restriction is instant on every version of Office. Recovering the exact original modify-password is a different matter on Office 2013 and later, where the verifier moved to a salted SHA-512 hash and is no longer trivial to reverse. In practice you almost never need the original password; you need the restriction gone, and that has not changed.
The password to open on Office 2007 and later. Here the file really is encrypted with AES, and the key is derived by running the password through tens of thousands of hash iterations, which is slow by design. There is no flag to delete, because the bytes are genuinely scrambled. The only way in is to find the password.
That means an attack: a dictionary of likely words first, then rules and masks that encode whatever you already know about the password, and brute force as a last resort. The work is measured in guesses per second, and the numbers are sobering. On 2019 hardware, a single NVIDIA Tesla V100 managed roughly 20,000 guesses per second against an Office 2013 or later document, against about 50 per second on a CPU. Current graphics cards are considerably faster, so treat those figures as a floor rather than a present-day benchmark. Even so, a long and random password to open on a modern Office file can be out of practical reach, which is the whole point of it.
Back to the legacy 40-bit files, because they are a special case with a satisfying answer. When a Word .doc or Excel .xls file uses 40-bit encryption, we do not attack the password at all; we attack the key.
A 40-bit key has 2^40 possible values, a little over a trillion. That is a finite space, and by modern standards a small one. You can simply try every key until the document decrypts. The length and complexity of the user’s password stop mattering entirely; the only thing that governs the time is the speed of your processor, and the result is guaranteed, because one of those trillion keys is the right one. On an ordinary computer this takes hours, but…
Trying a trillion keys on every new document is wasteful, since the set of possible keys never changes. The better idea is to do the expensive work once and store the result. This is a time-memory tradeoff: you spend time and disk space up front so that each later lookup is fast.
The naive version, a full table of every 40-bit key, would need about 5 terabytes. Rainbow Tables, introduced by Philippe Oechslin in 2003 as an improvement on a 1980 method by Martin Hellman, do the same job in a few gigabytes by trading a little lookup time for a large saving in space. The catch is that a Rainbow Table is probabilistic. Its success rate is high, commonly 97 to 99 percent, but it is never 100 percent. When it misses you are back to brute force, and worse, that brute force does not know the table already covered 99 percent of the keys, so it wastes almost all of its time re-checking keys that were never going to work.
Elcomsoft Thunder Tables are our answer to that last problem, and we explained the internals in a 2009 article for anyone who wants them. The idea is easy to state. Alongside the Rainbow Table we ship a second file that lists exactly the keys the Rainbow Table cannot handle. Now, when the table misses, the brute force step knows which keys are left, roughly one percent of the total, and checks only those. The miss that used to cost hours now costs seconds. The result is a genuine 100 percent guarantee for Word documents, and for PDF files, in seconds rather than hours.
Building that list of misses was the hard part. The obvious method needed 128 GB of RAM to hold a bitmap of the 40-bit space, which was exotic at the time, so we found another way and built the first tables on a single machine with one gigabyte.
Excel is the exception. For Excel spreadsheets we provide conventional Rainbow Tables with a success rate around 97 percent, not Thunder Tables. The reason is the Excel file format itself: it is unpredictable about where a given piece of data ends up in the file, and that unpredictability is exactly what a guaranteed table attack cannot tolerate. A small share of .xls files, three to five percent, carry quirks that defeat the attack, so chasing a guarantee for Excel is not worth the effort; the odds of hitting an awkward file are higher than the odds of the table failing on a normal one.
Which brings me to the software. For breaking Office protection on a single computer, the tool is Advanced Office Password Recovery. It removes the instantly-removable passwords described above, it decrypts legacy 40-bit .doc and .xls files within a guaranteed time, and it runs GPU-accelerated attacks on the password to open of modern documents. The Thunder Tables for Word and the Rainbow Tables for Excel ship with the Forensic edition; the Home edition brute-forces the 40-bit key instead, which is still quick on a current CPU.
Now the confession. For years we also sold Advanced Office Password Breaker, whose single job was the 40-bit key attack, in guaranteed time, that Advanced Office Password Recovery now handles. Two products, almost the same name, overlapping purpose. Our users could never tell them apart, and I am fairly sure only our CEO reliably could; the rest of us, mere mortals, just guessed. In December 2021 we ended the arrangement, discontinued Advanced Office Password Breaker, and folded its features into Advanced Office Password Recovery. We wrote about it at the time, with some relief.
When one computer is not enough, the tool is Elcomsoft Distributed Password Recovery. It is built for the hard case: recovering the password to open on modern, strongly encrypted DOCX and XLSX files, where a single machine would take too long. It runs one attack across many computers, up to 10,000 of them, with GPU acceleration on each, and it can borrow extra capacity from Amazon cloud instances when a deadline demands it. It also handles more than 300 formats besides Office, which is a different article.
The rule of thumb is short. If the document is old, or the password only restricts editing, Advanced Office Password Recovery on one computer is enough, and often finishes in seconds. If the document is recent and the password to open is long, that is what Elcomsoft Distributed Password Recovery is for.
GPU-accelerated Advanced Office Password Recovery can use powerful processing units of your AMD and NVIDIA video cards to remove, replace or recover passwords protecting Microsoft Office documents faster. Supporting all versions of Microsoft Office from version 2.0 to 2019, the tool allows specifying a variety of masks and attacks. Its highly-optimized low-level code ensures the quickest recovery of the most complex passwords.
Advanced Office Password Recovery official web page & downloads »
Build high-performance clusters for breaking passwords faster. Elcomsoft Distributed Password Recovery offers zero-overhead scalability and supports GPU acceleration for faster recovery. Serving forensic experts and government agencies, data recovery services and corporations, Elcomsoft Distributed Password Recovery is here to break the most complex passwords and strong encryption keys within realistic timeframes.
Elcomsoft Distributed Password Recovery official web page & downloads »