Why The Twitter Breach Is Bullish for Two-Factor Authentication

Written by chrisco

First, see these headlines and stories:

Now, ask yourself this?

Is having (good) two-factor authentication (TFA) on its Google Apps and Gmail accounts something that Twitter would pay for?  A GToken, perhaps, for each user?

Of course, it is.  And, to answer the begged question: Yes, TFA could have prevented this breach.  NEW: See “The Anatomy Of The Twitter Attack” and consider what would have happened if Twitter would have been using TFA (and it was required for password resets).

It’s the same with many other individuals and companies. In fact, if good TFA is easily accessible, it will become a requirement, not just the differentiator it is now. Companies who tell their customers, partners, investors, lenders, etc. that they use security best practices will have to use TFA.

Mini rant / idea:

It’s 2009, and every person and company who wants should be able to get one token (or iPhone app or whatever) and register/authenticate it with websites that support it (somewhat similar to the OpenID or OAUTH model).

So there might be an OpenTFA.com or 1token.com website (or whatever) where consumers and companies buy these things and developers develop, API, implement, whatever.  BTW, if anyone is interested in those domain names, get in touch.

2010-1-7 Update: 768-bit RSA cracked. For you hackers and crackers out there: CryptoCracker.com, where, for a fee, you can submit a cracking task to a cluster and have it send you the results when it’s done. Price is set according to a matrix: crackable items down the rows and turnaround times down the columns. The harder the crack and the faster you want it completed, the higher the fee.

Best to do everything open source. Many reasons for that, especially with cryptography and security (see your favorite crypto geek / security geek websites).

Why not do this and do it now? Yes, I’m aware of the problems. F-ck ‘em, problems are opportunities.  Actually, people are already working in this direction, including Stina Ehrensvärd, CEO and founder of Yubico. Stina was one of the panelists at the recent TechCrunch event Mike, Petra, Rassami, and team put on in Stockholm last month (official page and BuzzPal Blog page).

Cheers!

PS: Why did TechCrunch get so many links? Because they (Mike Arrington and team) broke and drove the story.

2009-7-17 UPDATE: From this Google blog post: “since 2006 we have supported SAML Single Sign On, a protocol that allows organizations to use two factor authentication solutions such as certificates, smartcards, biometrics, one time password devices, and other stronger tokens.”

