If you actually RTFA, it was the client that was hacked, not the bank. The client's passwords were compromised, and then the bank's services were accessed normally with the compromised passwords.
The client's logic is that the bank should take the loss for this. I know we all hate the banks but seriously? You get hacked and suddenly the service I provide to you being compromised is my fault?
A bank is in a better position to protect electronic access to the account than the consumer is. This bank provides simple username/password authentication to an Internet service that allows transfers of hundreds of thousands of dollars at a time to entities that a business has never worked with in the past. Offering that service with that level of protection without assuming any liability for the result is borderline negligent.
So? Linode is in a better position to prevent misuse of my VPS than I am. They can cut it off from the network and they have staff which would notice if it suddenly sent 40,000 emails. Does that make them liable if my server gets rooted because of software I install (say Apache 1.3.1 or something) and whoever rooted it installed a mail server on it to send spam from?
I don't see the analogy here at all. The whole point of Linode is to allow you to take responsibility for your own random software. The point of bank security --- in fact, a good part of the point of banks, period --- is to limit access to your funds.
Imagine if instead of passwords, the typical bank required a four-digit PIN. Imagine the bank did everything reasonable to meet best practices standards for validating PINs (for instance, requiring reset of PIN after N incorrect entries). Would anyone think it was reasonable for a bank to stake an entire business cash flow on a four digit PIN?
In 2011, the password is only marginally more secure than the PIN. That this is for reasons outside the bank's control is no more relevant than it would be with four-digit PINs.
The bank should in all cases be responsible for deploying electronic security measures generally recognized by those skilled in the art as reasonably effective. The bank is in all cases responsible for taking "due care" with the security of its accounts. Leaving them exposed to wild high-value money transfers should, and probably does, contravene the due care standard.
There is nothing that the bank was doing that was so far from the normal practice of securing a website that constitutes negligence. They were even following a published standard.
It's unreasonable to expect the bank to be so overly concerned with their customer's security and excuse the business for not being so with their own.
Whoah. Hold on. Just because the bank runs a Java app on an Apache server running Linux does not make the bank just a Java app.
Hold the bank only as accountable as delicious or Digg for its website. But the security of the bank accounts needs to be held to a higher standard. Having worked with multiple banks on online security, I actually believe they are held to a higher standard (that of "due care"), but that there's a combination of "commercial account" and "insufficiently informed judge" acting against that standard in this case.
1. There was an agreement between the two parties to use this service to access the accounts; it specifically covered the liability of the bank regarding this very situation.
2. At no time where the bank's existing systems compromised technically.
3. The transactions were completed in a manner that the owner of the account themselves did not notice for a period of time. That alone suggests that they were sufficiently "normal" that the bank could not detect them.
4. When the bank did become aware of the unauthorized access, it immediately acted and froze transactions in place and prevented all further transactions from occurring.
Because of all of this, there is simply no way you can find the bank acted negligently unless you just have a hate on for the banks. The only negligent party here was the plaintiff, and that's who should eat the loss.
But first, let me help you out with some research. Here is the FIRST SENTENCE of the SUMMARY OF KEY POINTS section on the FIRST PAGE of the FFIEC's _Guidance on Authentication in Online Banking_. Wait for it. Wait... for... it...
The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.
Now then:
(1) A fine-print clause waiving the banks responsibility for any protection of funds in an account beyond providing a working login prompt should be found unconscionable.
(2) That the compromise in question here didn't occur in a fashion that you recognize as a "technical compromise" doesn't actually make it not a security failure on the part of the bank. By creating a security system that revolved around a security mechanism that literally every bank of Keybank's size and above recognizes and loudly proclaims is inadequate, the bank fielded an inadequate technical countermeasure to attacks and cannot lean on semantic games to hide that fact.
(3) It seems obvious to me that customers should not be expected to be better at tracking anomalies than banks, who spend tens of millions of dollars every year on systems to profile and analyze transactions. Regardless, it does not follow from a customer delay in noticing fraud that the bank couldn't or shouldn't have been expected to see the fraud earlier!
(4) How does it change anything that, once fraud was detected, further fraud was halted? There'd be no dispute at all if the bank continued to allow online criminals to siphon out of a known compromised account. The entire debate is what the standard should be before all parties acknowledge fraud.
You say there's "simply no way I can find the bank acted negligently unless I have a hate on for the banks". Well, I don't have a hate on for the banks. We do work for banks. There are many banks I like. My comments are not motivated out of irrational bank hatred.
† They aren't, by the way, "facts of the case"; each is your interpretation of the facts we're aware of in the case. They are as "factual" as your bald assertion that disagreement with you must imply irrational hatred of banking.
2. At no time where the bank's existing systems compromised technically.
This isn't really true. Banks don't view their systems as servers -- rather a "system" is the technical bits, plus the controls and overall policies. If a bank allows someone else to use your credentials and transfer funds, it's a compromise. They have a responsibility to authenticate the user, not the credentials.
As tptacek points out, the bank was in violation of the FFIEC mandate for strong online authentication. They didn't have sufficient controls to correctly authenticate the client for this level of a transaction.
To be precise, I don't think the FFIEC has a "mandate" for two-factor auth, and I'm not sure how toothy any such mandate would be. But the bank is required by the UCC to exercise commercially reasonable controls, and I don't think you can consider "commercially reasonable" controls that are:
(a) Specifically called out by the FFIEC as inadequate to the task of protecting ACH transfers
(b) Roundly decried as inadequate by practically every large regional bank in the country
(c) The technical focus of massive deployments of reputational and two-factor systems at banks around the country.
Bruce Scheiner said this many many times: it is the transactions that needs to be authenticated, not the client. This is what credit card companies do (sometimes overzealously). The transactions mentioned in the article sound very unusual, a trivial authentication mechanism would have caught them.
The judge is right, since he rules by looking at current laws, but the current laws themselves seem out of date.
Along those same lines, if a hacker took advantage of a vulnerability in the banks application, but only after gaining access to that vulnerability through credentials stolen from a client/customer, is the client responsible for weak credentials protection in that instance as well?
Expecting people who know nothing about security to make an informed decision is unreasonable. It's much like expecting people to choose a building that won't fall over in an earthquake when they aren't architects - the responsibility lies with the architect for claiming that the security is good enough, not with the customer for trusting the expert.
You're suggesting that if I place a lock on your door, and you and I both agree that it is adequate, that it is my fault that you lose your keys and have your TV stolen because I should have known that a lock is not good enough and you should have had an alarm system as well....
Seriously, have some bit of personal responsibility.
The degree of "personal responsibility" you're alluding to here is unreasonable to apply to a regional commercial construction firm. It is simply not feasible for most businesses to keep a password-only protected online bank login secure using general-purpose operating systems, and particular not with Windows.
You're commenting because you know that:
* The firm could have dedicated a machine to do nothing but provide access to the bank account, perhaps from a single-use VM
* The firm could have structured its bank accounts so that only a minimal amount of its cash flow would be exposed to any single compromise
* The firm could have aggressively monitored transfers in and out on a better than daily basis
I'm telling you that (a) getting these things set up is a 5-figure consulting project that no bank tells its client base it needs to do, (b) that it is vanishingly unlikely that the bank made sure the client was informed that it needed to take these steps, (c) that failing to do that and leaving accounts exposed only to simple passwords is probably an example of a failure of due care, and (d) that the simplest and most reasonable way to solve all of these issues would be for the bank to simply strengthen its authentication mechanisms for commercial accounts.
You are placing a ridiculous expectation on the service provider while excusing the client using any form of security at all!
Sorry, but in 2011 it is not beyond reasonable expectation that a password be kept secret. Getting hacked sucks, certainly. Your company being hacked however is not the liability of your service providers, even if they are banks.
Speak to the people deploying multifactor and reputational authentication at major banks, and to a one, they will tell you that it is not considered a reasonable expectation that Windows systems be kept intact in order to secure bank accounts.
Banks can't come out and simply say that because of market realities (there are lots of market realities involving software security that terribly impact your day to day life) and concomitant liability.
The banks we talk to are certainly aware that a significant percentage of the customer-provided client machines are pwned by malware (and not just dumb keyloggers either). The Zeus trojan in particular is currently one of the most-discussed topics in online banking security.
tptacek is referring to that I work for PhoneFactor and we sell a multi-factor auth product to secure against these types of things. You're probably right, and thanks for the input.
It's hard to know when to worry about not disclosing affiliations and when to worry about sounding like a product name-pusher. I felt like I was on such basic facts in this comment that it wasn't so relevant, but I did mention it in a later comment in this thread.
At least in the US, if you didn't put a stern warning about doing up the zipper/velcro in the vest's instruction manual, I'd be willing to bet there'd be plenty of lawyers who would gladly sue you on behalf of Mr. Smith's estate. Sadly, there would probably be some juries who would find in the estate's favor, too.
The client's logic is that the bank should take the loss for this. I know we all hate the banks but seriously? You get hacked and suddenly the service I provide to you being compromised is my fault?
Sorry, the judge is right here.