Recently I started evaluating Mint.com as a tool to better track my family’s finances. As I expected, Mint asked me for the user IDs of my bank accounts and credit cards. What I didn’t expect was that Mint would ask for the passwords to these accounts and – even worse – that Mint would store those passwords.
What? Mint asks for and stores in its databases both the account ID and the password to my bank accounts?
Yes, that’s right. Mint does not just ask for the user ID and then work with the financial institution to request from the user and obtain a “read-only” access to the data. No. Mint asks for the user ID and password with which Mint could log in the account and make transactions, such as transfer money out of the account.
To make matters worse, Mint appears to store the password in Mint’s database. Consider the statement below from Mint’s Privacy and Security FAQ (screenshot as of July 18, 2013). While it does not state explicitly “we save your password”, the words “Your online user names and passwords are never displayed” very strongly implies that they are indeed saved in Mint’s databases in a format from which they can be extracted:
While this may not sound scary, consider that your bank itself most likely does not have your password stored in the bank’s database. What the bank most likely has stored is a hash of the password. So even if the bank’s login database gets exposed, an attacker won’t be able to figure out the password – not without a prohibitively time consuming brute force search through billions or trillions of permutations for just one password.
Why is that a problem?
Saving user’s passwords in a format from which the original password can be obtained is a big deal. If Mint’s database and encryption codes are ever hacked, an attacker would obtain the log-on information to every financial account of every user of Mint. Of course, Mint have said on their site that they use separate databases, multi-layered hardware and software encryption, and the like (see Addressing Security Concerns on Mint.com). But all of those technologies are available to and likely used by the other financial institutions, such as the bank in which you have your checking account. The difference is that if both the bank’s and Mint’s login databases are successfully hacked, it would take billions or trillions of times more effort to make the bank’s data usable to the hacker than the data leaked by Mint.
In summary, with this implementation, by subscribing to Mint for the benefit of receiving a “read-only” view of my finances, users must accept as a consequence that if the Mint databases are ever hacked, an attacker would need a few billion or trillions of times fewer resources in order to get to the log-on information than a better implementation would have made necessary.
Could this have been avoided?
Absolutely. The canonical solution to this problem which would not have required users to disclose their password (let alone have their passwords stored in Mint’s databases) is something along the lines of:
- The user provides Mint the user ID to the bank account but not the password
- The Mint servers contact the bank’s servers and request read-only access for that user
- The user logs on to bank account and authorizes Mint to retrieve information
- The bank servers send to Mint a read-only authentication token (which is different from the password, and, when presented, only gives “read-only” access to the user’s data)
- The Mint servers thereafter use that authentication token to retrieve the user’s information from the bank’s servers
With this solution, even if Mint’s databases were hacked, an attacker would obtain only a token with which they can request from the bank the current state of the account. They would not obtain the username and password with which they could log-on to the bank account and transfer money around.
Granted, it’s possible that this solution may not have been achievable, realistic, or cost effective. One can easily imagine this solution was considered and rejected due to:
- Difficulty convincing tens or hundreds of financial institutions to change their infrastructures to handle steps #2 through #4 in a consistent way
- User focus groups showing most users consider 5 steps per account to be too much work
- User focus groups showing most users are not concerned with potential hacking as expressed in this blog
Still, a number of simple yet effective alternatives could have been implemented. For example, Mint could have provided the option to not save the passwords and instead ask the user to enter the passwords each time the user wants an update. Which – assuming typical users have 2 to 5 financial accounts and check their Mint accounts once per week – would have been quite reasonable.
What do you think?
Do you feel that giving away both your user ID and password and the associated risks are a worthy tradeoff in order to get the convenient features of Mint – as the author of Why I Stopped Being Paranoid and Started Using Mint feels? Or does the thought of giving both ID and password make you cringe and close the Mint web page right away? Please leave your comments and thoughts below.