In my last post regarding weaknesses in how 2FA is implemented in the systems we rely on to secure us, I teased a thought that had occurred to me in going through the analysis I presented in the post. As usual, life intervened to distract me, but this recent post by Coinbase sharing their experience of a hack aimed at them brought me back to this. The Coinbase hack attempt was similar to the one aimed at activist Deray McKesson that I broke down previously – it leveraged weaknesses in phone number porting to take control of the number and compromise the SMS-based account recovery channels for various personal services of a Coinbase employee, with the goal of extracting access and money from that employees colleagues.
Coinbase got through it seemingly unscathed thanks to the employee being someone that was quite security conscious and locked down, a swift response from the security team, and some unusual cooperation from the mobile carrier (Verizon). But as the tweet above would indicate, most companies and employees aren’t quite so well equipped to handle a situation like this (if they can even detect it first). I’ll reiterate my past mantra that to properly secure your enterprise, you have to secure the root of all authentication chains, and often times that means tackling the weaknesses that exist in the account recovery process. Replacing SMS-based 2FA with a stronger solution like a Yubikey (or other similar token) doesn’t help if that mechanism has to incorporate a “lost my Yubikey” flow that bypasses the Yubikey authentication and falls back on a less secure channel like sending codes my SMS (like I described about the Apple case in my last post).
However, the Coinbase story also points to (albeit in a upside-down way) the interesting leap-of-the-month thought I alluded to in my last post. The hacker went after the personal services (in this case, Facebook) of the employee first. That’s because the hacker was hoping to leverage the social trust that underlies that communication channel as a means of obtaining access to corporate services (email). It’s essentially a play on the old “I’m traveling and have lost all my belongings; send money” email scam. It works because of the trust engendered by the social network. But why can’t we use that trust for good?
Something that I don’t think gets enough discussion is the social identity verification model. Facebook introduced it in the form of “Trusted Contacts” – a list of your Facebook friends that you select, and which Facebook will utilize to help you get back into an account if other means fail. It’s a model that could work well for other services (Twitter, LinkedIn) built on social networking as well. There are improvements I would make to strengthen the Facebook model – for instance, account recovery relies first on emailing a recovery link, which isn’t great. It also only uses one of the trusted contacts instead of a few of them, which can be abused. But I would argue it is categorically better than SMS-based account recovery.
It also makes the fact that Facebook has their own Authenticator (called “Code Generator”) as part of the Facebook app interesting, because it could solve the root authentication problem that most authenticator apps have. Going back to the principles I outlined in my previous post, a well designed security model would first leverage the authenticator app on the previous phone (protected itself by a biometric so as to mitigate stolen phones) to set up the authenticator app on the new phone. If for some reason that old authenticator app isn’t available (a lost phone for instance, or traded in to get the new one), then the system could fall back on the social network to authenticate the user in recovery mode by leveraging the trusted contacts.
With a little more evaluation by the market and security researchers, a bit more metadata and shared signals work to communicate with relying parties, and some work by Facebook to eradicate the current flakiness in Code Generator, I can see this (or something similar) going a significant way towards making social login more useful for more sensitive (dare I say enterprise) contexts – something our industry has been talking about for a while.