We have entered an era where our commercial transactions are increasingly being conducted online without any face-to-face interaction, and without the traditional safeguards used to confirm that a party is who they purport to be. The attenuated nature of many online relationships has created an opportunity for criminal elements to steal or spoof online identities and use them for monetary gain. As such, the ability of one party to authenticate the identity of the other party in an online transaction is of key importance.To counteract this threat, the business community has begun to develop new authentication procedures to enhance the reliability of online identities (so that transacting parties have a higher degree of confidence that the party on the other end of an electronic transaction is who they say they are). At the same time, the law is beginning to recognize a duty to authenticate. This blogpost post looks at two online banking breach cases to examine what courts are saying about authentication and commercially reasonable security.
An odd result -- we know. We previously reported on the lawsuit filed by Experi-Metal, Inc. ("EMI") and the subsequent motion for summary judgment (and briefs) filed by Comerica Bank to have the case dismissed. As reported in July, the U.S. District Court for the Eastern District of Michigan has issued a ruling on Comerica's motion for summary judgment. To make a long story short, the Court denied Comerica's motion and this case appears headed toward trial (or potentially settlement). In the course of its ruling the Court found that Comerica had utilized commercially reasonable security procedures. However, that ruling had more to do with the language in Comerica's contracts than an actual substantive analysis of the reasonableness of Comerica's security. In this blogpost, we take a look at the Court's ruling.
Back in February 2010, we reported on an online banking lawsuit filed by by Experi-Metal Inc. ("EMI") against Comerica (the "EMI Lawsuit"). As you might recall this case involved a successful phishing attack that allowed the bad guys to get the EMI's online banking login credentials and wire transfer about $560,000 from EMI's account (the original amount was $1.9 million, but Comerica was able to recover some of that). The bad guys were able to foil Comerica's two factor token-based authentication with a man in the middle attack. Comerica did not reimburse EMI for the loss, and this lawsuit resulted. In April 2010, Comerica filed a motion for summary judgment in order to dismiss the case. The motion has been fully briefed by both sides, and this blogpost looks at the arguments being made by the parties
In other posts, I addressed the trend in the United States to require encryption for certain categories of personal data that are sought by ID thieves and fraudsters - especially Social Security Numbers, driver's license numbers, and bank account or payment card details - as well as for medical information, which individuals tend to consider especially sensitive. These concerns are not, of course, limited to the United States. Comprehensive data protection laws in Europe, Canada, Japan, Australia, New Zealand and elsewhere include general obligations to maintain "reasonable" or "appropriate" or "proportional" security measures, usually without further elaboration. Some nations have gone further, however, to specify security measures.
"Exactly what data do we have to encrypt, and how?" That's a common question posed by IT and legal departments, HR and customer service managers, CIOs and information security professionals. In the past, they made their own choices about encryption, balancing the risks of compromised data against the costs of encryption. Those costs are measured not merely by expense but also by increased processing load, user-unfriendliness, and the remote but real possibility of lost or corrupted decryption keys resulting in inaccessible data. After weighing the costs and benefits, most enterprises decided against encryption for all but the most sensitive applications and data categories.