You've likely read about iDict, a very publicly released cracking tool designed to compromise iCloud accounts using brute-force techniques--techniques that try a series of passwords in quick succession in the hope of finding the correct one. According to reports, the vulnerability was patched by Apple within a few days. (Apple has declined to comment, however.)
The developer released the code without providing details in advance to Apple, which is unusual. The standard practice is to disclose this information privately in order to give a company time to patch the vulnerability.
iDict relied on what the author claimed was a "painfully obvious" problem with how Apple dealt with repeated password failures through a particular URL. This kind of issue is similar to reports that came out after last summer's iCloud "hack," which involved a combination of unthrottled password attempts against iCloud and attempts to answer security questions based on celebrities' biographies and other sources.
The iDict developer claimed it bypassed "secondary authentication," which doesn't appear to be a two-step verification hack, but rather a method that allowed the attacker to avoid answering security questions. The tool should now be ineffective as the developer's code-repository page says that Apple has enabled "rate limiting"--a process that tracks the number of queries from a given source or for a given account, and clamps down when a limit is hit.
The anatomy of an attack
But how exactly did it work? Let's examine this attack, your risk of exposure, and what Apple should be doing (but may not be).
iDict and similar remote attacks without special knowledge rely on three elements: a way to perform excessive tests of passwords for an individual account; a way to bypass triggering an account lockout, throttling to reduce queries, or alerts to let the account's owner (or Apple) know that an account is being attacked; and a weak password (and sometimes also weak security questions).
By having a strong password associated with an account--and preferably one that's unique to that account--you bypass nearly all of the risk of having an account hacked through brute force methods, whether through a URL exploit like the one iDict found, or when password files or databases are stolen and cracked over time.
Despite the incompetence at Sony, which allowed IT and other personnnel to store unencrypted passwords in files named "Password," most sites encrypt passwords through a one-way hashing algorithm that transforms the plain text into something that's impractical to decipher. There are weaknesses in an older algorithm--which is still in use out of laziness and lack of updates--that could allow a government agency or criminal enterprise trying to crack individual account passwords to succeed. More sensible sites employ stronger methods.
If you pick a weak password, brute force techniques allow captured, encrypted passwords to be tested with home-computer equipment against billions of passwords per second--yes, per second. In those weakest cases, finding one password match also allows the attacker to find all accounts that use the same password. (What's a strong password? Either make it very long--15 to 20 characters--or it should be a gibberish mix of letters, numbers, and punctuation.)
In the iDict exploit, however, there's no way to get the encrypted form of the password. Instead, the software tests passwords one at a time and, despite no apparent throttle on queries previous to Apple patching the flaw, the code has to wait for Apple's authentication server to reply to each attempt before testing the next.
iDict came with a list of a few hundred default passwords that meet Apple's minimum requirements for an Apple ID (see the image above). These could be added to (or modified by) anyone using the code. Making these short lists even more dangerous, it's possible for hackers to chain attacks. Plus, using passwords extracted from people's accounts on other services, they can attempt to break an Apple ID with an iDict-like exploit using passwords that might have been used by the same person. (Because Apple IDs are email addresses--except for those legacy accounts set up years ago--they allow for easy matching.)
If you're using any password on that list, or anything similar, change it immediately. Better still, if you haven't already, also enable two-step verification (and make sure you know how to find your Recovery Key in the future).
The other two elements required for an iDict attack to work are under the control of Apple, and it concerns me that, after years of running online authentication servers, the company still has these vulnerabilities. Every publicly reachable URL that deals with authentication, password recovery, and the like should have been tested by Apple long ago--and should be routinely tested as updates are rolled out to ensure throttling, monitoring, and notification are still functioning. If all the detals around iDict are accurate, Apple needs to step up its game.
Real world, real problems
I tweeted about iDict after it was released, and shortly thereafter my Apple ID account was locked down for security concerns. This is likely because someone used the iDict software and my Apple ID to see if they could crack my account. Fortunately, I have both a strong password and two-step verification enabled. And, having just written about issues of finding a Recovery Key, I knew just where it was, restored my account access, and reset the key.
Separately, late in 2014, I received a couple of reports about Apple ID or iCloud details being changed in password-protected accounts without any notification or other alerts. In one case, the user's address and phone number were swapped, but apparently to an account used by someone who had nothing to do with the change. If you've had a similar mystery occur, get in touch so I can gather more details.
Glenn Fleishman is the author of Take Control of Your Apple Wi-Fi Network, about configuring and securing your wireless network. He is a regular contributor to Boing Boing and The Economist, and a senior contributor to Macworld.