Some Thoughts on Two Factor Security

Awhile ago I wrote an Open Letter to Mint.com laying out some major concerns I have with their service and their security implementation.  Almost all comments both here and on Hacker News and Reddit were divided into three categories:

  • From non-Americans: How is a service like Mint.com even possible or legal? US Banks don’t have two factor security?
  • I totally agree that Mint.com and their service is insecure and I don’t use them!
  • I agree that Mint.com needs better security, but their service is great and anyway, it would be too time consuming/too expensive/too hard/too impractical to implement these security improvements.

Between the time I wrote that letter and now, we’ve seen RSA (the only major token based two factor security provider) have all of its hardware tokens compromised to much public uproar. At Sentry Data Systems, we’ve had two factor security implemented for years using time based cookies and additional security questions to challenge users when they were logging in from a device that hadn’t been previously authorized.  This is similar to how many banks in the US do two factor security if they choose to implement it.  While not a HIPAA requirement, we felt that it was a great feature to offer that provided an additional layer of protection.  We’d originally offered RSA SecurID tokens to customers but found that most customers balked at the price, and even if they did use the tokens, many would simply tape it to their computer monitor or keyboard, or they’d forget the token at home which would cause quite the contentious support call. This experience brought to the forefront several issues that I had with hardware based tokens:

  • Casual users or those who didn’t value the two factor security benefit would simply leave the token lying around or affix it somewhere – it wasn’t natural to expect a user to carry one more thing with them day-to-day.
  • If there was a compromise, you have to replace all of your hardware, for everyone, everywhere.
  • They were expensive.
  • They were highly recognizable and screamed to informed observers that you had access to a system that was considered high-value by someone.

I even went so far as to start sketching out an iPhone app that we could deploy for our customers but it seemed like quite a lift to do it well (a correct implementation is key in cryptography systems) and it was with much delight that I ran across an outfit called DuoSecurity based in Michigan. They have really put together a fantastic service that provides both SMS based (challenge/response) and one-time password (via an iPhone or Android app) options for two factor security.  I signed up for the service, installed their package on my Ubuntu Linux server, and within about 15 minutes, I had a very strong two factor solution that avoids all the drawbacks of the hardware token approach…for free.  Yes – they provide up to 10 users for free to let you get your feet wet and see how the system works.  With the token being my phone, I’m not going to forget it, it doesn’t draw attention to itself, I can’t tape it to my workstation, and they can update the software if they need to. If their service goes down, you can configure it to not require the second factor (the default) or you can choose to prevent logins and keep a private key around for last-ditch logins.  Of course, for those of us running cloud based servers, there is still the risk that your hosting account could get compromised giving an attacker shell based access to the machine – hopefully Slicehost and other services will implement this type of additional security soon (Amazon’s EC2 cloud already implements two factor security as an option). Duosecurity can be easily implemented with any web application, a lot of VPNs, and on your Unix/Linux servers quickly and easily.  If you’re doing anything with medical, financial, or other sensitive data you should definitely check them out.  If you just like additional protection for your own servers and services, they’re a great option as well.  Just in case you’re curious: Duosecurity put up a great blog post about the steps they’ve taken to prevent compromise if they came under the same attack as RSA. A few thoughts on improvement:

  • Give me an apt package please!  I don’t want to compile things, and I don’t want to edit configuration files.  These things make it hard to deploy on lots of servers.  I talked with a support rep from Duosecurity and they told me this is in the works already.
  • Put a login form on your website!  They email the login URL to you but I shouldn’t have to remember it.
  • It’s a little unclear to me if the pricing scales well- if I’ve got the same 35 users access 100 machines, does that mean I pay 35x100x$3?  That seems expensive.  Course, it’s still way cheaper than RSA but at least you could bind an account to a token and not worry how many servers you were accessing.  It’s possible that a single user crosses the server boundary, but again, I’m unclear on that.

