W3C home > Mailing lists > Public > public-usable-authentication@w3.org > June 2006

RE: Secure Chrome (and secure browsing mode)

From: Dan Schutzer <dan.schutzer@fstc.org>
Date: Mon, 12 Jun 2006 08:23:37 -0400
To: "'Amir Herzberg'" <herzbea@macs.biu.ac.il>, "'George Staikos'" <staikos@kde.org>
Cc: <public-usable-authentication@w3.org>, "'Alex Dvorkin'" <kaledan@chaoslands.com>, "'Ahmad Jbara'" <ahmad@netanya.ac.il>, "'Dan Schutzer'" <dan.schutzer@fstc.org>
Message-ID: <E1FplSZ-0003Qn-8w@maggie.w3.org>

I agree with the observations made by George. When he says:

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 12:24:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:15 UTC