In the future, instead of giving a third party unlimited access to information in any bank account, we hope to build systems that allow us to “push” information – and only that information agreed to by the customer – to that third party.
• Pushing specific information has another benefit: Customers do not need to provide their bank passcode. When customers give out their bank passcode, they may not realize that if a rogue employee at an aggregator uses this passcode to steal money from the customer’s account, the customer, not the bank, is responsible for any loss.In general I am in favor of minimizing access: allowing the customer to specify the minimal information that should be made available from a bank to any financial software or aggregator. Dare I say "capabilities"?
But I can't help but wonder if Dimon is confounding push/pull and capabilities. And missing the low hanging fruit.
The low hanging rotten fruit in bank and investment company security is having a single passcode that provides read/write access to the entire account. Give your passcode to an aggregator such as Mint or Yodlee, and you are completely exposed - an aggregator employee gone bad can transfer money out of your account.
(Wesabe [RIP] made a point of never storing credentials on their servers - but then could not provide offline access. Even Open Source software such as GNU Cash could be exposed - if inserted malware sends credentials off your system.)
SO WHY NOT CREATE A SEPARATE READ-ONLY PASSCODE ?!?!?
(Better yet, a separate read-only privilege authorized by a public/private key handshake. But that may be dreaming in technicolor (a 1916 technology).)
A separate read-only passcode would enable financial account aggregation - collecting all of your balances from all of your accounts in a single unified view - without allowing the aggregator, or a bad employee thereof, to empty your account.
Sure, a bad guy with your read-only passcode would have a lot of personal information, possibly sufficient to bluff his way into getting more access. But the key thing is, if that happened, it would be the fault of the bank, or the bank employee, that got bluffed - for not having followed procedures to prevent such bluffing. Not the customer's fault.
Sure, a separate read-only passcode would enable read-only services, but would not enable services that require read-write access -- hypothetical example, personal arbitrage, transferring cash between banks to the savings and checking accounts that have the best interest rates and fees. But a read-only passcode would enable an advisor that could recommend such arbitrage: the user would have to enter the read-write passcode to effect the transfer.
So there is a role for Dimon's "only that information that is agreed to by the customer". Ditto Steve Ellis @ Wells Fargo's API to eliminate screen scraping. I.e. there is a role for capability based security. (You can't expect a capability guy like me to say otherwise.)
But one of the most basic capabilities is read-only access. To everything.
(OK, not quite everything: Not information that can be used to steal your identity. Not your social security number. Possibly not your address, or full account numbers. But all account types, balances, transactions, interest rates, special deals... Everything except that which can be used directly to steal your identity.)
The most basic financial data account aggregation service that I want is read-only access. To everything. At all of my accounts. So that I can see all of my balances and all of my transactions in one place. So that transactions can be assigned to budget categories. So that the interest rates and benefits of different bank accounts, investment accounts, and credit cards can be compared automatically.
For example, I regularly travel outside the USA. In my recent vacation I wasted several hours manually reading credit card companies' "foreign transaction fee" policies, ATM coverage, etc. This is something that can and should be automated.
This sort of thing is why I get scared, and a little bit righteously angry, when I hear about Wells Fargo's "Data Aggregation APIs" and Dimon/JPMorgan's "pushing only the information agreed to by the customer".
Like I said: I want to be able to delegate read-only access. To all of my accounts. To all of the information. All current information, and all information that may be made available in the future.
Ideally only to a piece of Open Source financial account aggregation software that I trust (that I have read the code of, and review all patches for - yeah, right, in my dreams). Realistically, to one-and-only-one aggregator that I trust. Possibly Mint. I don't trust Intuit/Mint as much as I trust LastPass (malware inside a password manager like LastPass would essentially have read/write access to almost my entire life[*]). But if I knew that an aggregator like Mint had read-only access but no ability to make changes, I would feel a bit better.
I get a bit worried by APIs because they are, almost by definition, limited. What do you want to bet that there is information that is available on the customer-exposed website that is not available to the API? Screen scrapers will always be with us. APIs, when they are available, should be more reliable. But screen scrapers will always be with us - unless companies make a commitment to making APIs universal. I am not holding my breath.
I get a bit worried by capabilities "pushing only the information agreed to by the customer". Because the customer has not yet agreed to push the classes of information that did not exist at the time of the agreement. So you either have open ended "any information of class X, where the provider decides what is and is not class X for new information in the future". Or the aggregator is denied access to new classes of information until the customer is bothered to authorize access - which is another way of saying "The provider has a de-facto temporary monopoly on certain services."
I get worried by "pushing", because that probably means that the provider (the bank or investment company) can only push to a limited number of recipient services. While it is good to only provide information to services the customer has authorized, and there is some value to having the provider vet or filter obviously trojan data aggregators --- what do you want to bet that your favorite Open Source software is not on their approved list? Or that great new Wesabe/Mint/Betterment financial services cloud based startup that you want to use is not on their approved list?
Email is the only really ubiquitous push service, but we can't even get encrypted email security right yet. I would love to be able to receive my account statements by secure email. (And I don't mean having to log into a different private webmail interface for each provider.) Again, technicolor.
"Push" is sexy. "Push" may be good for real-time fraud alerts. "Push" is good for two-factor authentication. But for my personal accounts, real-time push is overkill. I am not a day trader or market timer. (Looks like I missed some profit opportunities with BREXIT because I am sloe to react - especially on vacation.)
--
I get a bit righteously angry about Dimon saying "pushing only the information agreed to by the customer" and "if a rogue employee at an aggregator uses this passcode to steal money from the customer’s account, the customer, not the bank, is responsible for any loss" because ... well, that's both true, and bullshit.
If the bank really cared about preventing a rogue employee at an aggregator from stealing money from a customer's account, the bank would provide A SEPARATE READ-ONLY PASSCODE.
All of this talk about APIs and push and capabilities is missing the low-hanging fruit wrt security.
And the banks are missing this easy opportunity to increase security wrt data aggregation
either (1) because the banks are stupid wrt security (which may well be true, but, for gosh sake, they are banks)
or (2) because the banks are trying to come up with ways of monetizing these APIs and push services.
The adage "never ascribe to malice what can be ascribed to stupidity" usually makes me feel better - but not in this case.
---
So I want to make a clear public statement, and I want to encourage as many other people as I can to echo, re-tweet, etc. - whether computer security experts, lawyers, hackers or lay-people:
If a bank gives a customer a single passcode that provides full access
And the customer gives that passcode to a reasonably reputable aggregator, like Mint or Yodlee
And a bad employee at such an aggregator uses the passcode to steal money from the customer's account
THE BANK STILL BEARS CONSIDERABLE RESPONSIBILITY FOR THE LOSS
Because it is OBVIOUS that the bank could have arranged for a separate read-only passcode, that would not have given the bad employee the ability to steal money from the account.This was obvious 10+ years ago, when I first started suggesting and requesting this (e.g. in "Contact Us" links on bank and investment company websites).
It was obvious then, and it is obvious now.
It has been obvious for so long that banks have had more than enough time to fix the problem.
If a problem is obvious, and the bank has not fixed it, then it is negligent.
And if a customer is robbed because the bank was negligent, the bank bears considerable responsibility for the loss.
--
The only way we are going to get this fixed is if the banks have financial incentive to fix it. Losing lawsuits will be part of that incentive.
Lacking such a principle of basic responsibility, the banks will try to "fix" the problem of aggregator security in ways that they can charge for, which risk limiting innovation.
No comments:
Post a Comment