Comments on: Revisiting Security UI – Part 1 of 2 http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/ johnath in blog form Fri, 13 Aug 2010 17:23:32 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: liza http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/comment-page-1/#comment-147958 liza Thu, 20 Mar 2008 03:48:37 +0000 http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/#comment-147958 nice work man 10x nice work man 10x

]]> By: bob http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/comment-page-1/#comment-147942 bob Thu, 20 Mar 2008 02:59:26 +0000 http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/#comment-147942 nice work man 10x nice work man 10x

]]> By: arni http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/comment-page-1/#comment-147933 arni Thu, 20 Mar 2008 02:09:31 +0000 http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/#comment-147933 nice site dude nice site dude

]]> By: kate http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/comment-page-1/#comment-147919 kate Thu, 20 Mar 2008 01:20:54 +0000 http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/#comment-147919 sweet site thx sweet site thx

]]> By: Health http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/comment-page-1/#comment-82299 Health Mon, 08 Oct 2007 01:36:08 +0000 http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/#comment-82299 Browsers need to make this UI non-spoofable by phishers if it is to be of any real value. They can easily do so, (FF has hidden user preferences that enable that now) but so far have lacked the will to do so. Will that change now? Browsers need to make this UI non-spoofable by phishers if it is to be of any real value. They can easily do so, (FF has hidden user preferences that enable that now) but so far have lacked the will to do so. Will that change now?

]]> By: YamYam http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/comment-page-1/#comment-61441 YamYam Mon, 30 Jul 2007 21:12:06 +0000 http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/#comment-61441 Very nice Article. I took this site into my bookmark ;) greets yamyam Very nice Article. I took this site into my bookmark ;) greets yamyam

]]> By: GD http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/comment-page-1/#comment-43056 GD Fri, 11 May 2007 20:00:49 +0000 http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/#comment-43056 Interesting. Good to see your mind isn't going with age. Interesting. Good to see your mind isn’t going with age.

]]> By: Amir Herzberg http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/comment-page-1/#comment-37512 Amir Herzberg Wed, 11 Apr 2007 11:18:04 +0000 http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/#comment-37512 Interesting post, thanks. However... blacklist-based anti-phishing indicators, apparently jonhath's favorite (and of most/all browsers), is a dangerous deadend. Blacklists are not just `always behind the times`; they are simply too easy to circumvent, by use of dynamic IP address and domain name. So if they become a major defense, phishers will break them, and we'll have to fix the secure UI once more - and every time we do this, there is a higher price in user adoption and confidence. IMHO, the solution will ultimately have to break to: 1. Secure the login process (many good ideas available here!). This does not solve the entire problem!! We stil need to prevent spoofed sites from spreading malware and false information (content)! 2. Improved site-identification indicator. IEv7 improved a bit, by indicating organization name and CA in the location bar (unfortunatley, for EV-equipped sites only). Their display, unfortunately, is not very visible and not customizable - I believe that in TrustBar, a FF extension I did with students, we did better - more visible, customized, etc. Further improvements are needed (we are testing now), e.g. we may ask users to click on the site identifier to enter each (sensitive) site. 3. Improved protection against malware - in particular, may be a good idea, to require explicit user identification of each site from which browser receives content. 4. Allow users to delegate the `trust decision` (which CA identifications are acceptable) to a security/trust service provider (like anti-virus service). Interesting post, thanks. However… blacklist-based anti-phishing indicators, apparently jonhath’s favorite (and of most/all browsers), is a dangerous deadend. Blacklists are not just `always behind the times`; they are simply too easy to circumvent, by use of dynamic IP address and domain name. So if they become a major defense, phishers will break them, and we’ll have to fix the secure UI once more – and every time we do this, there is a higher price in user adoption and confidence.

IMHO, the solution will ultimately have to break to:
1. Secure the login process (many good ideas available here!). This does not solve the entire problem!! We stil need to prevent spoofed sites from spreading malware and false information (content)!
2. Improved site-identification indicator. IEv7 improved a bit, by indicating organization name and CA in the location bar (unfortunatley, for EV-equipped sites only). Their display, unfortunately, is not very visible and not customizable – I believe that in TrustBar, a FF extension I did with students, we did better – more visible, customized, etc. Further improvements are needed (we are testing now), e.g. we may ask users to click on the site identifier to enter each (sensitive) site.
3. Improved protection against malware – in particular, may be a good idea, to require explicit user identification of each site from which browser receives content.
4. Allow users to delegate the `trust decision` (which CA identifications are acceptable) to a security/trust service provider (like anti-virus service).

]]> By: Nelson B http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/comment-page-1/#comment-33840 Nelson B Thu, 22 Mar 2007 15:41:10 +0000 http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/#comment-33840 Browsers need to make this UI non-spoofable by phishers if it is to be of any real value. They can easily do so, (FF has hidden user preferences that enable that now) but so far have lacked the will to do so. Will that change now? Browsers need to make this UI non-spoofable by phishers if it is to be of any real value. They can easily do so, (FF has hidden user preferences that enable that now) but so far have lacked the will to do so. Will that change now?

]]> By: Iang http://blog.johnath.com/2007/03/13/revisiting-security-ui-part-1-of-2/comment-page-1/#comment-32663 Iang Wed, 14 Mar 2007 16:37:52 +0000 http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/#comment-32663 The statement that the browser makes is crucial to aligning the parties to work at this thing. At the moment, the browser sweeps it all under the table ... to the security tab ... so ordinary users have no conception of the fraud. EV makes the right statement: Site XYZ is identifed by CA Blue. It is crucial to identify who says the site is as is, otherwise it falls to the browser. The CA must be represented as the one who said so, not only because it is their cert, but because this correctly allocates the liability to them for getting it wrong. But EV mucked up and turned it into a marketing-driven campaign: those who pay more (somehow) get the valuable green bar. Which means "the few" ... who really aren't so much of an issue. Meanwhile, the rest, the $10 cert factories with low or no security thresholds, are *hidden* from user scrutiny. To be a security statement and not a marketing statement, it should have been the other way around: Low cost CAs will always be named and shamed with the statements they make. (High cost CAs might be able to buy a better class of shame...) The statement that the browser makes is crucial to aligning the parties to work at this thing. At the moment, the browser sweeps it all under the table … to the security tab … so ordinary users have no conception of the fraud.

EV makes the right statement: Site XYZ is identifed by CA Blue. It is crucial to identify who says the site is as is, otherwise it falls to the browser. The CA must be represented as the one who said so, not only because it is their cert, but because this correctly allocates the liability to them for getting it wrong.

But EV mucked up and turned it into a marketing-driven campaign: those who pay more (somehow) get the valuable green bar. Which means “the few” … who really aren’t so much of an issue. Meanwhile, the rest, the $10 cert factories with low or no security thresholds, are *hidden* from user scrutiny. To be a security statement and not a marketing statement, it should have been the other way around: Low cost CAs will always be named and shamed with the statements they make. (High cost CAs might be able to buy a better class of shame…)

]]>