Bringing it all back to the original point – there is simply no excuse why a service like Mint.com doesn’t use Duosecurity to protect its own user’s logins.  But the second issue still exists – how do banks provide consumers of financial data access without compromising the entire account? A poor man’s solution of sorts could be taken by banks providing read-only accounts for customers that use generated, revokable passwords.  Google takes this approach with its own two factor implementation for Gmail.  You get texted when logging in normally, but for other applications, you generate a password that can be revoked at any point.  It seems like a decent compromise – you can’t control the account from that login, and the password is of sufficient length and complexity that it’s unlikely to be brute forced.  My initial suggestion of using Oauth is essentially the same thing. Congratulations to the guys/gals at Duo Security on providing a really great set of tools for developers and users.  I really hope it catches on and more and more providers begin offering two factor as an option.

The Impending Ad War

A few weeks ago I attended Github’s CodeConf in San Francisco.  While there, I got to meet quite a few really accomplished technologists (hackers) and discuss a variety of projects, processes, programming methods and more.  One of the most interesting moments for me came over lunch while talking to the CTO of a very well known blog which clocks in over 5 million unique visitors a month.  Like most sites of its type, it receives almost 100% of its revenue from ads.  According to him, one of the largest (new) challenges they were facing was that advertisers are beginning to buy ads targeting the blog’s fans from Facebook, not the blog itself.  In other words, to get at the blog’s users, advertisers were paying Facebook less money to directly market to the blog’s fans on Facebook.The more I think about it, the more I think this is a major problem for almost every ad supported site out there, and it could be the pitch that Facebook is using to bolster its insane valuations.  Right now, there are probably no less than a dozen Googlers being kept up at night worrying over this very problem, not to mention the admen at hundreds of highly trafficked blogs and other internet properties.  After all, if I can immediately pitch my competing product to your customers without paying you a dime, I’ve got a huge advantage, you’ve got a huge problem, and Facebook has an unbelievably great strategic position.Maybe you’re reading this and thinking “yeah that’s old news” and it probably is to many, but having never worked at an ad supported organization, I’d certainly never thought about it before.  I’ve also never heard it articulated online, and I’m wondering how many organizations even realize this is happening.  Note there is a two-fold risk here: ad supported properties risk losing ad revenue to Facebook, and they risk exposing their customers to competition.  If you’re an advertiser, you’d much rather know that you’re reaching out to all 10,000 fans of Blog X with the stats to show you who clicked, etc., vs. an anonymous 100,000 impressions.  Note that even if a Blog chose not to have a Facebook page to attempt to combat this kind of thing, Facebook can still harvest those users who “like” the Blog in their profile.Before, I used to think that the benefits of a Facebook presence for an organization outweighed the downsides, but now I’m not so sure, particularly for ad-supported businesses.  It’ll be interesting to see how this plays out.

Christmas – a Time of Giving

Normally around Christmas people are focused on giving.  Giving to family, friends, maybe even coworkers.  Some give time to charities, some make donations to others.  One of my annual traditions for Christmas is giving to the Electronic Frontier Foundation (EFF), a digital liberties organization that fights for freedom of speech online, privacy, and other causes that are generally too technical to garner attention from other organizations.

This year I’m adding a very similar organization to my annual Christmas list, Software Freedom Law Center (Hi Aaron!),  which similarly advocates for issues that increasingly plague and impact our lives, whether we understand them or not.With all the buzz going on right now about Wikileaks maybe you’ve thought about these issues a little more than normal.

Depending on your understanding of the issue or political orientation, it might be hard to believe, but freedom of speech online is a relatively fragile thing.  Maybe it’s because technology appears to be finite and controllable, maybe it’s because online speech travels much faster and is easier to consume, but it seems that governments and governing bodies tend to naturally flock towards the idea of speech regulation of technical mediums.Groups like the Software Freedom Law Center and the Electronic Frontier Foundation work to preserve freedoms on our behalf.

