In June 2015, someone connected to Plymouth University accidentally sent a spreadsheet containing the salaries, pensions and allowances of 245 senior staff to the wrong email address.
The error was reported to the UK’s Information Commissioner (ICO), and the file was said to have been deleted by the recipient. Until, that is, the same file turned up last week in the inbox of a local newspaper from an anonymous source.
The university’s solicitor told the newspaper:
It is clear from the face of this document that this information should not have been sent to you or any third party. We should be grateful if you would delete this information from your records immediately and confirm to us in writing when you have done so.
The file’s sudden reappearance draws attention to the security hole that allowed it to happen at all – the file doesn’t appear to have been encrypted.
On the assumption that the application used was Excel, the breach raises the interesting chestnut of whether using Office’s in-application encryption would have helped.
We say “chestnut” because Microsoft’s integrated document encryption, which allows a file to be protected with a password (not to be confused with document editing protection), has had a mixed press.
A basic problem is that encrypting a document stops other people from accessing it. The password can be shared or stored somewhere, but that undermines the point of security. This inconvenience becomes especially acute when emailing documents to third parties.
The way Office’s document encryption has evolved over time hasn’t exactly helped. Office 97-2003, used the .doc, .xls, and .ppt formats with something called the Cryptography API (CryptoAPI). From Office 2007 on, Microsoft adopted the Open XML Format’s .docx, .xlsx, .pptx with CNG (CryptoAPI Next Generation).
This, logically, made it tricky to send files encrypted in a newer version of Office to versions based on an older design. Office not only had different file formats but different encryption schemes too.
Office’s encryption defaults:
Office 95, 97 and 2000 – forget it.
Office 2002 and 2003 – used the insecure RC4 stream cipher with a 128-bit key.
Office 2007 – started using AES-128 with SHA-1 hashing.
Office 2010 – Still using AES-128 with SHA-1 hashing but SHA ‘conversions’ doubled to 100,000.
Office 2013 – Still using AES-128 but with SHA- 2/512.
Office 2016/365 – up to AES-256 with SHA-2/512 plus compatibility with Office 2007’s CryptoAPI. (Office 365 additionally transparently encrypts files at rest and during transport).
That we have to summarise Office encryption with a complicated list of overlapping capabilities raises the possibility that one reason people don’t use built-in encryption is because they’re mightily confused about what it offers.
As for ways around encryption, even before Office 2013 got off the ground, Russian pro-crackers Elcomsoft claimed they’d found a way around its apparently bullet-proof encryption. Whether they had or not is almost irrelevant. After years of occasional stories around Office’s encryption, perhaps mud was starting to stick.
It goes without saying, of course, that regardless of the encryption used the same rules apply to Office document passwords as any passwords.
The simple takeaway is that only the encryption offered from Office 2013 onwards is worth relying on, but any encryption is better than none, even versions with theoretical weaknesses. If only Plymouth’s incredibly sensitive spreadsheet had used something.