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.