17 thoughts on “Why The Twitter Breach Is Bullish for Two-Factor Authentication”

  1. I repeat what I said yesterday:

    Is having (good) 2-factor authentication (TFA) on its Google Apps and Gmail accounts something that Twitter would pay for? A GToken, perhaps, for each user? Of course, it is. (And, to answer the begged question: Yes, TFA would have prevented this breach.)

    Today we have the following TechCrunch article:

    “Google Wants You To Know A Google Docs Redesign Is Coming (I Wonder Why)”
    http://www.techcrunch.com/2009/07/16/google-wants-you-to-know-a-google-docs-redesign-is-coming-i-wonder-why

    GToken coming soon?!

  2. There already is a “one token for every site” solution – VeriSign’s VIP Network. They are OATH based, have a free token for the iPhone, Blackberry and J2ME phones, and use a simple SOAP API for a site to connect to their service. VIP tokens work with over 50 other sites, including eBay and PayPal. http://m.verisign.com

  3. I know there’s lots of tokens and solutions, I use them. I’m talking about something you can use with Gmail and Google Apps. It ain’t available yet. That’s my point. Hence, this blog post, its title, and content. Verisign is crap.

  4. PS: Sorry to knock Verisign, maybe I’m thinking of the old Verisign. Hope they’re better now. I think the Gtoken will eat their lunch, though. What do you say, Google?

  6. An interesting article from 2005 by Bruce Schneier: “Two-Factor Authentication: Too Little, Too Late”: http://www.schneier.com/essay-083.html

    EXCERPTS:

    Two-factor authentication isn’t our savior. It won’t defend against phishing. It’s not going to prevent identity theft. It’s not going to secure online accounts from fraudulent transactions. It solves the security problems we had 10 years ago, not the security problems we have today.

    Unfortunately, the nature of attacks has changed over those two decades. Back then, the threats were all passive: eavesdropping and offline password guessing. Today, the threats are more active: phishing and Trojan horses. Two new active attacks we’re starting to see include:

    Man-in-the-Middle Attack. An attacker puts up a fake bank Web site and entices a user to that Web site. The user types in his password, and the attacker in turn uses it to access the bank’s real Web site. Done correctly, the user will never realize that he isn’t at the bank’s Web site. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user’s banking transactions while making his own transactions at the same time.

    Trojan Attack. An attacker gets the Trojan installed on a user’s computer. When the user logs into his bank’s Web site, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

    See how two-factor authentication doesn’t solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.

    The real threat is fraud due to impersonation, and the tactics of impersonation will change in response to the defenses. Two-factor authentication will force criminals to modify their tactics, that’s all.

    Recently, I’ve seen examples of two-factor authentication using two different communications paths: call it “two-channel authentication.” One bank sends a challenge to the user’s cell phone via SMS and expects a reply via SMS. If you assume that all the bank’s customers have cell phones, then this results in a two-factor authentication process without extra hardware. And even better, the second authentication piece goes over a different communications channel than the first; eavesdropping is much more difficult.

    But in this new world of active attacks, no one cares. An attacker using a man-in-the-middle attack is happy to have the user deal with the SMS portion of the login, since he can’t do it himself. And a Trojan attacker doesn’t care, because he’s relying on the user to log in anyway.

    Two-factor authentication is not useless. It works for local login, and it works within some corporate networks. But it won’t work for remote authentication over the Internet.

  9. From http://www.wikidsystems.com/ (WiKID Commercial Open Source Two-Factor Authentication):

    “The WiKID Strong Authentication System offers the features needed today to meet today tough compliance standards and tomorrow’s threats. Only WiKID can do two-factor session authentication, mutual https authentication to thwart man-in-the-middle attacks and is extensible to perform transaction authentication.”

  10. More info, comments, and links from this post:
    “Password twilight: bad from Gmail, not so bad from OpenID”
    http://tech.kateva.org/2008/09/password-twilight-bad-from-gmail-good.html

    EXCERPT:

    On the bright side, there’s optional two factor identification for my myOpenID account.

    About CallVerifID

    … CallVerifID™ provides the most convenient and cost-effective strong security measure available for OpenID users. An individual can enable CallVerifID™ within seconds to add an additional authentication factor.

    * Easy two-factor authentication for myOpenID
    * Instantly receive a call when signing into myOpenID. Simply answer and press # to authenticate.
    * No extra phone capabilities or text messages. Use any phone.

    The basics of OpenID are pretty simple. From a user perspective it’s like the old Microsoft Hailstorm/Passport scheme — a single un/pw sign-on. So when I use my OpenID to sign on to a web service, I’m redirected to enter my password into the myOpenID site then return to my true destination. I can stay authenticated with myOpenID provider, then I don’t have to keep entering my password as I move from site to site.

    The big difference from Hailstorm/Passport is it’s not controlled by Microsoft, Apple, Amazon, IBM or your cellphone company. All kinds of places can, and do, offer OpenID services — including my many Blogger blogs.

    Of course these services are only as good as the associated security, and Google hasn’t been wining any prizes for their security measures.

    Even MyOpenID is vulnerable, like anyone else, to password theft.

  15. 2009-8-31
    “Amazon Multi-Factor Authentication for AWS Accounts”:
    http://aws.typepad.com/aws/2009/08/amazon-multi-factor-authentication-for-aws-accounts.html#

    An additional layer of protection, once reserved for banks and large enterprises, is now available to protect your AWS account from unauthorized use. This should be especially attractive to our enterprise-level customers, but we expect customers of all types to value the additional security.

    Once activated for your AWS account, our new Amazon Multi-Factor Authentication (MFA) feature requires you to provide a second piece of information (an authentication code) in order to log in to the AWS Portal and the AWS Management Console.

    To activate this feature, you must first purchase an authentication device here. Once you have the device in-hand you can activate it for your AWS account using the AWS portal. From that point forward, you will need to provide your password and the authentication code from the device in order to log in.

    The devices are small, lightweight, and long-lasting. Fraudulent usage becomes much more difficult because a successful login combines something you know (your email address and password) with something you have (the authentication device).

    We are following the OATH reference architecture for time-based one-time passwords. In this model, the authentication device contains a very accurate clock. Once synchronized to your AWS account, the device displays a new set of pseudo-random digits every 30 seconds. The digit stream is based on the current time and the device’s unique serial number.

    Once you purchase an authentication device from one of our participating third-party vendors, use of MFA is free. Each device works with a single AWS account and each AWS account accommodates at most one device.

  16. TehCrunch:
    “Gmail Security Enhancements Expected Tuesday”:
    http://techcrunch.com/2010/03/01/gmail-security-enhancements-expected-tuesday/

    There are two specific changes that we’ve heard Google is implementing. The first is a secondary line of defense when a user has lost his or her password. If a Gmail account is accessed from a new computer, the user will have the option of receiving a text message with a new one time use pass key. They then enter that pass key into Gmail to authenticate themselves and lock out any bad users with access to the account.

    Google is also possibly implementing a different version of OAuth for its contacts exporter (something often used by other services to import Gmail contacts). It’s likely to be OAuth Wrap, an easier to implement version of OAuth. If developers can be convinced to use it instead of harvesting and storing user credentials, there’s less of a security hole.

    These changes are likely in response to the Chinese security incident from earlier this year. A secondary line of security for users would have avoided the Twitter documents leak from last year,

    My comment:
    http://techcrunch.com/2010/03/01/gmail-security-enhancements-expected-tuesday/#comment-946464

    As discussed here at the time of a Twitter breach, Google will soon roll out the Gtoken. You can already use 2-factor with Google, but the Gtoken will be consumer friendly. They’ve got the sales and fulfillment in place with NexusOne. The Gtoken is just a new SKU for the store. It’s win, win, win.

    PS: Amazon already offers “Amazon Multi-Factor Authentication for AWS Accounts” (see the AWS blog from August 2009).

Comments are closed.