Not Strictly VFP - Cracking Password on Excel Spreadsheet

[GriffMG]

Sorry for the departure from the theme, but I'm sure we all generate spreadsheets and feel the need to password protect them from time to time,
so hopefully no one will object. B-)

My wife had such a sheet, after a year or so she had completely forgotten the password and it became 'important', 'did I have a tool that would crack it?'

Well, no, I didn't - but 20 minutes with google revealed that most of the free crackers only pretended to be free and just irritated me. I found one for just shy of
£15 for a month and bought that - you know how it is when something is 'important' to your better half (I'm sure).

Set it with a brute force attempt (dictionary one failed quite quickly) and about 24 hours later we are in. Now here is the interesting thing, the password it settled on
could not possibly have been the one she used, she says. So I'm thinking Excel hashes the actual password and that more than one candidate password can
produce the same hashed result - making the whole thing less secure? Anyone else seen this.

 

[tomk3]

Hello,

I heard that is posible for SHA1to generate values with same hash, but never heard of it for AES 256 (Excel 2019+)
But any crypto is only as good as its implementation

Btw : which Excel version ? Up to 2016 you do not need a pw-cracker. 7zip should be enough

Regards
tom

 

[GriffMG]

Not sure of excel version, pretty sure it was not xlsx.

 

[Chris Miller]

Griff, that's normal, a hash is not reversible, if only one passowrd would produce the same hash, it would be reversible. So as unintuitive it seems to you, that's one of the afety features of hashes. There are more and less secure hashes that differ in how vast the range of hashes can be so it becomes less and less probable to easily find a secondary password. But the nature of that - finding not the actual password, but another producing the same hash, is very normal.

You should think about it that way:; You need a long password to get to a hash that's less likely to be found with brute force attack. If your wife had, say, a 5 letter password, even not a word but a combination of letters and numbers, then it's generally easier to find a password that produces the same hash than it is, if the password is longer, that's why password length is a measure for password strength, among other things.

Tom, AES is an encryption algorithm, not a hash algorithm, a quick google finds: "Excel uses Advanced Encryption Standard (AES) algorithm with a key length of 128 bits to encrypt the password-protected workbook." So that means the sheet is encrypted with AES, the 128 bit key used must either be the hash of the password or the password unlocks access to the AES key that's also stored within the Excel file, I don't know the details. In theory this is very safe, but if the key is stored along it would be like having a key under your doormat. Hard to say how well things are protected within Excel. Such tools point out that either the implementation isn't very safe, or an unsafe password was used.

You could of course always go another route and encrypt the file itself., with cryptograhic encryption plus how and where they key to that is stored fully under your own control. One siple for end users way is storing sensitive files into a virtual encrypted disk. Like VeryaCrypt, that's continuation of TrueCrypt with learned lessons learned from a weakness of Truecrypt. Of course, that's just telling that encrypted drives also only are as secure as their key protection, it's not only about the security of the cryptographic encryption used.

 

[Chris Miller]

Diggina bit deeper I learn a password protected sheet could also be one, where the data can be seen loading it, only the modification of cells triggers a password input dialog. As shown in this video:

If the data can be read, then it's not really protected. The video even shows how simple it is to delete the prtection from a sheet xml file embedded in the zip file an xlsx file is. And that shopws how bad that sheet protection implementation is.

In detail the video shows the xml contains an xml tag with attribute password="CA9C". I doubt that is the plain password, it's likely the password hash, but it is avery short hash, 4 hex digits = 16bit. That's one of 32768 possible values. Besides the fact you can simply delete the protection xml tag, it will not need long to break a 16bit hash.

 

[ggreen61]

Excel (xlsx) and Word (docx) both store the password as a hash value in the xml as a string value. I tried to implement the ability to assign passwords in my Excel class on VFPx but there are a number of property tags that have to be set for it to actually work. The removal of the password value in the attribute is enough to remove the password check and Excel will 'clean-up' the other tags by removing them during a save if the password value is not set.

 

[Chris Miller]

Thanks for pointing that out, I think at makes protection of office files a toy feature you can't take serious, you don't even need to find a replacement password, if you can simly remove the attribute storing the password hash, no matter how bad or good the hash algorithm used is.

If you have the need to provide data read only and make some fields editable, I can't think of a really safe way. Zip file AES encryption is safe, generally AES, especially the variants with at least 256 bits are considered safe, still.

The way hashes become weaker is the way you can not inverse them but still compute rainbow tables to know hashes of most frequently used passwords, password using a simple scheme like only letters or letters and digits, etc. the latest hashing algorithms make it a challenge to copute those rainbow tables as they run the core hasing algorithms many times. You can even make use of the rising capability of CPUs and GPUs by not defining a constant number of iterations but a time used. If, for example the Argon algorithm is run for a second and you finally note down the has and the number of iterations, to compute the same hash on more advanced hardware in the future might take less than a second, but computing millions of hashes in the same way is still impossible, so to build up a rainbow table became impractical with that idea, even better than the idea of using salts or even salt and pepper. You can slo combine these ideas.

But a 4 hex digit=16 bit hash value is surely unsafe, it points out the use of a very simple hash algorithm.