Hi, Leo. I searched your site and several other websites but could not find the exact explanation that I’m looking for. I’ve been keeping all of my personal financial information and website passwords in an Open Office spreadsheet that is saved with a long, complex password. From what I’ve been reading from your site and others, that spreadsheet is maybe not a secure as I think it is.
My question is – can anyone using sophisticated hacking software see the data in my file without breaking the password? In other words, if I have a relatively complicated password, shouldn’t I trust that as being secure? I find it very convenient to copy and paste login information from my spreadsheet. However, if I someday lose my portable backup drive or it’s stolen or if someone breaks into my home when I’m away, then could someone easily see the data in my password protected spreadsheet file? I assume, of course, part of this equation is how sophisticated the potential thief is and how much of a target I am perceived to be?
There’s a part of me that really wants to say that you’re safe.
In general, I’m not a big fan of using spreadsheets for passwords, but I know a lot of people do for saving that kind of information. And with a complex and lengthy password like you’ve said you’re using, in general, it should be safe to use a password-protected spreadsheet in a utility like Open Office, Microsoft Office, or any of a number of other applications that provide password protection for their documents.
I want to say that is safe.
Unfortunately, history does not really bear that out too well.
The sordid past
Things are no doubt getting better, but we don’t know if they’re getting better enough.
In the past, application-provided security was anything but secure. By “application-provided” I mean applications like Office or Open Office whose primary function is something else: document creation and editing for example. As a side effect, sometimes almost as an afterthought, they happen to provide some way of password-protecting a document.
Going back some years, if encryption was used, it was often exceptionally poor. Sometimes the presence of a password did not do much more than set a flag that said, “password required” without actually encrypting the data. As you might expect, there were easy cracks available, often very simple ones that would bypass all of this so-called security.
Fortunately, those days are long gone – we hope.
The hoped-for present
Most of the reputable applications, like Office, Open Office, Libre Office, WinZip or any of several others now actually have significantly better security in place. Most will use what I’d refer to as “real” encryption algorithms, and often do their best to handle things in an appropriately secure way.
And yet, it’s still difficult for me to say that we’re really safe relying on them.
The first problem is that security and encryption are hard; really, really hard. Encryption in particular is complex and very easy to get wrong while looking like it’s right. When applications add a layer of encryption, they’re basically asking people whose primary job is not encryption to learn and implement it. That by itself is a risk.
The second problem is that there are hundreds of different encryption algorithms and variants out there. Some are better than others. Some are faster than others. Some make a trade-off between complexity and what I’ll call the thoroughness of the encryption, or the amount of time that it takes to do the encryption and decryption. Add to that the choices that the encryption implementation can make; everything from what kind of random numbers to use to how big an encryption key to use… and things get, like I said, really complex.
Why is encryption so complex? There’s just no single thing we can call encryption. It’s really a combination of a multitude of choices and trade-offs, algorithms and software. Choices that our application vendors are making; the ones whose number one job isn’t really encryption.
Finally, the third problem is that of the techniques and horsepower available to crack your password. The scenario is simple. Someone has a copy of your encrypted document and they want to open it. Since they have it, they can apply an arbitrary amount of computer resources to simply trying everything, and they can do so for as long as they like. This is where the concept of “billions of guesses per second” kind of thinking really applies. You see that often come up when we talk about various types of encryption schemes, or the length of your password. You make an assumption about how many guesses they can make per second, do some math, and you find out that your password can be cracked in thirty seconds or thirty years.
It’s also where well-intentioned decisions on encryption algorithms by the application creator can actually make or break their practical security. Those kinds of decisions can in fact make the difference between thirty years and thirty seconds, regardless of what kind of a password you choose.
The practical reality
I know, it all sounds pretty depressing so far.
What I’m going to say is this: In general, you’re probably okay. It’s probably safe to assume that most major applications are doing a reasonable job. And yes, a good, long password, complex as possible, is in fact the key to thwarting the types of attacks that are most likely to successfully break in.
But I personally like to think of it this way: Application-provided encryption is great at keeping honest people honest. I’m talking about people who wouldn’t bother beyond perhaps a cursory attempt to try and crack into your encrypted files. They’re just not going to go any further.
On the other hand, if your data is sensitive (and yes, I think your password list would be) and if you believe that people interested in your data might have greater than average resources available to them, then I’d use dedicated encryption software, software that was designed by people who do encryption for a living.
That means tools like TrueCrypt or AxCrypt or LastPass, or several other utilities whose very reason for existence is security and encryption.