When I say “freedom of speech online” or “freedom online”, we’re also talking about fighting against overly broad software patents, violators of the GPL, warrantless wiretapping of online communications, and a whole bunch of other issues that may seem only tangentially related to speech, but do impact your voice online.In addition to the work they do, I’ve had the privilege of interacting with and knowing a few individuals from both organizations, and they’re great people as well!  So Merry Christmas, and if you’re looking for a great gift idea or a cause to support, check out both groups.

New Trend? Desktop App is Free, Mobile App Isn’t.

I’ve noticed a new trend (at least, it seems that way to me) that seems to be gaining popularity with Micro-ISVs, and that is to give away your desktop application while charging for the mobile app.  I’ve seen it with Plex, Magento, and I’m suspecting this is the strategy behind last week’s (and my new favorite) GTD piece of software Wunderlist from 6 Wunderkinder.  Their new application is simple, beautiful, and runs on Windows and the Mac, while supporting syncing via the web, which fixes my top two annoyances with my current GTD favorite, Things.  They just announced via Twitter today that they’ve open sourced the entire application, but their mobile application is “coming soon”, and my guess is they’ll charge 10 bucks for it, which I’ll happily pay.If this is a new trend with Micro-ISVs, I think it makes quite a bit of sense.  Get users hooked on your mainline offering, even open source it, become the defacto standard, and then charge for the extra bit of mobile functionality.  It solves the “edge case” problem of increasing costs involved when targeting the Big Three mobile platforms (Blackberry, Android, and iOS) and gets people to fork over money where they’re most comfortable – big shiny app stores that make it easy to buy.I think there are some challenges to overcome, but overall it should be a smart strategy.  We’ll see how it plays out, or even if it’s a trend at all.

An Open Letter to Mint.com: Stop storing my bank credentials!

A lot has changed over the last few years.  It seems like forever ago, and yet, it was only in 2005 that AJAX sprang forth and ushered in the buzzword of Web 2.0.  And it’s great – rich applications that are delivered quickly and efficiently allow me to do things online that I never thought possible. And yet, there’s a dark side to the Web 2.0 craze for APIs and tools and importing and exporting data, and that is that we’ve taught our users to embrace man-in-the-middle attacks.  Every time I see a website asking me for my Facebook password I cringe, but nothing pales in comparison to the nightmare that is Mint.com.

I love Mint.com.  They have spectacular visual design, a great product, an entertaining and informative blog, and a great iPhone app.  I know tons of people who love Mint.com, and yet, when surveying my digital life with a critical eye, I know of no greater security risk than Mint.com.  It’s still astounding to me that Mint could grow from a small startup to being acquired by Intuit in the space of a few years and essentially retain unlimited liability by storing user’s logins and passwords to their entire financial lives.  Yikes. 

If I were turned to the dark side, I would immediately attempt to hit Mint for their millions of users credentials which provide me completely unfettered access to their accounts, most of which are not FDIC insured.  This means that when someone hacks Mint, they’ll be able to pull out all of my money, transfer it, etc., and I’ll be responsible because from the financial institution’s perspective they aren’t liable for me entrusting my credentials to a third party. Sure, Mint encrypts their password database, but somewhere that password is known or stored.  It has to be because they have to use my unencrypted credentials to login.  Sure, there are a bunch of ways they could monitor this access and mitigate risk, but at the end of the day there are usernames and passwords floating away.

