Quick tip for convenient file-vaultless encryption of selected files

Well, I want to use Time Machine, and I want to have some encrypted files. Moreover, I want Time Machine to archive those files, and naturally I want them archived in their encrypted form.

But, after a little checking, FileVault did not look like a good option. First of all, File Vault encrypts far too much stuff. Conceptually, the Home folder should contain ALL of a user's data, and there's no reason to encrypt, for instance, all of my application's preference settings that are contained in ~/Library. I just checked, and I have 21,542 files inside of ~, and only one of them actually needs to be encrypted right now.

Second, FileVault sucks with TimeMachine. It only encrypts your home directory while you are in the process of logging out, and only if you have the TimeMachine volume already mounted (i.e., it doesn't automagically mount a network share like it does on a normal hourly backup).

Finally, you don't get to use the galaxy interface to do per-file archival restores when you want to look at a sparsebundle (which is what FileVault turns your ~/ into). You have to manually browse to the .sparsebundle that TimeMachine creates, open it in finder, browse to the .sparsebundle that FileVault creates, double click it, mount it, and find your file there. Then you have to manually copy it and delete the old copy. It's just a big hassle that defeats the Apple-ness of the whole archive and restore process.

Here is a way to avoid most of these issues , while retaining secure hourly archives of all of your files, including the encrypted ones.

Step 1. Create an encrypted sparsebundle in your ~ directory. Mine is secure.sparsebundle. From the point of view of backing up, a problem with disk images is that they are just one file, and differential backups only skip unchanged data on a per-file basis. Whenever the disk image file changes, TimeMachine has to back up the entire new disk image. But .sparsebundles solve this problem, by chopping the image into smaller stripes, or "bands", of data. When you change a file on an encrypted sparsebundle, only the band or bands which contain the file will change, and Time Machine only needs to back up those bands (I think these bands are by default 8mbs wide with no way to change them).

So, create the image in Disk Utility. Chose a secure password and add it to the keychain.


Now, you can double click this file to mount a secure volume in /Volumes/secure. Anything you put in there is encrypted. Because you keychained your password, you will not be asked for it when you mount the disk image. It is very important to remember this password. Files that must be encrypted are naturally also files that are very important to you. Let's make this explicit one more time: if you were to lose your password, you would not be able to open this disk image and your data would be irrevocably GONE FOREVER. No ifs, ands, or buts. No one can help you. And this, after all, is the whole point of encrypting your data: no one can get at it without the password. Because no one can reliably memorize secure passwords anymore, you should chose a secure password, write it down on a slip of paper, and keep that slip of paper in your wallet or a safe. Don't listen to the ones who tell you not to write it down. If you are memorizing your password, that means you chose an insecure password.

Step 2. Automatically mount your secure volume on login. My encrypted file is a plaintext list of all my credentials for websites, etc. Every time I register a new account, or need to login to an infrequently used website, I need to grep the list. I don't want to have to manually mount the volume whenver this happens. I automatically mount mine on login by adding the .sparsebundle file to my login items in Accounts Preference Pane.

Step 3. There is no step 3. Time Machine skips everything in /Volumes/ by default, so it won't backup the plaintext of your encrypted disk image. Meanwhile, it will backup the sparsebundle in ~, even if that volume is mounted.

Ouch. But, my hack works for more than a note. It works for any arbitrary number of files that you might want to be encrypted, without encrypting crap like application support.

And you can't fault me for the security habits of others. Everyone who cares about secure files should know to restrict physical access to their console without my mentioning it. If someone sits down at your logged in computer while you aren't there, it's game over either way. Edit: I just checked, and, on my computer, keychain defaulted to requiring the keychain password when apps access the disk image, and whitelisted the system utility that mounts the image. So other apps will still have to get the keychain password to open the secure volume. Anyway, if you have a trojan on your machine, no amount of encryption is going to prevent data theft. They'll simply keylog your password next time you go to access the file.

But, thanks for your kindness and humor, this is why I love the internet! 😀

Like I said, if you have a trojan, your way doesn't prevent data theft either.

My solution is not just for a single text file. It is offered to anyone who has a use for encryption. Your solution may be better for the specific usage that I have, but I posted this as a complete alternative to FileVault, which mine is, while yours is not. It is exactly as secure as FileVault, in the sense that the FileVault volume is open in plain text whenever the user is logged in. Apple believes, as they should, that the proper barrier to access of sensitive data is at the login layer.

It's too late, once someone is logged in as you, or runs code as you, to talk about security. It's already over; you are pwned. Your way does not protect against this. My way does not protect against this. Apple's way does not protect against this. There is no security drop when you switch from FileVault to my way. There is no security gain when switching to your way, even for a simple password file.

My day job involves risk analysis of financial systems and this is my bread and butter.

Click to expand...

1. Being an actuary does not make you a computer security expert. You clearly are not one.

MikeDTyke said:

Apple's way does protect you, if someone or something is on your machine with your access privs.

Click to expand...

2. Tell me how my way is less secure than FileVault in this situation.

Since you can't, you will have to talk instead about how both my way, and FileVault, are equally insecure, because they provide all sensitive information as plaintext to anyone who can log in as you. If they have your privileges but not your password, my way protects just like FileVault does: keychain will still prompt the application that the attacker is running as you for a password to open the image, and they will be thwarted (the only application that does not prompt for a password is the system utility that opens the disc image, which is whitelisted by the same operation that keychains the file when you create an AES image with Disk Utility). None of this is relevant, however, because once they have your privileges but not your password they can keylog you and escalate to a password.

Once they have your login password, you're just equally screwed in all three scenarios. They log in as you and are immediately presented with a plain text of all files with both the FileVault and Mason hacks. For your way, they'll access a secure note, which presumably will be also tied to the login password (else why store it in the keychain?).

I will reiterate, that once someone has your privileges, the game is over. The deed is done. The fat lady has sung. The cat is out of the bag. Pandora has opened the box. Eve has eaten the apple. Slap me in a dress and call me Shirley, because your data is already compromised.

wrldwzrd89 said:

This is a great tip, and one that I share with other Mac users. If I were you I'd consider getting a Mac Guides entry made with this information, and adding a link to it in the appropriate forum header.

If you don't know how to do this, I will be glad to help. 🙂

Click to expand...

Thanks wzrd. I'm really surprised that this technique doesn't come in Googling. I don't know how to make a guide, if you link me up, I'll check it out.