Re: Secure Chrome

Phillip, et al,

First, I want to thank you for bringing this discussion back to the
importance of "mutual" authentication where the user is equipped with
better approaches to authenticate the Web site. Improving authentication
of the user to the Web site is solving less than half the problem,
perhaps much less than half. It is also worth noting that even the most
effective mutual authentication techniques do not solve the problem
either, but it is still essential that we substantially improve mutual
authentication between users (i.e., people) and Web sites (i.e.,
machines). As you note, we've got to stop putting off fixing the roof
because the shingles leak.

Second, I would like to point out that FSTC has posted one of the key
deliverables from its Better Mutual Authentication Project on its Web
site. The relevant page is at:

   <http://www.fstc.org/projects/bma-ph-1/>

The "Recommendations and Requirements for Better Mutual Authentication"
document can be downloaded from this page or directly via this link:


<http://www.fstc.org/projects/docs/Recommendations_and_Requirements_for_BMA_v1.0.pdf>

Chapter 3 in this document directly addresses financial industry
requirements for Web authentication, and I believe it reflects many of
the comments made on this list. I should emphasize that this document
pulled together the collective perspectives of the entire BMA Project
team and a variety of other sources. It's value to this group may be
that it attempts to present a holistic view of the current problems,
while recognizing that there are no perfect solutions--just some
important next steps that must be taken.

Feedback is most welcome...
....Chuck


Hallam-Baker, Phillip wrote:
>  
>
>   
>> From: Chris Drake [mailto:christopher@pobox.com] 
>>     
>
>   
>> This is only true when the OS has been compromised by 
>> something specifically targeting your authentication system 
>> (or, like the pile of banking viruses and trojans did, 
>> targeting the more general case of any browser window with 
>> passwords, or that had credit card numbers keyed into them).
>>     
>
> Curently the O/S we have are all pretty fragile. Get into ring zero and its game over.
>
> I agree that strong authentication is also a major concern and yes VeriSign is 110% behind Infocard and the open source realizations of the same. We genuinely believe in getting authentication welded into the O/S at a very low level and making credentials as theft resistant as possible. That is why we have invested so heavily in OATH and recently PIP.
>
> But inbound authentication is only one half of the problem. Unless we also look at ways to authenticate the bank to the customer there will still be ways to perform social engineering. The Internet is only one part of the customer relationship with the bank, many customers do not do internet banking at all, but they can still be targetted by an identity theft where the perp is looking to take out a bogus $50,000 home equity loan in their name. 
>
> We can only get so far with that approach and each step we take is going to be very very expensive. Deploying strong authentication to a bank is unlikely to cost less than some number of dollars per customer even if the hardware itself is free (e.g. OATH authentication provisioned over the air to wireless phones). If you have 10 million customers that is some tens of millions of dollars.
>
> There is only one bank brand and securing that should not in principle be much more expensive than the systems that are already in place to provide SSL for Web sites. At most we are talking some multiple of hundreds of thousands, probably much less. Some banks are already stepping up to the most expensive requirements - putting all their bank Web sites under SSL without exception and signing all their outgoing email with DKIM without exception.
>
>
>   
>> I don't believe we should declare all protection against 
>> client-side attacks "out of scope", nor should we not at 
>> least attempt to do what we can while the O/S people tinker 
>> about the edges of this problem.
>>     
>
> They are not totally out of scope, certainly I think we should discuss relevant client side attacks and we should be feeding requirements back to the O/S development teams. In particular we should be feeding requirements back to the O/S providers that have not been as aggressive in developing trustworthy computing as the entity based in Redmond WA. 
>
> But we do need to focus, and we do need to make sure that we don't end up in a position where we don't fix the shingles because the roof leaks and we don't fix the roof because the shingles leak.
>
> The only limit to the number of groups we can create is the supply of focused ideas that provide a return on the investment required. If the idea is not appropriate for W3C we can find another forum where it does fit in : IETF, OASIS, Anti-Phishing WG. This is not the only initiative I am involved with in this space. It is the one that is my highest priority though because I think it has the potential to provide the most direct and immediate return.
>
>
>   
>> No fix has arrived for two decades so far - so I think it's 
>> more than reasonable to assume that O/S vendors are not going 
>> to be delivering one anytime soon.
>>     
>
> People only woke up to the fact of professional Internet crime three years ago.
>
> The past twenty years were spent on the wrong type of Computer Security. The model was to create a castle and a vault within the castle to secure the crown jewels. What people were not thinking about was the problem of making the streets safe outside the castle.
>
>
>

Received on Thursday, 15 June 2006 23:10:31 UTC