Saturday, July 07, 2012

Password security: what if your desktop were stolen?

For various reasons, in addition to using 1Password (always encrypted), I keep a comprehensive set of family user credentials in a FileMaker database that began life over 15 years ago.

I need it to be accessible to Emily or my estate, particularly if I'm dead or incapacitated. I don't like making it too accessible though; recently a neighbors home was vandalized and some computers were taken. Losing hardware is always a problem, even if you have homeowner's insurance and good backups [1], but losing an unencrypted comprehensive password file is a bigger problem.

On the other hand, I don't need to defend against the NSA. The chances is low that anyone stealing my Mac would even bother to Google ways to browse the file system, or would know how to use FileMaker. It's even less likely that they'd scrape deleted or cache data. I just need need decent security.

Whole disk encryption would be more than decent [4], but I'm running Snowie [2] on the main machine. So I do that just on my MacBook Air. Instead this is what I do for the password file and for similar data:

  • Used Disk Utility to create a 500 MB 256bit encrypted sparseimage in Users/Shared and moved my files to it. These images ignore permissions by default, that's what I want.
  • I set permissions on both the sparseimage file and the mounted disk image to give r/w to Emily and I and nothing to anyone else. (You can't set permissions for the mounted image on the sidebar, you have to navigate the Finder to view the mount)
  • In both of our user accounts I mounted the image and allowed OS X to store the password in the user keychain (so anyone knowing our login pw can get it).
  • In both of our user accounts I added the image to the User Accounts login items.
With these settings every user can see a folder called 'confidential' (hint) but only Emily and I can open it.
 
It's just enough security so that if our home server were stolen I'd be able to revise our passwords over days rather than hours. [3]
 
-fn-

[1] I'm a believer in using two relatively unrelated techniques to do at least daily backup. For me thats Carbon Copy Cloner and Time Capsule/Time Machine with offsite rotation of 3 disks containing clones of varying age.

[2] Not only is Lion a memory/perfomance slug, it's also tied to iCloud -- which has been a bit of a disaster for me. I'm hoping to skip to Mountain Lion; maybe I'll get some features to go with the bloatware and the iCloud malware.

[3] The way I configure CCC deleted files are kept in archives. So after moving the database to the disk image I deleted it on CCC. That's not too bad a risk however because my clones are stored on an encrypted image (for offsite backup). So even if they take my backup disk they won't get much of benefit. If thieves took my Time Capsule I'd be in trouble with copies of the unencrypted file. So I opened TM and told it to delete ALL backups of the file (made me nervous to do that!). So I feel relatively covered, at least to the level of a typical burglar/vandal [4]  But wouldn't Time Machine backup the data to an unencrypted store anyway? Maybe a disk image is a better idea?

Update 7/18/2012: There's an odd permissions bug with creating documents on the shared image that limits this somewhat. Regardless of permissions on either the disk image or the mounted disk, whichever user mounts the image first has the "most" access. That is both users can open and edit existing documents/files, but only the first user to mount the image can create new documents. The second user gets this error message:

The operation can't be completed because you don't have permission to access some of the items.

This happens even though the image is configured to ignore permissions with both journaled and non-journaled MacOS formatted images and with sparseimage and standard image.

The workaround, paradoxically, is to turn off "ignore permissions" for the mounted image. With permissions enabled both users can read and write to the mounted image.

 

No comments: