What difference does it make how strong the password is? It was a seven-digit alphanumeric password, right? Is iCloud going to permit up to 36^7-1 failed login attempts in a row without rate-limiting, banning, or launching missiles at the owner of the offending IP address?
Assuming the answer is no, there are only two remaining alternatives: 1) Someone targeted and keylogged him to obtain the password, in which case it doesn't matter how strong the password is; or 2) Someone hacked iCloud itself and stole their (presumably unsalted) password file.
In that case, yeah, a stronger password might've helped. Bad user. No cookie.
But if he thinks he's having a rough night, consider what scenario #2 would mean to Apple. The impact of an iCloud hack would be measured in multiple billions of dollars of market capitalization.
It's a good point actually - does iCloud in any way prevent multiple account logins?
There's another possibility: he re-used his iCloud password on another account, that was compromised, and someone tried that successfully against his iCloud account.
The bigger issue, as someone else has said, is putting so much remote control behind a single point of security.
The strength of the password is relevant in the scenario where the password was actually brute-forced through an interface. If it was jesus01 (or something else common - typically religious), then it may be an easy hack for the hacker.
iCloud would surely block consecutive, failed login attempts. From the post, reading years and years, opens up the possibility that it may have been something the hacker was following for some time. Therefore, he would have been blocked, but may have come back in 1 week to try again.
The possibility is a bit far-fetched, but it exists. The likelihood that this was actually the case is extremely low.
I _strongly_ suspect the iCloud web login will block brute force attempts. What I do wonder though, is if there's some other place an iCloud/AppleID login can be brute forced without appropriate rate limiting? Maybe an IAP API endpoint? Or an in app advertising endpoint? I wonder if the "check whether an IAP succeeded" API that the "just redirect you dns to my server and add my root cert" "exploit" uses is failing to block brute force attempts?
Even if iCloud allowed 10 failed logins before locking out for an hour, every hour, every day for seven years, that would still only let you crack a 4 digit lowercase-alphanumeric password. I'd be willing to bet that either the attacker took the password from something or that 'alphanumeric' is a misleadingly good description for the password.
The issue I have is that in this case, your AppleID is (normally, by default) the ID you use for everything Apple related - including the iTunes Store.
I really have problems typing long 20 character passwords comprised of every kind of symbol on the iPhone keyboard. It was annoying enough trying to type my Twitter and FB passwords correctly the first time. To type that every time I want to update my applications for free, is not a nice experience for me.
This means someone could wipe my iPod remotely, but I would note that I don't have (use?) any kind of Apple controlled email, so the impact for me would be limited to my card being charged for iTunes purchases.
> Well, if you will put complete remote control of all your devices behind a single, weak password.....
From the post:
> My password was a 7 digit alphanumeric that I didn’t use elsewhere.*
It sucks, but when you've got control of someone's iCloud account (email, and remote wipe of presumably their primary devices), you've put them in a tight spot. One of the many reasons that I use iCloud for my phone and iPad, but certainly not my primary machines (or email).
On your primary machines, you should have at least some form of local backup. I'm using Time Machine with a network drive. If my primary machine fails or gets wiped (whether I did it myself or someone obtained my iCloud password), I can still recover everything from the backup.