Gordon sent in a terrific Dumb Question for us a while ago and I’m finally going to answer him:
Hi Allison – I have a question. You might say I have a dumb question. I wanted to know if password securing your documents is, well, secure. In my case I have a spreadsheet in Numbers that contains sensitive financial information. I use the feature built into Numbers to set a password. By the way if you’re looking for this, it’s located under the File menu.
I have this file stored in iCloud, and I wanted to know how safe this document is, in case some day a nefarious party somehow gains access to my documents stored in the cloud. So, is my document safe by being password-protected, or is that something easy for a hacker to bypass? I await your expert opinion.
Thanks for the great question, Gordon. This is a perfect example of a dumb question because I had a clue of how to start figuring it out but it took me down some fun rabbit holes to get you a complete answer. I’d like to break the problem down into a few separate areas.
Start with a Strong Password
Since you’re a NosillaCastaway, and have most likely heard Bart saying, “stay patched so you stay secure” a few hundred times, I’m sure you’ve learned that you need to have a good password. A good password would include upper and lower case letters, numbers and a few special characters thrown in for good measure. It should be long, say at least 16 characters long.
Personally I always go to the awesome tool Bart built at xkpasswd.net to generate my passwords. Using his tool, you get long, you get complex, AND you get memorable and easy to type. Then of course I immediately put that awesome password into my password manager. By the way, if you get value out of using xkpasswd, Bart has a big yellow donate button on the page.
How is the File Protected?
Now that we have a strong password, we have to look at how the file is encrypted to know if it’s secure. Security experts agree that if you don’t know how they encryption is done, you don’t really know how secure your data.
For example, my favorite messaging tool, Telegram, uses a proprietary encryption algorithm called MTProto. This was developed based on 256-bit AES encryption with Diffie-Hellman key exchange (the good stuff) but their server side code is closed source. Since security experts can’t actually see how it’s being done, they can’t really give it a seal of approval.
Another secure messaging service called Signal, uses AES-256 bit encryption with Diffie Hellman as well, but publishes both its client and server code under an open source license. Signal is considered the gold standard of secure messaging as a result.
Now in our example, we would like to know how Apple encrypts our files if we use their handy dandy password-protection field inside iWork. In the Apple support article on the topic, they don’t say what encryption they use, but they do say:
There’s no way to recover your password if you forget it. Be sure to choose a password you won’t forget, or write it down in a safe place.
That suggests that they don’t have the keys to unlock it, which is a good thing. Still not as much detail as we want.
I did some hunting on our collective behalf and found one interesting tidbit about encryption in iWork. In 2017, a vulnerability was discovered by Philipp Eckel of ThoughtWorks in the way iWork was exporting password-protected PDFs. This is explained in detail in CVE-2017-2391, but explained simply in a security report at apple.com:
iWork used weak 40-bit RC4 encryption for password-protected PDF exports. This issue was addressed by changing iWork export to use AES-128.
I point at this article because in a lot of searching I was unable to find any reference on any official Apple page that explained what encryption algorithm they were using to password protect iWork documents. I can’t imagine though that they would have fixed this vulnerability in PDF export of iWork documents and not thought, “Hey, should we check what encryption we’re using when people password protect their files?” I think it’s a good bet that they at least use 128-bit AES encryption.
I did find a 2012 article from CNET about a brute-force attack on iWork password-protected files. This article from 7 years ago does say that Apple uses 128-bit AES encryption, but since it’s not an official Apple document I didn’t’ want to rely on it.
How good is AES-128?
Now that got me to thinking, what if they’re only using AES-128 when all the cool kids are using AES-256 nowadays? Is 128-bit good enough?
I found an awesome blog post by Agile Bits, makers of 1Password from May 2013 by Jeffrey Goldberg that addresses this topic. The title of the article is, “Guess why we’re moving to 256-bit AES keys”. I’d like to read a couple of quotes from the article:
1Password is moving to using 256-bit AES keys instead of 128-bit keys.
Why do you think we are making this move? If your answer is because AES 256 is stronger than AES 128, you’d be wrong. There is a technical sense in which AES 256 is enormously stronger than AES 128, but in every sense that actually matters for security there is no difference.
While most articles about encryption would make your head spin with or without a propeller beaning, Jeffrey’s article is very human-readable. He explains what AES (Advanced Encryption Standard) is and how the keys work, all in plain English. He explains how 256-bit encryption is mathematically more secure.
But then he switches gears under a section entitled, “Searching for keys is harder than digging up bones”. He uses an analogy of his dog Molly hiding bones from his dog Patty, and how Patty’s method for searching for the bones would be equivalent to a brute force attack.
He explains that if Molly uses 128-bit methods, there will be 2128 potential hiding places for the bones.Patty knows all of the hiding places, on average she will have to search half of them before finding the bone. It turns out half of 2128 isn’t 264, it’s actually 2127 hiding places!
Now going to 256-bit methods, of course Patty would have to search on average 2255 hiding places which is a whole stinkin’ lot harder, but if you think about it, 2127 is already an insurmountable number of places to search, and not just for a dog.
Jeffrey does the math on how long it would take to brute force 2127 hiding places. With today’s super computers, he says it’s 10 quadrillion years. That’s a number that’s a wee bit hard to get your brain around, but Jeffrey even puts that in perspective for us. He explains that the universe is around 15 billion years old, so checking 2127 hiding places would take more than 600,000 times the age of the universe. With a super computer.
I think this says categorically that even if Apple is only using AES128 (and they’re probably using AES256), that’s going to be going to be secure enough even for your financial documents. The fact that Apple says they can’t help you unlock the documents if you lose your password is also encouraging.
Another option
I would be remiss if I didn’t mention that you can take control of this and leave no questions left unanswered about the security of your documents.
I’m sure you’ve all heard of the tool Disk Utility (which lives inside Applications/Utilities). One of its hidden treasures is the ability to create disk images, and more specifically encrypted disk images. If you create your own disk image, you can encrypt it with the level you want and then store the image in iCloud or any other cloud service.
Open Disk Utility and in the File menu, choose New Image → Blank Image. In the bottom right of the window that pops up you can name the disk image, set its size and how it’s formatted, but most importantly you can choose between no encryption, AES128 or 256-bit encryption. Before reading the Agile Bits blog post by Jeffrey, I would definitely have chosen 256, but after what I learned about Molly and Patty searching for bones, I wouldn’t be worried choosing 128-bit encryption.
Once you’ve named and created your encrypted disk image, you can put it anywhere you want, including into cloud storage. Now when you want to open your super secret document, simply double click it, enter the password and the disk will mount on your desktop. Work away on your documents, save, and then eject the mounted disk to keep your data safe from local prying eyes as well as on-line hackers.
With Disk Utility’s encrypted disk images, you can have all of your documents secured with a single password and you know for sure how it’s encrypted.
Bottom Line
I guess I could have done the research and answered Gordon’s question of how safe his document is by saying, “pretty dang safe”, but what fun would that have been?
To add a bit more specificity to the encrypted disk image solution, I would recommend changing the default “read/write disk image” format to “sparse disk image” or “sparse bundle disk image”. This saves actual disk space as it only uses storage for actual content. Since Gordon specifically mentioned iCloud (or any syncing location, ex Dropbox), the sparse bundle is the preferred format. This breaks up the disk image into many little typically 1kb files which makes for easier and more reliable syncing. “Sparse disk images”, on the other hand, are just a single data blob.
[edited] Clarification – Looking at some sparse bundles on my system, the bands (data chunks) are not 1k. On my system they are typically less than 10Mb…..actually most seem to be around 8.3Mb. Ease of sync still applies though 🙂