When hackers broke into Mat Honan's Apple account last week, they couldn't answer his security questions. And Apple didn't even care.
When hackers broke into Mat Honan's Apple account late last week, they couldn't answer the security questions designed to verify his identity. No matter, Apple issued them a temporary password anyway, setting off a chain of hacks that laid waste to Honan's digital life.
The security-question failure is just one in a series of flaws that made the attack possible, but this one stands out. What's the deal, Apple? This wasn't a mismatch between two different companies' systems, or the result of Honan's lackadaisical approach to passwords; this was a company disregarding its own measure, saying, effectively, these questions are a joke. We don't take them very seriously.
Why Apple didn't require the hackers to answer those questions is unclear. But even if they had, it's very likely that the hackers would have been able to find the right answers (depending, of course, on the particularities of Honan's questions and answers). The answers to the most common security questions -- where did you go to high school? what is the name of the first street you lived on? -- are often a matter of the public record, even more easily so today than in the 1980s when security questions evolved as a means of protecting bank accounts. A 2009 study from Microsoft Research found that acquaintances could answer such security questions 17 percent of the time, and strangers didn't fare too much worse, answering correctly within five tries 13 percent of the time, though that high figure may have been the result of a homogeneous sample.
Part of the problem is that a good security question is hard to design. As Frank Voisin explains on Quora:
In drafting good security questions, the objective are as follows:
1. Definitive: there should only be one correct answer which does not change over time.
2. Applicable: the question should be possible to answer for as large a portion of users as possible (ideally, universal).
3. Memorable: the user should have little difficulty remembering it
4. Safe: it should be difficult to guess or find through research
Harder than it sounds. Few if any things fit those criteria and are known only by you. Perhaps mother's maiden name was good enough for banking decades ago, but I'm pretty sure anyone with even a modicum of Google skills could figure out my mom's maiden's name (failing on point four). Not to mention that this question is confounding for people who have the same last name as their mother, have more than one mother (same-sex couples, stepmoms, etc.), or whose mother never changed her last name (therefore also failing on point two, and possibly point one). Similarly, questions about high schools, first best friends, pet names, and so on, all make people bend to fit the security-question narrative of a normal life, instead of asking people to create their own question-and-answer sets, failing at least for some people on at least one of these criteria. Designing questions that satisfy these requirements -- in addition to being unsearchable -- may just not be possible.
The whole point of security questions is to devise a way that you can prove to a machine that you are who you say you are, and to diminish the possibility that someone else can fake it. Security questions are really just fall-back passwords, and not very good ones at that. If you want a back-up password, I suggest ... more passwords, regardless of what the questions ask, and just create a system for yourself for tracking those passwords. As commenter MotherSon writes at Schneier on Security, "My mother's maiden name is 4dAm3Y3fv9nIks."
And while we're at it, take Fallows's advice, and turn on your two-step verification on your Gmail. This wouldn't have saved Honan's Apple account, but it would have spared him a lot of other grief. There are few ways more secure to say you are you, than that you have your cell phone in hand, and the unique code to prove it.
We want to hear what you think about this article. Submit a letter to the editor or write to email@example.com.