Simple Passphrase Conundrum

August 4th, 2012

My sympathies go out to Mat Honan who, as he puts it, “was hacked. Hard.” After exploiting his iCloud account, the attackers took over his Gmail account, and proceeded to remote-wipe the contents of his iPhone, iPad and Mac. He states in his recollection of the tragedy that the compromised Apple ID had a 7-character passphrase, and had remained the same for many years. The relative weakness of the passphrase, combined with the long period of time, presumably gave hackers the opportunity to guess the passphrase by brute-force. I hope we will learn more about the specific details of the attack, because it will help inform how the rest of us can better protect ourselves.

Assuming the weak passphrase was indeed the root of the exploit, the obvious way Mat could have protected himself is by choosing a more sophisticated one. But as Michael Rose of TUAW points out, the increased security brings with it significant costs in day-to-day frustration: the Apple ID passphrase is demanded for many user actions involving Apple’s store and syncing services. The particular difficulty of typing complicated phrases on the iPhone has led some folks to intentionally choose simpler passphrases.

Apple and other tech powerhouses such as Google, Facebook, and Twitter, hold increasingly large amounts of power over not only the information we store on their servers, but on other services, to the extent we’ve granted them the privilege of authenticating our identities. An issue in Mat’s case was that once the hacker had his iCloud email, he or she was able to compromise Gmail by following the “forgotten passphrase” for Gmail. Services such as Twitter that don’t host email face similar vulnerabilities: many services, including but not limited to games, offer to use Twitter authentication to log in. In this situation a compromised Twitter account means all the services you’ve entrusted to Twitter are compromised as well.

One way to protect yourself is by declining to delegate authentication to third parties. When enrolling in a new service that offers Twitter or Facebook authentication, I usually go through the nuisance of creating a new account instead. That way I can choose a unique passphrase, and store that in my keychain. I prefer this to allowing numerous items to be implicitly added to my Twitter or Facebook “keychain.” Don’t put all your eggs in one basket, as they say. (Well, that’s what I’m doing with my keychain, but I am empowered to personally protect it and to back it up as I see fit.)

On my iPhone, I chose an exceedingly difficult passphrase after reading about how relatively easy it is for hackers to brute-force the code in hardware when they possess the device. I also chose a very short, 1 minute lockout period, and opted to let it wipe my data clean after 10 failures. These steps minimize the chances that a thief will be able to access my data. But this is a royal pain in the ass in practice, as I’m constantly required to fumble with my phone, keying in this monstrous phrase.

Apple, and other companies who hold the “keys to the castles,” can help by developing technologies that empower us to apply increasingly strong protections while at also minimizing the day-to-day hassles of a complicated passphrase. For example, I would be happy to use a simple 4-digit passcode that unlocked my phone, if a longer passphrase was demanded after an hour of inactivity. This would allow me to use my phone in confidence that it would be fairly hard to unlock quickly without the passcode, and that a thief would only have an hour to make that happen before the phone entered “strong lockdown” mode.

Apple seems interested in evolving their authentication strategies: they recently acquired AuthenTec, a fingerprint-sensor manufacturer. Will future iPhones allow us to unlock our phones with a simple finger-touch? It would be a nice step forward in usability, but I’m not familiar enough with the technology to know if it’s a step forward in security. Other companies are looking forward, as well. Tim Bray at Google recently announced he’d be pouring his energies into identity technologies. A commonly cited approach is two-factor authentication, which is perhaps a way Apple could apply the fingerprinting technology, combining it with a relatively simple-to-type pin code.

Culturally and technologically, we have certainly come a long way from plain-text passphrases stored in a file, but it’s clear there is a lot more to be done. In the mean time, I’ll just be here fumbling with my phone every other minute, cursing Apple as I bask in a moderate sense of security for having jumped through all these hoops.

MarsEdit 3.5.5: Retina Graphics Support

August 3rd, 2012

MarsEdit 3.5.5 is now available on the Mac App Store and directly from the Red Sweater Store. This is a free update for licensed MarsEdit customers.

