Someone sent me an encrypted Microsoft Excel 2013 spreadsheet the other day. It was based on a request I’d made and contained very sensitive information. The sort of stuff that an identity thief would be interested in. To be frank, I wasn’t thrilled to have received it as an e-mail. Worse, the password to unlock the encryption was in the email.
The data was to be forwarded to a third-party. To do that, I could either forward the e-mail with the file attached or download the file and create a new e-mail. Either way, I wouldn’t be forwarding the password within the e-mail.
It struck me that, by the time this activity was finished, a relatively straightforward e-mail process would have left copies of this sensitive, albeit encrypted, data into multiple places.
In a way, this is almost best case. This assumes I didn’t save a copy outside of my e-mail system, and that my recipient(s) didn’t forward internally to other people or save it in a shared location.
The encryption is a great protection for the file. I was surprised, actually, at how well Microsoft Office file encryption worked. But the difficulty with encryption is that you need to be able to decrypt the information to use it.
In this case, the password arrived in my e-mail inbox. At that point, it probably existed in 2 places – the sent mail of my source and my own inbox. I called my recipient and told them the password over the phone.
There seem to be a number of possible threats to this data. First, the number of places it’s stored as it travels from e-mail account to e-mail account. Each of those e-mail accounts (in our case, cloud-based Exchange) are potentially susceptible to an outside attack. It doesn’t matter how strong your encrypted file password is if it’s in plain text in an e-mail account that has a weak password itself.
Additionally, when sensitive data is placed into a spreadsheet, it may have come from a database that is itself firewalled and protected in ways far more extreme than an encryption password. Consider that, as it leaves that protection, the ability to protect it diminishes significantly, because in order to share it in even an encrypted format, we need to pass it through systems that many more people need to be able to access.
That got me to thinking about all the live copies we’d left in the process. And how most of those would be backed up into e-mail archives or network share or local data backups. The potential risks were growing!
Breaking the Encryption
I was also skeptical about how well the Microsoft Office encryption would hold up. I shouldn’t have, as it was no where near as easy to break as I thought it would be. I subjected two test files (not the sensitive one) created in Microsoft Office 2007 and Office 2013 Excel to a couple of attack tools.
The first one was the old one of just renaming the file from .xslx (or .docx, etc.) to .zip. An encrypted file will take on the appearance of a zip file, but it will complain that it is corrupt or has other problems.
There are also tools available for free on the Web that purport to be able to crack the passwords. I tried two and neither were able to get past the file format. Then I ran dictionary attacks (a word list) and brute force attacks (more complicated lists of possible passwords) against the files. Neither of these worked for me either.
That didn’t necessarily make me feel better. The fact that you could attack a file thousands of times – rather than like your typical online account, where you get 3 times or you are locked out – was disconcerting. It meant that someone with a bit more fire power than I had and better password lists might be able to do it.
As an alternative, I think that, if I was shipping large amounts of personally identifiable information (PII), I’d use an encryption tool outside Microsoft Office. Rather than e-mail, I’d prefer some sort of physical packaging and an overnight shipper like Fedex or UPS.
Alternatively, although this is tricky in small environments, if you have a way to share a link to a secure document and audit it’s access, you could go that way instead of e-mail. SharePoint supports it but then you need to open a connection to SharePoint from the internet. Third-party cloud secure file sharers are an option but I don’t think I’d put this file on a cloud server.
Like an evidence chain, I’d feel better knowing where the data was and that the fewest possible copies existed. Records managers often talk about duplicate files, and we all probably keep more than we should. It’s the inadvertent copies that we didn’t intend to keep that are going to keep me up at night!