Re: Secure Chrome (and secure browsing mode)

Dan Schutzer wrote:
> I agree with the observations made by George. When he says:
>   
Hi Dan... These specific comments were actually mine (although I agreed 
with most of George's comments as well...).

BTW, the `secure browsing mode` could also be appropriate for an FSTC 
experiment (or an experiment with a specific bank). On our own, we can 
implement, but it is hard for us to make an interesting experiment - so, 
we'll love to cooperate with FSTC or a specific Financial Institution 
(or webmail service) to do a really interesting experiment.

Best, Amir Herzberg
> 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.
>
> It also parallels physical world. I receive lots of mail, and I understand
> that much of what I receive is untrustworthy, but it still does not stop me
> from using the mail system. There are however certain types of
> correspondence that require special treatment - e.g. registered, certified,
> Fed Express, etc. If I get mail in this manner it can be treated
> differently.
>
> -----Original Message-----
> From: public-usable-authentication-request@w3.org
> [mailto:public-usable-authentication-request@w3.org] On Behalf Of Amir
> Herzberg
> Sent: Monday, June 12, 2006 2:28 AM
> To: George Staikos
> Cc: public-usable-authentication@w3.org; Alex Dvorkin; Ahmad Jbara
> Subject: 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 13:19:54 UTC