The transition from MobileMe to iCloud was not without its pitfalls—and losses. The end of support for Apple-hosted websites produced the biggest short-term turmoil, but the writing had been on the wall for the iWeb application for years.

Passwords, on the other hand, are (sadly) not going away any time soon. MobileMe’s Keychain synchronization feature was one of the highlights of the service for me. To replace it, iCloud offered exactly nothing. This was an ongoing pain, becoming worse as the Keychain databases stranded on each isolated Mac slowly diverged from each other.

In Mavericks, blessed relief is just one checkbox away.

The new iCloud Keychain isn’t exactly the same as MobileMe’s Keychain sync. Rather than synchronizing the entire contents of the Mac’s Keychain database, Mavericks adds a new “iCloud” keychain alongside the local “login” and “System” keychains.

iCloud gets its own separate keychain.

If the iCloud Keychain is subsequently disabled, the iCloud keychain highlighted in the screenshot above is replaced with a “Local Items” keychain that has the same contents as the iCloud keychain. Any items added to the Local Items keychain will be pushed out to other devices when iCloud Keychain is re-enabled.

Enabling iCloud Keychain requires traversing a gauntlet of security-related questions rivaled in OS X only by the recently revised FileVault disk encryption feature. It starts with a suggestion to enable a screen lock, if one is not already enabled, to prevent someone from walking up to your unattended Mac and having access to all your cloud-synced passwords.

You can forgo a security code entirely, ask to be prompted for a “complex” security code (i.e., a password instead of a 4-digit code), or ask Mavericks to generate a random security code. Random codes look a lot like FileVault recovery keys (e.g., DCLK-XZEX-XNEB-LGXJ-5UHB-89C3). The “complex” and “random” security code dialog boxes also suggest that people write down their security codes and keep them “in a safe place” because “Apple cannot recover a lost code.”

Finally, if you didn’t opt out of the security code entirely, you must enter a phone number that can receive SMS messages.

At last, the final step: a phone number to receive verification codes from Apple via SMS.

There’s also a first-run setup wizard that will take new users through the same steps before logging in for the first time.

All of this additional security comes into play when you want to enable iCloud Keychain on a second device. At that point, you have two options. You can request approval from another device where iCloud Keychain has already been enabled for the same Apple ID. This request appears in the form of a standard notification dialog.

Approval from a trusted device is one way to activate iCloud Keychain on another Mac.

If you choose to configure an iCloud Security Code, you can enable iCloud Keychain on a new device by entering all three of the following: your Apple ID password, your security code, and a verification code that Apple will send to the configured phone number via SMS.

Usability and security are often at odds with each other. iCloud Keychain bears this out, presenting many more hurdles during the setup process than the MobileMe Keychain sync feature that it belatedly replaces.

Once configured, it mostly works as expected, helpfully offering to remember usernames and passwords in applications like Safari, syncing them to all configured devices, and then auto-completing those values when they’re requested later.

Safari’s Keychain auto-fill, now powered by iCloud.

Safari’s iCloud Keychain integration goes further, offering to auto-generate and then remember passwords for the user.

Accepting the suggested password will also helpfully enter it in the password confirmation field as well. Interestingly, Apple’s own Apple ID account creation website ranks the strength of the auto-generated password as merely “moderate.”

Apple is not impressed by its own password suggestions.

By default, auto-fill still refuses to activate on websites that explicitly ask to disable the feature. Again, the tension between usability and security surfaces. Digging into Safari 7’s preferences reveals a setting that promises to “[a]llow AutoFill even for websites that request passwords not be saved.” Jackpot! But there are caveats. First, enabling this override requires that the Mac be configured to lock the screen when idle. Second, Safari still fails to auto-fill passwords on some websites, most notably Apple’s own icloud.com.

For people with more complex needs, third-party password managers still fill an important role. Similarly, the people for whom “cross-platform” means more than just “OS X and iOS” will continue to rely on the password management and sync features built into Chrome and Firefox.

For everyone else, things are looking up. An Apple-made password manager that’s built into the default Web browser on OS X and works across multiple Macs and iOS devices was long overdue. It’s sure to be a hit among people who—rightly—expect this functionality to work without any third-party software.

Share this story

John Siracusa
John Siracusa has a B.S. in Computer Engineering from Boston University. He has been a Mac user since 1984, a Unix geek since 1993, and is a professional web developer and freelance technology writer. Emailsiracusa@arstechnica.com//Twitter@siracusa