Brute Forcing Passwords
Cracking forgotten document passwords

A.E.Veltstra
2020-04-06

The other day I found myself confronted with a spreadsheet I created 
using a rather popular closed-source spreadsheet computer program. I 
had locked it with a password. And then forgot that password. 
  
Ack.

A quick search around the interwebz teaches us that many people like 
to profit from our misery and deliver brute-forcing attacks to crack a 
forgotten password. I found one that promised a free download and got 
presented a tool that would attempt up to 3 characters. For more 
characters, one had to pay. 

I am a computer software engineer. I think I'm capable of programming 
such an application and not pay someone else for my skill. 

What do we need? First: the ability to open the spreadsheet with a 
random password and catch the error if we pass the wrong one. Luckily 
this spreadsheet has a programming language built-in that can do 
exactly that.

Second: the ability to keep on attempting variations of passwords 
without the document getting scrambled beyond repair. Now any 
self-respecting built-in document security system would keep track of 
how many attempts one failed and either refuse access for some time, 
or just obliterate the document. But not this particular spreadsheet 
making program: it happily continues to try and open the document. 

Third: a computer that can plot away at this task without getting 
interrupted by system updates or power schedulers that turn off the 
power after 30 minutes of interaction absence. And this computer I'm 
using is operated by the system built by the same company that made 
the spreadsheet program. So a few hours later I have all its update 
and power management abilities turned off. Really. Hours. This should 
be easier.

Fourth: a way to iterate over password attempts and make sure we try 
each variation possible within common ascii for a password length 
between 12 and 32 characters. Because I tend to use pass phrases 
rather than words, there's bound to be spaces and commas. 

So how much time is this going to take? 
  
Well, let's see. This spreadsheet language runner is pretty slow. And 
for 12 password characters the amount of possibilities within common 
ascii equals 37,133,262,473,195,501,387,776. That's 37 thousand 
million million possibilities. And that's for the smallest expected 
length. You can do the math for the 32 character length. 

Even if this language is able to process 4 passwords a second (and 
that's pushing it), testing the full range of 12 characters is going 
to take 300 billion years. 

What.

I need a faster language.