At least at one point, Mint used a information-clearinghouse by Yodlee that (by my understanding) did not require indefinite storage of actual login credentials for continued service, at least not for all target banks. Instead, after initial authorization, Mint held its own persistent delegated read-only credentials -- but not full read/write and login capabilities. This was essentially like the OAuth-style solution this author advocates (though using a system, Yodlee, that long predates OAuth itself).
I could be wrong about any of this, but I believe this was what allowed Mint to say, among other things, that they could provide your financial information without even knowing your name, and that no possible compromise of their servers could result in bank transfers.
Mint's current privacy info is insufficiently detailed to know if they still use this approach. They say "your bank login credentials are encrypted", suggestive that they retain 'login' abilities, but that might be a simplification or fallback (when the read-only delegation is unavailable).
Unfortunately, describing security in more detail often confuses and unnerves customers more than just saying the magic words that make people feel safe. So most companies, whether they are good or bad at security, oversimplify in their descriptions. (That is: the public descriptions that are most true and useful to knowledgeable users won't win an A/B test, maximizing either conversions or feelings of trust, with most customers.)
Yodlee's a big screenscraping shop (I remember rumors of having large teams dedicated to just keeping the scripts updated). I don't see how any delegated credentials could work in that case.
Mint has switched to Intuit's backend (there was a thread on Quora about this) but I doubt their approach is any different since a lot of banks just don't offer any OFX/other APIs.
I think the argument is that Mint would not need to store the users' raw bank credentials. Yodlee does need to hang on to the raw credentials, but Mint (when they were using Yodlee) only needed to pass them through to Yodlee in exchange for a token.
My assumption was that once Yodlee proved they weren't going away, they could strike privileged deals with banks that obviated the need for screen-scraping, to the mutual security benefit of everyone.
Yes it's a bt scary that mint stores passwords but putting this all on mint is wrong.
For one, don't use Mint if you are concerned about their system arechetecture. Wesabe stored passwords locally and did the scraping from your client side. Unfortunately Mint killed Wesabe in the market but maybe there are similar products out there.
For two, the real fault lies with the banks. Issuing that banks simply need to move to oauth is a joke. There is nothing simple about updating and/or unifying every banks online systems. Many banks run custom software and much of this is very old (but very well tested). Making any changes is a massive undertaking that most banks have explicitly rejected doing. If it ain't broke, don't fix it.
Finally, it's strange to fear getting hacked and losing money because of a non-FDIC insured account in mint. Who is using such banks in general let alone in mint?
As a software engineer, I'm always in awe of how well mint works. They have unified a massive number of disparate services. As a end user I love the value mint provides. As a hacker, putting passwords in makes me uneasy, but I'm confident in the banking institutions I use, and Mint's security.
This security issue is the reason I stopped using Mint. The non-FDIC insured accounts are any investment accounts -- your 401k, your IRA, and wherever you store any money you'd like to be making more on than just "rolling CDs." If you're basically month-to-month with just a few extra months of living expenses, then one might not have many of these accounts. But, for many of us in the HN community, the FDIC-insured portion is significantly less than 1/10 of our assets.
I'm sure that Mint would love for banks to setup an oAuth type authorization system with real APIs (I can't imagine getting around login systems and screen scraping is something they like doing). However, given that some of my banks still don't support passwords with non [a-Z0-9] characters and AJAX (or even an interface that looks like it's not from the 90s) I'm not holding my breath on them getting around to writing an API for Mint.
Is this an american bank thing or I'm missing something? User changeable passwords for banks??
I have accounts in several banks (Europe) and all of them use either a token with pin that generates a one time password or token which you slide your debit card into, enter your pin and generate one time password.
You have to go through the same process for every transaction you make also.
Does anyone know if any specific US banks provide a secondary set of credentials for customers specifically for 3rd party sites (mint) that the customer only wants to allow to have non write access?
On one side of the equation I'm concerned that mint is holding these credentials somewhere, on the other side I'm more concerned that the only thing between someone and all of my financial data is a simple user name and password. No attempt at RBA or out of band/multi-factor authentication to get into my mint account.
I don't know how true this is, but my evidence is based on the fact that I stopped using Mint (because this is that scary). A month or so after I stopped logging into Mint, the account balances stopped updating, without me doing anything on my bank's website.
Mint.com is very useful. He wants to use it, but he wants it to use OAuth or similar systems to communicate with banks via an access token and APIs, not stored passwords and screen scraping.
Knowing how backwards even the big banks are, I doubt this'll come for about 50 more years. Nothing Mint can do...
I got scared of Mint moments after signing up. Don't they intentionally avoid mentioning security on their site because most people don't care? And people who do care will never be satisfied with them storing credentials?
Thanks for pointing that out. I don't remember reading it before.
But, they own up to the one security hole that really bothers me. As a sysadmin, I know there is always a way for employees to get sensitive data. If a program can see it, so can a programmer.
Their security faq says: "Can Mint employees view my bank account numbers or credit card numbers? Your bank account and credit card numbers are stored securely. Your information may be seen by technical personnel in accordance with specified procedures and safeguards governing access in order to operate, develop and improve the Service."
My bank gave me a PIN and a list of transaction numbers (seems to be standard practice in Germany). So I could theoretically let a Mint-like service read my bank statements without allowing them to transfer anything.
I'm completely torn on Mint. I opened an account a couple months ago, and it's neat, but I worry about the security. I'm considering closing my account soon...
I could be wrong about any of this, but I believe this was what allowed Mint to say, among other things, that they could provide your financial information without even knowing your name, and that no possible compromise of their servers could result in bank transfers.
Mint's current privacy info is insufficiently detailed to know if they still use this approach. They say "your bank login credentials are encrypted", suggestive that they retain 'login' abilities, but that might be a simplification or fallback (when the read-only delegation is unavailable).
Unfortunately, describing security in more detail often confuses and unnerves customers more than just saying the magic words that make people feel safe. So most companies, whether they are good or bad at security, oversimplify in their descriptions. (That is: the public descriptions that are most true and useful to knowledgeable users won't win an A/B test, maximizing either conversions or feelings of trust, with most customers.)
Update: Here's an old thread where I had questions, and a link provided by timf contributed to my understanding above: http://news.ycombinator.com/item?id=412715