There is simply no technical reason the financials institutions out there can’t work with Mint and every other API providers/consumers out there can’t implement an OAuth authentication solution.  For the nontechnical of us who are reading this, an OAuth solution is essentially a token based method of authentication.  A key based authentication mechanism doesn’t necessitate handing over your username and password to a third party, instead, you grant a key (and depending on the API, limited access) to Mint which can then login and grab the information you need.  If Mint gets compromised, your financial details might be stolen, but at least they can’t access the upstream account with the same type of access.  In fact, this is what I was really hoping would come out from the Intuit acquisition: for Quicken you used to have your financial institution give you a separate login or key for Quicken specifically. To be clear: this is originally the financial institution’s problem.  They should be providing OAuth based services for Mint and  others to consume.  However, this has now become Mint’s problem to address.  Also, hindsight is 20-20.  What may have started out as a great application for a developer to track his personal finances with an acceptable risk quotient has ballooned into one of the largest and best avenues for tracking finances in the world.

The simple fact is that today, when you change your financial institution credentials, Mint breaks, which means they’re scraping the content from financial institutions.  Financial institutions are in on it too – it should be easy to see that a large percentage of their traffic is coming from one domain.  Even those sites that use a two-factor “security questions” approach are accessed via Mint by saving all possible security questions!  Financial institutions could easily block Mint by adding CAPTCHAs to their login protocols, but since I personally know several users who have changed banks to use Mint, my guess is there’s sufficient pressure to maintain Mint’s access. Some might say that I’m being overly paranoid because we’re used to saving usernames and passwords on our local machines and while it is true that from a direct comparison perspective Mint probably has the security edge over my Macbook Pro, from a risk management perspective it’s quite a different story.  All of a sudden it pays to hire a team of evil programmers for a million bucks to gain access to Mint’s millions of users.  Consider too the fact that most people re-use a single username or password as much as possible – this means cracking a lower security database (a web forum, etc.) can leapfrog access into those same user’s Mint accounts.  The less we’re using usernames and passwords for services, the better. What’s the solution?  I think a three pronged approach should be considered by any modern technical service that holds data of value:

  • Institutions should provide rich APIs in the first place and aggressively prevent screen scraping.
  • APIs should clearly segregate between “read only” and “read and write” access levels.  Mint.com can “read” my financial data but can’t “write” and pull money out of my account for example.  API access could further be segmented to only allow access to pieces of data (e.g. financial sums only and not transactions, or both, etc.)
  • APIs should use account credentials for access, but instead should be key or token based.

This might sound complicated, but in practice it’s very straightforward.  I simply login to authorize a request made by an application (anyone authorized a Netflix device recently?) and that’s it. In an increasingly networked world, application service providers bear increased responsibility to provide safe computing to users.  The old standards of storing usernames and passwords within applications need to change to reflect a different risk model.  This means both providers (financial institutions) and consumers (Mint.com) of data.  I want to use Mint and recommend it to others so I’m hoping that they can bring their clout to bear and work things out with financial institutions to solve this problem.

Here We Go Again

Back in the dark old days of the internet, I started an “e-commerce” business.  I was fresh out of high school, the dot com boom was storming its way toward oblivion, and technology talk was everywhere.  I grew up in China, so I thought, why not become the Amazon.com of Chinese stuff?  China has tons of beautiful traditional artforms that are almost all handcrafted and I thought it would sell well.I was right, mostly.The problem was, I was in school, strapped for cash, there was almost no technology that was any good out there, and getting a real site up was expensive.  As in, 300+ bucks a month for a dedicated server, 100+ bucks a month for credit card processing, 50+ bucks a month for a cell phone, etc. etc.And I had to build the software.  So that’s what I did, and I spent 99% of my time building software just so I could have flexibility and be able to run a “real” ecommerce site.  We built up a customer base, sold some stuff, but I never had the time to devote to it that was required in order to build the kind of business with the kind of product line that I wanted.Fast forward a few years, and now I’m married.  With a wife who’s got impeccable tastes and enjoys fashion, someone who likes learning new things and wants to get things done, and is blessed with one or two (psychology and spanish) of those useless degrees.  So we take a trip to China to see the Olympics, and she comes back and announces that she wants to start up the business again.So here it comes: Unique Traditional Chinese and Asian Gifts and Handcrafted Items – Orient Products (.com)This ought to be fun.