Two Cheers for Two-Factor

Twitter has added a form of two-factor authentication (2FA) that they're calling "Login Verification". This is big news: Twitter has had a number of notable account compromises recently, culminating in the takeover of the Associated Press account by Syrian hackers. The security community had been encouraging Twitter to join Google and Facebook in requiring a second level of verification for suspicious login attempts, and today's announcement does exactly this.

Twitter's approach works very well for personal accounts; I've enabled it for my account and you should too. Unfortunately, this approach to 2FA is not usable for brand accounts (despite claims to the contrary). In this post we'll look at the kinds of attacks that 2FA is designed to mitigate and see that major brands are still at risk, even with 2FA enabled.

When Login Verification Can Help

Before I explain the shortcomings of this new feature, let's look at how it works. You provide an email address and phone number to Twitter who verifies that you are in possession of both. From that point forward, when you attempt to sign in from an unrecognized device, you'll get a text message with a single-use code that you type in (in addition to your password) before you're allowed into your account.

This second factor (your mobile device) protects against attackers that have managed to obtain your password. There are a few ways this could happen - let's see how Login Verification can help in each scenario:

  1. Your account uses an easy-to-guess password. If your password is "passw0rd" or something else that you can find in the dictionary, then an attacker can guess it using a brute-force search. In this case, requiring a code via SMS would prevent your account from being taken over.
  2. You're using a strong password, but it's duplicated elsewhere. Maybe you're doing the right thing and using a high-entropy password, but you're using it on both Twitter.com and CrazyEddiesDiscountSocialNetwork.com. When Crazy Eddie's database gets hacked, an attacker could get at your strong password and trace it back to your Twitter account. Again, two-factor auth protects you here.
  3. A disgruntled ex-employee has your password. Two-factor auth will help here, but only if the employee no longer has access to the second secret (the mobile device). The idea is that's it's easier to revoke access to a physical token (a mobile device) than a password, which is stored in someone's head and must be changed in order to be "revoked"

The first two attacks can be prevented with good password hygiene - use a strong password and don't use it on more than one service. If your brand is at risk of a Twitter account hijacking, you should already be doing this.

The third scenario creates a new problem: sharing access to a phone. As I pointed out, Twitter's "second factor" works by sending a SMS message to a specific phone number. Since more than one employee accesses a brand's accound, how do you share access to a phone? I suppose you could keep it in a shared physical office, or put it in the hands of a particularly security-conscious team member who can dole out six-digit codes on demand. Ultimately, there's no good way for a team sharing a password to also share a second authentication factor - we'll come back to this problem shortly.

Brands are still exposed to phishing attacks

There's a fourth scenario that login verification won't offer much protection against, and unfortunately it's also the most common attack on Twitter accounts: phishing. If an employee can be tricked into revealing one secret they know (a password) then they can be tricked into revealing an SMS authorization code as well. This is the fundamental problem of sharing passwords in order to share access; you're as vulnerable as your most easily-phished team member. A brand that is trying to share a Twitter account among many individuals now has to jump through a very complex usability hoop (sharing a mobile phone) for a minimal gain in security.

Stop Sharing Secrets

Twitter's security model for brands hasn't fundamentally changed; before, a team had to share one secret (a password) in order to share access; now, they have to share two secrets. To build a system that can truly protect brand's accounts from takeovers, Twitter needs to take a much larger step: get rid of account sharing and create a model for delegated access. The problem with account sharing is that it confuses authentication (identifying that an individual is who they claim to be) with authorization (deciding whether or not an individual is allowed to take some action).

That Other Social Network gets this right. For a very long time, Facebook has not only discouraged, but prohibited multi-user account sharing for Facebook Pages. In fact, it's impossible to "sign in" to a page; instead, a page has many administrators, and each of those administrators signs in to his or her own Facebook account. This has a few advantages: you can add or remove access at the level of individual team members, you can always see who has access (whereas it's impossible to centrally monitor who knows a shared password), and you can audit any account breaches or attacks back to an individual's credentials.

This split between access and identity is completely compatible with two-factor auth; in fact, 2FA works better this way. Each individual on your team has his own password and his own mobile phone for receiving 2FA codes, so there's no credential sharing at all. Until Twitter moves to a proper multi-user system, company accounts are still at high risk of phishing attacks (even with 2FA turned on). Login verification is a step in the right direction, but it won't mean the end of Twitter account takeovers.

Protecting Your Company From Phishing Attacks

Many of the high-profile attacks you've read about lately have come from the same place - the Syrian Electronic Army (SEA). How are they taking down high-profile sites over and over again? Good, old-fashioned phishing attacks. From Sophos:

The suspicion is that the hackers have been targeting potential victims with phishing emails. For instance, if the attackers were to send a convincing looking email to a news agency, claiming to be a link to a breaking news story, recipients might be fooled into clicking on it and being tricked into entering their Twitter account details.

And the Onion just published a detailed piece detailing how their Google Apps accounts were phished in a two-phase attack:

Once the attackers had access to one Onion employee’s account, they used that account to send the same email to more Onion staff at about 2:30 AM on Monday, May 6. Coming from a trusted address, many staff members clicked the link, but most refrained from entering their login credentials. Two staff members did enter their credentials, one of whom had access to all of our social media accounts.

The Onion piece provides rote advice: always use different passwords on apps, and always use strong passwords. But we know from decades of experience with passwords that individuals just don't follow strong password hygiene unless they have tools that make it easier to have a strong password than a weak one.

The other advice offered by the Onion is to use an app such as HootSuite to remove password-based access to accounts. This is good advice for Twitter and Facebook, but there isn't a point solution for each app that you use (and if you're anything like us, you're using dozens).

The best remedy to phishing attacks is to take passwords completely out of your users hands, and mediate all application access through an authentication gateway like Meldium. When you combine this with two-factor authentication, you have a secure front across all of your shared apps that even determined hackers can't compromise. A simple password manager isn't enough - you're really only protected once you've moved all of your passwords off of low-security devices (like employee email accounts, desktops, and browsers) and into encrypted, secure, authenticated storage. And trust us, your team won't miss typing in their passwords every day.

Connecting Meldium to Pardot

Pardot provides a set of world-class tools for email marketing, and we're happy to announce that you can now connect Pardot to Meldium to get a single view of all your user accounts on every SaaS app your team uses. Here's a quick guide to getting started with this integration:

You'll need to be logged in to Meldium as an administrator. On the launchpad, click "Team Services":

Click "Add New Service":

Select "Pardot" in the "Choose a Service to Manage" popup:

You'll need to type in the email address and password you use to log in to Pardot, as well as your API Key, which you can find using this link. Once you've typed in this info, click "Connect" to continue:

The connection will take a few momens to complete. Once it's done, you'll be returned to the "Team Services" page with a summary of your Pardot connection. Click "Users" and you'll see all the accounts you already have in Pardot merged in with your other SaaS apps for a single, holistic view of company access.

Do you have questions or feedback about using Meldium with Pardot, or any other web application? Contact us at support@meldium.com and we'll get back to you ASAP!