The Epic Hacking of Mat Honan and Our Identity Challenge
Wired has the kind of article that will make all of us leading highly digitized lives (is that the right term?) wake up in a cold sweat. While the title – How Apple and Amazon Security Flaws Led to My Epic Hacking – may strike many as sensationalist, the article does a good job of showing just how the rappel ropes of our digital lives have mushroomed into a beast that we can’t manage or hardly ever understand the implications of. And if you read deeper you start to see how the way we construct these “daisy chains” that center around email instead of identity are hopelessly outdated and dangerously flawed.
It’s a powerful article at an emotional level too, and I hope the mental images of Mat losing all those digital memories – photos, videos – of the first year of his child’s life gets people to pay attention. But I want to take this opportunity to discuss both the simpler, individual level implications of this as well as the larger identity ecosystem level implications of this.
Please read the article to understand the details and nuances, but for the purpose of discussion I tried to visualize the attack plan that let the hackers take over and erase Mat Hogan’s digital world.
Remember, all they started with was his Twitter handle.
What Does This Attack Reveal?
The factors we rely on to verify identity are (simply put) useless
Apple spokesperson Natalie Kerris told Wired: “Apple takes customer privacy seriously and requires multiple forms of verification before resetting an Apple ID password“. Those multiple forms equates to knowing both the billing address (easily figured out) and the last four digits of a credit card number on file. Information known to anyone you order takeout from. Or any number of daily deal websites, for instance.
Security questions suck (and everyone knows it)
The forgot password procedure does involve correctly answering the security questions set on your account. But we know that the majority of the time, people simply do not remember what answers they set a long time ago, and in an attempt to be helpful to the customer, the “understanding” customer service folks will ignore this failure on the part of the user. Can’t blame them. After all, they have a backup process just for this eventuality (and it is an eventuality). And keep in mind that if the answers are memorable enough for the user to remember no matter how long ago you set them, they are also very likely simple enough for a hacker to figure them out by looking at our digital footprint.
The simplest attack vectors come from bad processes
Taking control of an Amazon account via forgot password requires providing a name, billing address and credit card number as authentication factors. But what allowed the hack to be pulled off was that the hackers could manipulate those factors – by adding a (fake) credit card number to the account – without having to authenticate, because all you need is the email address and the billing address. Amazon has quietly changed this policy now, but this should force everyone to review their policies around data management and customer service. How many times have we had to give our password over the phone to a customer service rep on the other side of the line? [Update: Apple has also suspended their customer reps ability to do password resets over the phone. But then what is someone who doesn’t remember the answer to their security questions supposed to do?]
We need to follow and analyze the trail
If the sequence of separate identity events that allowed the hackers to take control of Matt’s Amazon account had been connected by an audit trail that was being analyzed, then maybe it could have been caught. This is harder done than said, but that’s why identity activity monitoring and identity change monitoring has to be a part of the underlying fabric to detect when manipulating events are underway.
The weakest link
The forgot password feature which relies on simply emailing a reset link to the registered email address is at the heart of these and other exploits. Because it assumes that access to the email address is completely secure. Which it is not.
The key point, if you didn’t already know this, is that a lot of our online security revolves around our email addresses. Not us (aka our identity). And with the wealth of data sources out there now, email security in its current form is increasingly easy to hack.
First, the Simple Stuff
Here’s the basic stuff everyone needs to do.
Make sure you’re backing up your data, and not just on your laptop or desktop. Backup your devices as well. You can even do that over the air now without having to plug them into a computer.
Turn on two-factor authentication for GMail and Yahoo mail. One can only hope that Hotmail and other email-based identity providers follow suit.
Review those little used email addresses that you’ve registered as the backup email accounts for your systems. Chances are, you have a pretty poor password on those. Fix that.
Here’s the Difficult Stuff
First off, identity verification needs to grow up. Yes, Passwords Must Die. But so should Static Knowledge Based Authentication (KBA). Information like billing addresses, school attended, mother’s maiden name are so easy to find in this day and age of rich data sources (social, data aggregators, what have you) that to use them is just inviting the hackers in. Companies like Experian, IDology, Trulioo are using new and innovative ways to address the identity verification needs of your systems. And while this needs to be used in a risk aware context, I suspect that the risk in cases like iCloud is not being properly weighed against the needs of frictionless (not necessarily good) customer service and purchasing ability.
Nonetheless, every business dealing with identity management of customers in any way needs to review their model, and if they can’t externalize identity by allowing customers to Bring Your Own Identity, then they need to review their processes and put much better controls in place than those demonstrated by Apple and Amazon in this case.
You might think that this story also highlights the risks of relying on other systems for identity. And certainly a whole lot of CISOs will be fretting over this point and questioning both identity externalization and cloud. Certainly seems to be a poster child for the Woz’s concerns. But this would be misguided. The breakdowns here occurred because identity was not externalized, and was instead being managed internally using poorly constructed and highly flawed processes that relied on 3rd parties in the wrong way. This was not a zero-trust environment by any definition. And as such, it broke in quite predictable places because there were no mitigating controls.
Furthermore, email providers have to understand that they are now the de facto identity providers on the web, and start acting as such. More than any other service (even Facebook, sorry Mark Z), they hold the keys to the kingdom – in the same way that SSO and Privileged Accounts hold the keys to the kingdom in IT. The level of security needs to be commensurate with this increased importance or risk within the broader identity ecosystem. Two-factor authentication using SMS is a first good step, but the move to identity recognition is crucial for email providers. And the ability to layer in risk-based identity within any identity reliant system becomes even more crucial to mitigate against the domino effect exhibited in the Matt Honan fiasco. That chain could have easily been broken at many different points, preventing his personal disaster from blowing up to that scale.
In a weird (but entirely predictable) way, this also validates the point that Jonathan Sander was making in his blog post ‘Is the ID ecosystem #NSTIC wants too much risk for an IdP?‘. The identity providers are already carrying a huge amount of responsibility in the internet ecosystem, they’re just not being treated (or held accountable) as such. Once we start doing that (and it will happen because of stories like these), they will be at the level where supporting the NSTIC requirements will not add that much more to their risk coefficient. On the flip side, the NSTIC process can be used to accelerate the adoption of smarter, better identity management techniques at identity providers like email providers by laying down clear expectations and guidelines. Hopefully this (and more) will be discussed at the NSTIC steering group meeting in Chicago next week.
I don’t think this will be the last time we hear a story like this. But I do hope that the innovations coming out of the identity community will change the game soon.
Update [8/9/2012]: I have been incredibly gratified at the kind words my tweeps have used in responding to this post and spreading it around. I’ve collected some of them here as a Storify piece – partly because I want to come back to this when I need some encouragement, but mostly because I can use it to make Paul Madsen jealous.
Update [8/9/2012]: I have seen some people use the “daisy chaining” that facilitated the attack as a proof point that federation is bad, and even suggested that this somehow proves that Bring-Your-Own-Identity is a bad thing. Far from it. I’ll address the BYOI argument in a follow up post since it deserves a more detailed response. But on the “daisy chaining” thing, you have to understand that this was NOT a daisy chaining of identities. There was NO federation here. The connection between the 4 different identities and identity infrastructures was one of PII data (data Amazon considered not sensitive, but was used by Apple to verify identity) and communication channels (email messages being sent by the forgot password feature to a hacked account). And I also want to make sure that folks understand that I am not trying to sell two-factor authentication (2FA) as a silver bullet here. 2FA is not without it’s flaws, as demonstrated in the story “New Frontiers in Online Fraud” on page 33 of SC Magazine AU (thanks Simon Harvey for the link). But it does make the accounts less of a soft target. And that’s a big leap forward from status quo for most people.