This release is primarily of interest to customers with Retina MacBook Pro computers: all of the toolbar icons and other incidental art has been updated to appear crisp and beautiful on HiDPI displays.

MarsEdit 3.5.5

  • Updated graphics to support Retina MacBook Pro
  • Fix a bug that prevented the port number from being included in Host: HTTP header
  • Fix a bug that caused drag-and-drop to margins of editor to reload the content of editor with bogus data
  • Fix a bug that could crash the app when customizing toolbar items
  • Fix a bug that crashed when editing tags with VoiceOver enabled
  • Fix view-tabbing cycle in the blog settings panel

If you notice anything out of place, especially relating to the new Retina graphics, please let me know.

Subscribe To Feed 1.0b4

August 2nd, 2012

OK, I know I said I wasn’t particularly going to be supporting the Subscribe to Feed Safari extension I released last week, but it so happens I got a lot of great feedback and even some anonymous code contributions to help beef up the behavior of the plugin.

If you already have 1.0b3 or later installed, you can just check for updates in Safari’s extension preferences. Otherwise, download directly by clicking the name below:

Subscribe to Feed 1.0b4

  • New toolbar icon with Retina display support
  • Support for multiple feeds on a page, selectable from a popup menu
  • Convert from http:// to feed:// for faster, streamlined subscription process
  • Expand the list of MIME types recognized as valid feeds to cover edge cases

Hope you enjoy these fixes and enhancements. Let me know if there are other glaringly missing features or bugs.

Can I Get Your Address?

July 27th, 2012

Mac OS X’s centralized Address Book empowers developers to offer users features that go above and beyond what would be possible in the absence of such a resource. For example, an envelope-printing utility on Mac OS X doesn’t need to demand that you painstakingly type in the name and address of your friend before mailing a letter, you can search for them and automatically select from a list of matching addresses. It’s magic, it just works, and it makes a Mac a Mac.

Many other examples of Mac software just working are also based in accessing the Address Book, but instead of needing access to the whole thing, it’s just the “Me” card that is of interest. This is very useful for example if a map app wants to offer you easy directions home. A very common use case for accessing the “Me” card is when an application has good reason to pre-populate personal fields in an inquiry form of some kind: for example, a feedback or crash reporter dialog. In this case, putting the user’s email address in the field for them saves a step and prevents a possible typo.

Starting in Mountain Lion 10.8, Apple has dramatically increased security protections around the contents of users’ Address Book data. On the face of it, this is a good thing, as it protects against applications that either surreptitiously or stupidly access and upload the contents of address books to web servers without permission. The flip side is that fairly innocuous requests for the “Me” card are now met with a foreboding dialog:

RSCrashReporter

Yikes! What is Red Sweater Crash Reporter and why does it want my contacts!? Sounds fishy. In fact, all it wants is the “Me” card, but there’s no way for it to let the user know this. Or is there?

Thanks to Cabel Sasser’s tweet today, I learned that there is in fact a way to express intent, albeit with a very crude mechanism. You can’t specify intent on a call-by-call basis, but you can publish in your application’s Info.plist a single string that will be conveyed to the user as an explanation for your need of Address Book data. The key is NSContactsUsageDescription, and it’s very lightly documented in Apple’s Info Property List Key Reference:

NSContactsUsageDescription (String – OS X). This key contains the localizable description of the reason why an app is requesting access to the user’s contacts information in the Address Book database.

It would be far preferable if there were an API mechanism through which an app could request specific content from the Address Book, along with a dynamically stated explanation. But this is better than nothing. Tweaking my crash reporter’s Info.plist, I end up with this:

UserNotificationCenter 1

Incidentally, if you’re a developer trying to add this to your own app, you’ll find it frustrating that the nature of this dialog provides you only one chance to get the terminology right. As soon as you click “OK” or “Don’t Allow”, that’s the last time you’ll ever see this dialog. Unless you happen to know about this magic little command line incantation (thanks to Jim Correia for reminding me):

% tccutil reset AddressBook

That clears out all permissions for your Address Book access, causing the panel to appear again the next time any app, including yours, tries to access contacts.