|
|
Reply to Concerns
There seems to be a lot of confusion about the purpose / methodology of this hint, but unfortunately, I haven't had a chance to respond to comments in a timely fashion. So I'm going to roll up my sleeves and try to address the points brought up, if only for the record so it might be useful to someone in the future: The Time Machine backup limitation is a hassle, but I don't understand why people would jump through so many hoops to rig up a homemade encryption solution when FV is a button-push away. Filevault is definitely a good solution for the majority of people, and I apologize for the FUD (really), but like I mentioned in the post, it's not configurable. I use this method for some sensitive information that I keep outside of the OS X user directory (in the /usr/local/ tree). That doesn't seem possible with Filevault. Also, in the case of disk image corruption (see below), the whole user directory becomes unusable until restore, while corruption of selectively encrypted content won't stop the show completly. If you're wondering if it's really worth the effort, the relevant question is if you enjoy the process. If you don't, then do the easy thing. If you are writing to it while your Mac dies for some reason the end result may be a corrupted file that can no longer be mounted, losing you the whole file & its contents as a result. Well, this is the danger of data on encrypted images. This is one reason I don't like whole-disk encryption or Filevault; if fatal data corruption occurs, you're out of luck until you restore from a backup. If you're only encrypting a few directories of data, you con continue using your computer until you can restore from a backup. Oh, this all assumes that you're keeping good backups. I should have mentioned this, but anyone actively working from encrypted disk images should be keeping regular backups. If you're not, go do that before encrypting anything. I recommend rsync, SuperDuper, and Jungle Disk. As it's corrupted it cannot be mounted for Disk Utility to fix and as it's a file it can't be fixed without mounting. I fully agree about the risks involved, but incidentally, I accidentally corrupted a large encrypted image containing the backup of my entire hard drive about five months ago, but was able to repair the filesystem dmage with Diskwarrior. It's a little expensive and not guaranteed to work so I certainly wouldn't rely on it, but it's not technically impossible to recover from filesystem damage in encrypted volumes. Oh, and if you are running Leopard, sparse bundles are more resistant to corruption than sparse images, and like Toadling mentioned, are much more amenable to backups. What makes the disk image unmount on logout? The logout process unmounts any user-mounted volumes. #---------------------------# Now to Dr. T's concerns: This seemed logical until the discussion of passwords. It makes no sense to assign a long password to the encrypted sparseimage and then put it into Keychain Access that is protected by a weak password. Your keychain password must be strong. I'm not sure where I said that it was a good idea to keep a weak keychain password. I wrote: Of course, if that password is in the keychain, then our keychain password should be relatively secure. By relatively secure, I meant not as long as "venivedivici718a9508a9ce9695778eaedb9df851bc", not as in something trivially crackable, like "popcorn". My keychain password, for instance, is about 10 random characters with numbers, letters, and symbols. It is, as I wrote, relatively secure, easy to type, and enough for my needs. It would be better to go with a longer password, perhaps, but if more security is desired, you could: 2. Store this keychain on a USB key, and set it to mount at ~/Library/Keychains, as described above in step two. This effectively separates the keychain from the disk images, so even a cracked keychain wouldn't immediately compromise your data. I object to the accusation of being illogical. A second point is that you need to securely erase the files that were moved to the sparseimage. Some of that sensitive data may still be readable weeks after completing this process. This is true enough. I should have mentioned this, but I was trying to spin this hint as a medium-level security process. If your data is terribly sensitive, then your best route is to use a TrueCrypt volume with plausable deniability on a brand new hard drive. Tiger's secure erase isn't even 100% reliable; zeroed out data can be retraced by high-tech labs, however slowly; Leopard's secure remove command (/usr/bin/srm) however correctly overwrites sectors with random data. A third point is the issue of securing your Address Book. This makes little sense to me. Most names and addresses are in the public domain, so I don't see how it helps to hide them ... Snip some comments about the futility of securing marginally private data / data synced to an iPhone: My first response to this is that I agree that Address Book / Calendar information is hardly the most sensitive information that a person has on a laptop. That's why you could use this method to encrypt your entire Documents folder in addition to your contacts and calendar. Or, don't encrypt your contacts and calendars at all, and encrypt the few things that you do want to protect. This hint was meant to provide a general method for modularly encrypting data while keeping it easily accessible, despite the title and examples. I personally use this method to secure business documents, financial data, and private source code, in addtion to the data in the examples. I guess I could have been more clear about the generality of this hint, but I thought more people would be interested in the post if a concrete and compelling example was demonstrated. And it is compelling for me, because despite the fact that much of the information in Address Book and Calendar can be gleaned or acquired, I don't necessarily want the TSA (for example) to easily see who I know or what I'm scheduled to be doing when I'm boarding a flight or crossing a border. Finally, the futility argument can be made against your mail in Mail.app as well. The emails go over the internet unencrypted, and furthermore, governments have been quite successful in acquiring email from email providers or outright intercepting them onroute. So what's the point of keeping your mail secured? Again, it's an issue of low-hanging fruit: if anybody with serious resources is after you, you should be employing heavier security. If you're trying to guard against moderate, opportunistic infiltration, securing the local copy of your mail makes sense. Oh, and btw, if you do need to secure your email, you can do it with GnuPG. My business partner and I confidently email each other passwords and financial data all the time using gpg-encrypted mail. The GPGMail plugin makes it possible to have this functionality right within OS X's Mail.app. |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.11 seconds |
|