Re: Secure Chrome (and secure browsing mode)

George Staikos wrote:
> On Friday 09 June 2006 17:12, Hallam-Baker, Phillip wrote:
>   
>> Without the ability to do a frameless popup the example shown simply
>> becomes a web browser with two sets of menu and status bars. The user will
>> probably find this confusing but it is unlikely that they will be tricked.
>>     
>
>   This I'm not so sure about in terms of "unlikely that they will be tricked", 
> but I do agree that once we axe the frameless popup, we will be in much 
> better shape.
>   
I wish I could agree that this will make tricking `unlikely` - this was 
indeed our assumption with TrustBar. However in our experiments we found 
that displaying site identification - even personalized - helps, but 
there is still a significant fraction of failures to detect the 
spoofing. BTW, I've presented this `attack` also in the workshop - with 
the two menus.

The results do indicate a significant improvement in detection rates 
with improved (esp. personalized) security indicators - assuming these 
are protected in the chrome of course. However, these results motivate 
search for complementary measures, which will defend the user _without_ 
depending on the user to notice the security indicators. Which, I 
believe, is also what George is saying.

The current focus by MS & Google/FF on `blacklisting` (following 
NetCraft etc.), may be interpreted as a step towards automated defense; 
i.e.,  in some of these solutions, the browser actually blocks the 
suspect sites rather than expect users to notice. This is good, but 
unfortunately, I am skeptical about the long-term value of blacklisting 
against web spoofing/phishing. Spoofers can and will avoid blacklists; 
it is only matter of time and market share (of blacklists) till spoofers 
do this, resulting in another loss in credibility of secure e-commerce 
solutions. And we'll need real solutions at this point anyway.

Which motivates the following two solutions (any others?):

1. Avoid entry of sensitive data (passwords, credit card #, SSN, etc.) 
into forms. Main technique is probably by a `wallet/password manager` 
solution which (securely) stores the sensitive data and sends it only 
via SSL to appropriate sites. We are integrating such solution with 
TrustBar.

2.  `Secure browsing mode`, in which browser is limited to trusted 
content - certified by trusted authorities. Every figure, script and 
executable - signed. It may sound crazy to people familiar with the 
current contents of web sites, but is it really infeasible? We could 
begin with a solution for banks and brokers, which are probably the most 
critical targets. Initially, the solution may require user to use a 
special (secure) browser for these sites - this will be a simple 
recommendation that the banks & brokers can give to their customers. 
There are some technicalities to solve here such as the separation 
between script code and variables, which is one place where a W3C 
standard may help.
>   
>> There are two parts to this group as I see it:
>>
>> 1) Work out how to make chrome secure
>> 	* Limitations on Javascript to prevent stomping
>> 	* Limitations on controls
>> 	* Ways of varying or customizing the interface
>> 	* etc.
>>
>> 2) Work out what information the user needs to see in the secure chrome
>> 	* Site info
>> 	* SSL conection status info / gogreen(TM) / letterhead
>> 	* ???
>>     
>
>   I think it's still spoofable, but perhaps addressable.  I've seen some 
> tactics in a few places where some sort of information well-known only to the 
> user was placed in the chrome.  While it did require the user to actively 
> look at the chrome to make sure the information was valid, the information 
> was not spoofable since it was impossible for a site to know what that 
> information was (barring any security hole in the browser implementation).  
>   
Yes, and we have experiments which seem to validate the intuition that 
such customized information makes it easier for users to detect spoofing. 
> Imagine a browser that had, in the tool/menu bar, "This is Phillip's 
> browser." and a mini-picture of Phill's car.  It uses real-estate, and maybe 
> that's not the best implementation, but it's an example of placement of 
> information in a secured area that indicates the probable authenticity of the 
> window.  I think that makes it much harder to spoof.
>   
I think it _is_ a bit absurd, to allow frameless popup and then ask 
users to to detect an identification of the `real` browser... The 
principle should be `defend don't ask` - in particular you should impose 
the control frame for all browser windows rather than ask users to 
detect the `real` frame by the picture of his car... Although I do agree 
it will have _some_ value.

But a customized picture is a good way to identify a trusted site e.g. 
your bank!!

Cheers, Amir

Received on Monday, 12 June 2006 11:53:14 UTC