Skip to content

The Trouble With Passwords (Again)

Part of my efforts to grab my life by the corners and twist it into a different shape was a decision to switch my “primary” computer to be a laptop, rather than the ailing iMac. I’ve almost finished making that move, and have just a few things to move across from the old machine onto this laptop. So I sat down last night to recover some passwords and account information that I had been missing that I knew was in the Keychain on the old machine. And there the hassle began again.

It’s been pointed out, and I’ve ranted about it in the past in different forums, that the Mac OS X Keychain is a parson’s egg. It does a really good job of noting authorisation credentials for software running as the current logged in user, pretty well invisibly, silently and hassle free. Most software that needs authentication credentials has been written correctly to use the Keychain, and as long as nobody swipes both the keychain file and the master password, it’s reasonably secure.

Where the Keychain Access program falls down badly though is usability for a specific but pretty common use-case: being able to bulk-export credentials for import to a different keychain.

It’s not that Apple are unaware of this as a failing in the product, their support forums are littered with people asking how to do a bulk export, and the response is always the same – use the Migration Assistant to move the whole account from one machine to another. And there’s the fallacy in their design world view: Apple desig software with the belief there is a one-to-one relationship between a user and a user account on a single machine. For all their talk about cloud services, they still have this vision of a single user with a single user account instance publishing to the cloud. Bzzt. Wrong. It’s only loosely true for most users, and very wrong for the minority that for one reason or another have different accounts, potentially on different computers, for different uses and contexts.

The canonical and simple example is where I was a few months ago – a main desktop which was a document repository and work bench and media player, and a laptop which contained a subset of documents that were currently being worked on. And a computer at my work place with some internet connectivity, and a strict injunction against plugging private devices into the network. Oh, and the FrankenPuter Windows 7 box I built for games. Getting this to work, in general, was fairly straight forward – I used ChronoSynch to keep specific folders in synch, and Spanning Sync to keep calendars and addresses in synch between the two computers and Google. Using IMAP for Gmail kept mail sort of in synch, and Chrome’s facilities for synching bookmarks between instances via Google works ok.

But two things did not work at all well. There was no good way to keep two instances of Things in synch (but they are [working on that]), and absolutely no way to keep credentials and secure notes in synch (caveat, no way without committing to drinking the 1Pass kool-aid, which I may yet do).

I sat down on Monday night to finally get all the passwords out of the iMac keychain and onto the laptop somehow. Exercising Google-Fu, I found a pretty good AppleScript solution which did the trick, even if it had to deal with the annoyances of the Keychain. The trick was to unlock each keychain before running the script, then for each item in each keychain, as the script was running, click “Allow” on the two modal dialogs that Apple threw up. Somewhere over 300 clicks later, I had a text file with pretty well all I needed in it, and a firm decision to leave the data in a text file for reference, and not muck about trying to get it into the laptop keychain (See, I’m already thinking that 1Pass might be the better solution).

The next part of the puzzle was to get it onto the laptop. Now I’m slightly paranoid about things like this, and wanted to have at least a third copy while I got it across. Ok, it was late at night, and I wasn’t thinking straight. I’ve misplaced my last USB thumb drive (damn, need another), so decided to toss the file onto [DropBox] to aid in the transfer. Which led to the next issue: there was no way I would throw this file into the cloud without it being encrypted, and hard encrypted.

Ok, easy solution there – encrypt it with PGP. Done. Now to install PGP on the laptop… wait a minute, when did Symantec buy up PGP? And they want how much for a personal copy? (As an aside, for an example of entirely obfuscating costs and product options, the Symantec PGP subsite is a masterpiece). When it comes to companies I am loathe to entrust with protection of my secrets, Symantec is pretty high on the list. Ok, second plan, grab MacGPG. I’ve used earlier versions, and have used GPG and its variants on other platforms, and am confident in it. On the other hand, I really miss the point-and-click integration of MacPGP. Fortunately there’s a project under way to provide a point-and-click interface on top of the underlying command line tools, and I’m pretty happy with what they are doing. If you need it, go check out GPGTools, but be aware that you’ll probably need some of the beta versions of stuff – the stable release at the time of writing doesn’t provide an interface for decrypting files. The only thing I’m unhappy about is that it automagically decrypts files for me, without prompting for the pass phrase. So while it’s good for protecting the file in the cloud, it’s not so great for protecting the local copy (yes, I know that there’s little protection if someone swipes the laptop).

Which leaves me with the old hack – create an encrypted DMG with the file(s) in it. It’s a pretty straight forward process:

  1. Run Disk Utility
  2. select “New Image” and specify one of the encryption options. Other than the size and name, the rest of the options can be left as their default.
  3. copy the files into the new DMG
  4. there is no step 4

The only alarming gotcha is that it appears that you can decrypt the image without providing a credential, if you have allowed Disk Utility to store the pass phrase in your keychain. The trick is twofold – first, credentials are kept in a cache for a few minutes after use so that you usually don’t have to provide them in rapid succession. You can flush the cache by locking the keychain again. The second part is that by default the keychain remains unlocked after login. You can tweak these settings by going into the preferences for Keychain Access – I like to select “Show Status in Menu Bar”, and deselect “Keep login chain unlocked”.

All of which takes me off on a ramble from what I was thinking about. It seems to me like the battle to allow and encourage strong personal encryption and digital signing has been abandoned, and the focus has shifted purely to secure use of online services. There are a few personal file protection products on the market, of unknown and unverified strength, and a few more business focussed products. The intended widely available public key infrastructure for general public use never eventuated, subsumed instead by an industry focussed around providing certificates for Web sites and certificates for B2B secure communications.

Apple provides File Vault as a means to encrypt the entire disk, and there are similar products available for various versions of Windows, but the trouble remains that for encrypting a subset of files the software remains dodgy or highly technical. And don’t get me started on digital signatures on mail.

Post a Comment

Your email is never published nor shared. Required fields are marked *