(Why) does an encrypted MS Office 2010 Spreadsheet (need to) have the password hash "written down"?

Question

To my naive mind, it seems like the encryption of a document with AES should go like this:

HumanPassword ---|hash|--> key ---|AES|--> Ciphertext

                       plaintext|--^

And the decryption like this:

HumanPassword ---|hash|--> key ---|AES|--> Plaintext

                      ciphertext|--^

And as such it seems that the encrypted package (the excel file) should not need to contain the hash of the human password, and furthermore, that it would be insecure for it to do so.

One of my co-workers says that "if the file didn't contain the hash, what would it compare the password to?"

It seems to me like it needn't do any comparison. It should decrypt with whatever key it gets from the hash, and if it worked, the result won't be nonsense. If it didn't work, excel should see nonsense and say "Wrong password, nincompoop." But it shouldn't have the hash in the file. It shouldn't need to compare anything.

However, it seems that it does have the hash in the file.

When my coworker and I picked this file apart, we found that there was indeed a hash value in there, and we are now running dictionary and brute-force attacks against it.

So I suppose my question is this:

Why does an encrypted MS Office 2010 document need to store the hash of the password?

And, if secondary questions are appropriate on SE,

If it doesn't absolutely need to, why did Microsoft choose for it to? Isn't that less secure if the hash algorithm isn't very good?

Answer 1

This is a case where security has been scarified for usability.

The hash acts as a checksum. If they had nothing to compare it to they would not be able to determine if the file was in fact decrypted with the correct password. Without this comparison it would blindly try to load in the file. A wrong password would mean it would load in corrupted. And the user/application would not know if this corruption was due to a wrong password or some other issue.

Additionally the hash is not a direct hash of the key. In Office 2007 it hashes the password 50,000 times and in Office 2010 it hashes it 100,000 times. Both using SHA-1. This is to fight off tools that brute forced hashes for earlier versions. Office 2013 uses the same strategy but uses SHA-512 by default. As a result the hash is safe for redistribution. You can learn more about the password protection here.

With this said it is still possible to brute force. Ultimately the strength of the key is up to the end user.