If he really hasn't used that password anywhere else and it was not based on a dictionary word, then I highly doubt OP's password was brute-forced.
Brute-forcing the iCloud password is an online attack and would probably (hopefully) be caught by apple.
What is more likely is a keylogger or similar malware at which point even a longer password would not have helped. The days where macs are free of malware are unfortunately over.
Or maybe there's a problem with the iCloud auth protocol, and it was snooped? For example, that in-app purchase hack (which involved a MITM attack after installing a custom SSL CA) revealed passwords were being sent "in the clear" inside the SSL transport.
My first impression is that either a session token or password was intercepted from iCloud either via malware or MITM. But the post mentions that the iCloud password was reset, which means the account may have been hacked via Apple ID security questions[1]
When I just did this for my own account, the first security question is your date of birth, which is easy to find for anybody via Facebook. The second was a generic security question.
These are easy to guess or to find out via social media. You could spearfish a user by sending them a free account to a web service and asking them the same security questions on registration.
The security isn't adequate, considering the data that is held behind an Apple ID. I also can't believe they have a delete feature that can not be undone.
For my own account I have done a few things. First I have a secret email address for online accounts that require higher security. These emails are unique for each service and are not published anywhere. I have also removed all of my personal information from my social accounts, such as date of birth, name of school, etc. and my security answers are always random strings.
The other option is that malware was used, or a transparent proxy. If iCloud doesn't verify the server certificate it would be straight forward to proxy the HTTPS requests. iCloud will also always send out connection attempts every x minutes, so if you accidentally connect to a public WiFI hotspot or personal network with an intercepting proxy setup, you can have your password stolen in a matter of minutes.
I am also not super-confident about two-factor auth. I noticed that with Google Apps the verification SMS messages can be read using the web interface for my telco provider. A web interface that is protected by nothing more than an email address and password with the same weak security questions.
I think it is very feasible to hack around second-factor SMS notifications by first hacking the telco provider web interface and reading then deleting the SMS alerts. You are only as secure as the weakest link in the chain.
"I am also not super-confident about two-factor auth. I noticed that with Google Apps the verification SMS messages can be read using the web interface for my telco provider. A web interface that is protected by nothing more than an email address and password with the same weak security questions."
While google DOES have an SMS seconds factor, I highly recommend use their Google Authenticator app [1] instead, which generates the code directly on your phone, sans network communication.
I like your method of:
- Separate, secret accounts for signups
- Random strings (i.e. passwords) as answers for security questions
I've always used a pseudo-password (i.e. it's a standard response of mine that isin't related to the question) for security questions given how weak they are.
Very good point. As a reporter of Gizmodo he might have tried the hack.
I do believe though that sending a password "in the clear" over SSL is totally sufficient. SSL was designed exactly for sending sensitive information like passwords.
We can't blame Apple for not designing a protocol (it might be just plain HTTP basic over SSL) with people in mind that turn off SSL security in order to get access to paid content without paying.
In this case you are betting on captured SSL traffic never being able to be cracked in the future, offline. (Consider: Someone logs SSL traffic and waits for the next Debian OpenSSL bug (DSA-1571-1) to be revealed)
I think it would be a great improvement to have some kind of challenge-response nonce/timestamp hash thing going. So that even if the plaintext of an SSL connection were to be revealed at some point, you couldn't deduce the password-equivalent.
The problem with challenge/response and nonces is that the server and the client both need to have access to something secret to encrypt the nonce with. This usually means storing the plain text password on the server or at least a hash of it which then would be used to encrypt the nonce.
But this also means that when your user database gets lost, all accounts are instantly compromised without the attacker having to do any kind of brute-forcing.
Unless you notice an intrusion immediately, the damage that can be done in such a configuration is way bigger than if the server gets the secret thing from the client and does the hashing there, because now an attacker has to individually brute-force the various accounts (keeping at least those who chose a strong password safe).
Even if perfect forward secrecy was not doable, I assume it's far less likely for an attacker to brute force my SSL private key than it is for them to acquire my user database - not that I want that to happen of course.
That's a good point. On the other hand, with the ECDHE / PFS scheme, aren't you still at risk for an implementation specific bug like the Debian incident? (I.e. the server or client only ever picks the a/b factors from a very limited range?)
Anyways, your suggestion sounds much better than my initial nonce suggestion. :)
Brute-forcing the iCloud password is an online attack and would probably (hopefully) be caught by apple.
What is more likely is a keylogger or similar malware at which point even a longer password would not have helped. The days where macs are free of malware are unfortunately over.