Archive for November 15, 2012

Thursday, November 15, 2012 [Tweets] [Favorites]

Kill the Password

Mat Honan:

[Don’t] Use a short password—no matter how weird. Today’s processing speeds mean that even passwords like “h6!r$q” are quickly crackable. Your best defense is the longest possible password.

Longer is better, but aren’t key derivation functions supposed to protect short passwords?

Overall, I think the article gives the mistaken impression that the problem is passwords, when the real problem is the ease of resetting them:

To reset a lost login, you need to supply answers to questions that (supposedly) only you know. For his Apple ID, Pogue had picked (1) What was your first car? (2) What is your favorite model of car? and (3) Where were you on January 1, 2000? Answers to the first two were available on Google: He had written that a Corolla had been his first car, and had recently sung the praises of his Toyota Prius. The hackers just took a wild guess on the third question. It turns out that at the dawn of the new millennium, David Pogue, like the rest of the world, was at a “party.”


They wanted to get into his Google Apps account, but it was protected by two-factor. What to do? The hackers hit his AT&T cell phone account. As it turns out, AT&T uses Social Security numbers essentially as an over-the-phone password. Give the carrier those nine digits—or even just the last four—along with the name, phone number, and billing address on an account and it lets anyone add a forwarding number to any account in its system. And getting a Social Security number these days is simple: They’re sold openly online, in shockingly complete databases.

Prince’s hackers used the SSN to add a forwarding number to his AT&T service and then made a password-reset request with Google. So when the automated call came in, it was forwarded to them.

(Apparently, this two-factor authentication was using SMS rather than Google Authenticator.)

Update (2012-11-15): Daniel Jalkut:

Of course Honan has had a little more practice than me with this, and when he saw my tweet he was inspired to ask if he could give it a shot. He and I are friends, and I trusted him to do nothing more than test the security of my account, so I agreed. He said it might take a day or two. A few hours later he sent me a screenshot of the AOL page where it was helpfully offering to let him enter a new password for my account.

I simply hadn’t tried diligently enough to get through the ridiculous “security” wizard. In the end it was as simple as knowing that I grew up in Santa Cruz (a value that I had evidently chosen to enter accurately), and that my email address was my last name at “” Totally, outstandingly, ridiculously poor security.

+[NSURL URLWithString:] Changed

Mike Abdullah:

Once again it’s not in the URL documentation, but the behaviour of these methods actually depends on which SDK you link against. When running on OS X v10.6, or linking against the 10.6 SDK while running on a newer OS, they throw an exception when handed nil. Just like the other methods above.

If you link against the 10.7 SDK or newer, and are running on 10.7 or later, you instead get the more sensible & friendly behaviour of them returning nil. This change doesn’t even get a mention in the Foundation release notes!