Mission impossible: protecting against social engineering
Two weeks ago, Naoki Hiroshima’s Twitter username (@N) was stolen. He was, of course, a particularly valuable target, but don’t think you’re immune just because you don’t have a rare twitter id! As more of our lives take place online, the value of our accounts, and the importance of securing them grows.
The details of the attack are as follows: The attacker alleges that using information provided by a PayPal phone support agent, he was able to convince GoDaddy to alter the password and email address on his account. He then intercepted emails sent to Naoki, using it to compromise other accounts. Successful attacks of this kind underscore that even if you follow best security practice and use strong, unique passwords for your accounts, your data is still at risk. So how can you protect your valuable data?
One common suggestion is to turn on two-factor authentication (TFA). TFA, while effective against certain attacks, provides very little protection against the kinds of “social engineering” that worked in this case. This works great until you drop your phone in a puddle. What do you do when you can no longer access the unique codes that TFA requires along with your password? Many services, including Gmail and Twitter, tackle this problem by allowing you to designate a phone number as a backup. If you break your phone, you can log in as soon as your replace it.
This approach means that the weak link in the system is now your phone provider, which isn’t great either. CloudFlare was breached because AT&T was tricked into giving an attacker access to their CEO’s voicemail. Alternatively, an attacker could usurp control of a target’s phone entirely; when I personally needed to get a replacement for my lost SIM card, a friendly T-Mobile customer service representative asked for my name, phone number, and payment, then proceeded to deactivate my old card, transferring my service, without ever asking for ID. Anyone who walked into the store could have easily pretended to be me, and walked out with my phone, and along with it, the ability to receive my TFA codes.
Unfortunately, aside from using strong passwords and enabling TFA, there isn’t much more that individual users can do to protect themselves. Application developers, however, have the power to make great strides in the fight against targeted attacks. Having a “paranoid mode,” which users can opt into is a step that increases security, but at the cost of substantially worsening the user experience. Credit bureaus already support freezing your credit report, which prevents anyone from opening accounts in your name or even seeing your credit history. This service is hard to enable but is mandated by various state laws since it helps to prevent identity theft in the physical world. A corollary could be built for online services: services could allow customers to opt in to a mode that makes it difficult, if not impossible, to recover a forgotten password or from a lost device.
Another possibility is to use real world social connections. Facebook requires you to identify pictures of your friends when you log in from an unknown device. This information is very difficult for an attacker to obtain, making the accounts far harder to steal. The one remaining downside is that some Facebook employees still have the authority to reset a user’s account (though it’s likely subject to many checks and balances).
At Mitro, a password manager for organizations, we’ve recently begun an alpha trial of something similar. Our system encrypts all data with a password (key) and doesn’t offer users a way of recovering their password if they forget it (any service provider that can recover users’ passwords has access to their data). For those who want some way to recover their account, we’re testing a scheme that will allow them to designate their friends as “recovery buddies.” Using secret sharing, we distribute pieces of the user’s key to all these friends (and we hold a piece ourselves). In order to restore access to his password, a customer would have to convince a number of his friends, along with us at Mitro that he was legitimately who he claimed to be, collect the pieces and recover his master password. This makes it incredibly difficult for an attacker; he would need to compromise our service, figure out who target’s friends might be, then individually compromise all of those users’ accounts.
While not perfect, this solution offers substantial benefits over the default service behaviour: employees have no way to unilaterally restore access to customers’ accounts, so social engineering attacks on the company won’t work; users still are provided a method to recover their data; responsibility for authenticating user requests is distributed across users’ friends; and the UX tradeoffs are much better.