I’m sitting here, in the dark, when I should be sleeping. Thinking about how 100 different iCloud accounts were manipulated to give up their secrets.  We should all be taking a hard look at what constitutes account recovery in this day and age of the internet. Disclaimer – I haven’t had a coffee yet this morning.  If I sound like a raving lunatic, this may be why.

As the dust settles, it appears that the attackers walked in the front door.  Well, the side door actually.  Data is sketchy, but it looks like account recovery processes at Apple were manipulated to give access to attackers.  Why can this even happen?

1.  We design only for the Lowest Common Denominator

When an account recovery loop is assembled by a service, it is the same loop regardless of who you are. Or how savvy you are.  Or how likely you are to be targeted for a given threat.  Why is this?   Why not keep the base recovery experience as the one where you get if you can barely spell computer and these password things are scary.  But why not let people with stronger needs self-identify?  Allow people to ask to jump through more hoops, to supply more, and better, information in order to receive more, and better protection from targeted attacks?

I know exactly why this kind of “better security” doesn’t happen.  Because for every JLaw attack, where the security could have helped, there are 10,000 regular people who would turn on a feature like this and then get locked out of their account.  There, I said it. The lowest common denominator is: that the public expects is that even if they do everything wrong, even if they cannot in any reasonable or provable way identify themselves as the actual owner of the account, they should still get their data back.   And the cost of dealing with those 10,000 upset locked-out people, both in PR and support terms is very real.  More real and more common than cost associated with the relatively few that get hacked.

2. We have purposely created a Stateless Machine

When you choose to try to recover an account today, you generally do so in a vacuum.   You are asked to identify yourself, and the information you give is often considered in isolation.  Do these two strings representing your dog’s name and your first school match the hashed strings stored in our database?  Yes?  Great!  Keys to the kingdom!   Doesn’t matter that somebody has been trying and failing to do the same thing three times a day for the last week.  No sense of suspicion is placed on this success as a possible culmination to all those failures.  This is part of why an attacker can keep calling help desks over and over until they succeed, and why they can keep using online forms over and over until they succeed.  Also — see #1, whereby it isn’t that unusual for people to really fail at knowing their recovery information and to still expect success.

The whole reason these systems were built to be stateless is because they were built to scale.  But those requirements need to be examined.   It should also be a requirement to at least try to recognize when an attacker could be systematically probing recovery systems, ranging from digital forms to help desks, maybe even in-person resources, or direct emails to IT staff.

3. We keep the User in the dark

If somebody is systematically probing at a given user’s account, don’t you think it would be valuable to tell them, so that they can try to form their own understanding of their safety?  If you’ve locked yourself out of your account, I’m sure you won’t mind the notifications.  And if you haven’t locked yourself out of your account, those notifications may be very important. For example, receiving a notification from every one of your email accounts and your bank in a 24 hour period is something that may not be so significant to each system, but should ring serious bells for the individual.  There are programs like Shared Signals that are evolving to help with cascading identity attacks, but for now, the only person who might see the pattern is the user.   And they are not involved in the process.

4. Users don’t care until it’s too late

It’s true.  There are lots of optional things people could do to be safe that they never bother with.   But perhaps, if there was a way to make users aware of recovery question guessing attempts against their account, users might get scared a little sooner, and carefully contemplate their options.

The WORST THING about this breach

I understand the prosaic duh moment going on where people note that the best way to not have naked pictures stolen is to not have naked pictures taken.  But this should in no way mask the failure that has taken place from an implementation standpoint.  We need to safely store and share sensitive things. As a society. We need to trust that accounts we create and populate with our most treasured data are not just swiss cheese for anyone willing to stalk a specific target.  The old canard of “Doctor it hurts when I do this”/ “then don’t do that” doesn’t help if the underlying problem is disease rather than a boo boo.  This issue is not a boo boo, and turning the iphone camera off will not prevent the spread of the disease, it just prevents one symptom from showing.

Recommendations

If the identity fairy came to visit and granted me three wishes, here is what I would wish for.  These aren’t qualified recommendations in any sense — just a place to start.

1. Provide options for users to customize their own recovery ritual.
   1. Include things like
      1. Turning on notifications for events like calls to the help desk or for use of the password reset form
      2. Adding additional or alternate recovery steps
         1. Additional identity proofing steps before help desk support will engage  – like requiring a 2FA authentication before the call continues
         2. Requiring that KBA answers be retired (or at least flagged for review) after a certain number of incorrect guesses
         3. Turning on additional 2-factor authentication for services that may not normally be protected (see above for an example
2. Architect for recognition of accounts that self-identify (or are verified) as likely targets
   1. Help Desks should be able to recognize high-fraud-risk accounts
   2. Audit and accountability should be elevated
   3. Work towards a point where the system figures out who the high-risk accounts are in real time
3. Track the use of recovery mechanisms, and make the history available to the user.
   1. How many times has a recovery question been used
   2. How many times has the form been submitted with the user’s user name
   3. How many times and when has the help desk been notified

The sun is long-up now. Time for reflection to end, and reality to intrude again…

A few weeks ago, a convicted sex offender abducted a 10 year old girl from a shopping mall in my hometown (link).  The attacker posed as a police officer, but when the girl asked too many questions, she was simply picked up and carried to a van, which then sped away from the mall. Even as the girl’s father searched the mall for his daughter, police pulled over the same van for speeding.  The officer at the traffic stop ran the attacker’s drivers license, gave him a ticket, and let him go.

At the time police pulled over the van, there was no public bulletin, no specific information about a kidnapping, nothing to make the officer suspicious about the man and the girl.  That officer had only one source at his disposal that could have caused him to question the situation in front of him: data delivered from a search on the drivers license of the attacker.  The officer should have been able to see that the man was a convicted sexual predator with a violent history towards children.  Did the officer actually see this data?  I don’t know.  If the officer did have access to that information, he did not make a correlation between the van’s passenger and the impropriety of a sexual predator being alone with a child. It is always easy to connect the dots after the fact  of course, but the real question is:  how could that police officer have been assisted in connecting those critical dots in real time?  What needed to change in that situation to cause an inkling of suspicion, just enough for a few extra questions, a slightly more in-depth interview?

The ultimate goal of the identity management industry is to have correct information available in the moment when it is needed, presented in a fashion that changes decisions for the better.   We have fancy names for this: corporate agility, visibility, business intelligence and so on; but those fancy terms go away when I think of that night, that scared little girl, and the police officer who didn’t understand the context of the situation in time to help.

In this case the story had a happy ending:  the attacker, likely realizing that the police would eventually put two and two together, dropped the girl off unharmed at a fast food restaurant.  What remains are questions from the community – the next time an officer happens to be in the right place at the right time, will the availability, accuracy, timeliness and relevance of the data he has access to save a life or cost it?