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

Re: Secure Chrome

From: Amir Herzberg <herzbea@macs.biu.ac.il>
Date: Mon, 12 Jun 2006 16:36:17 +0300
Message-ID: <448D6DD1.3010701@cs.biu.ac.il>
To: Chris Drake <christopher@pobox.com>
CC: public-usable-authentication@w3.org, Alex Dvorkin <kaledan@chaoslands.com>

Chris Drake wrote:
> Hi Guys,
>
>   
>>> * There must be a clear visual distinction between 'control' and 'data'
>>>  * Data elements must not be allowed to overlay or otherwise simulate the
>>> control area
>>>       
>
>   
>>  Agreed.
>>     
>
> Sorry to broadside this debate again - everyone keeps forgetting
> this:  http://guardpuppy.com/BrowserChromeIsDead.gif
>
> You can put as much effort as you want into chrome, and 100% of it
> will be wasted when the spamming phishers etc just visually simulate
> the entire browser UI.
>   
But preventing this, i.e. properly framing every browser window, is 
definitely doable - although web designers may not like it.
> "Secure Chrome" is not a sensible or workable solution.
>
> What *IS* a secure and sensible solution is using shared secrets to
> authenticate resources to users - either before they "log in", or as
> part of the login process.  This is easily implemented within a
> browser with simple visual graphics, without using any chrome or
> requiring browser makers to change anything, and can easily be done to
> prevent both the visual attack that google demonstrated above, as well
> as man-in-the-middle/proxy attacks.
>   
For this to work, server must identify browser securely. Currently, this 
is usually done by browser sending cookie over secure connection to the 
server. But cookies are not reliable: users erase them, change 
browsers/computers/disks, etc..

Would it help to make a more `permanent` kind of (limited) cookie?
 
Amir Herzberg
Received on Monday, 12 June 2006 13:37:14 UTC

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