Research has shown that most people are unable to tell whether they are at an authentic website that is using SSL encryption (see The Emperor’s New Security Indicators). This is part of the reason people are so susceptible to phishing. Web browsers provide enough information to tell if SSL is on, but it is presented in a poor manner (as a small lock icon). Other bad security practices, like the website embedding its own lock icon and saying “secure login”, make matters even worse.

The problem is that people tend to notice glaring differences, but do not take explicit steps to check for security. They shouldn’t have to. Firefox 3 tries to improve SSL indicators for “Extended Verification” certificates by displaying the company name in green to the left of the URL along with the fav-icon. It looks like this:

Unfortunately, this indicator is still just text, plus an insecure/unsigned fav-icon. One must deliberately read it to verify the site’s identity, so it is likely to go unnoticed if the user is at a different site, just like like previous security indicators. If a hacker can compromise any site that has an EV certificate using cross-site scripting (a common problem on many sites), then he can create a believable phishing page. Sure, the company name will be different, but the fav-icon could presumably be spoofed and the address bar will still have the green indicator.

 Firefox 3 SSL indicators for EV certificates are a much better than previous indicators, but there is still room for improvement. The problem is that there isn’t a striking visual difference between the security indicators for different sites with EV certificates. Confusion is possible, especially if one can spoof the fav-icon. What I propose is that each site with an EV certificate also sign a logo for display in place of the hostname. The logo should also be a registered trademark, which, by law, must be clearly different from other trademarks. In fact, the test for trademark violation is “confusion,” so using registered trademarks for EV certificates guarantees (legally) that there will be no visual confusion. Here is an example of what, in my mind, SSL indicators should look like:

This way, any deviation from PayPal.com would immediately stand out to the user and serve as a much better indicator not only of SSL, but also the identity of the current site.

Recent discussions about research on bank website design flaws (see Analyzing Websites for User-Visible Security Design Flaws) have brought up a few important points about web security. The research conducted by Dr. Prakash, Laura Falk, and myself addresses problems that preclude secure usage of bank websites by expert users. It does not consider how to design websites in such a way that they are secure for non-expert users. In the recent study, we looked at bank websites that have login boxes on insecure pages. However, if a hacker has access to the network link, he or she could just direct customers to a page that doesn’t use SSL at all. How many people will notice the difference? This article looks at the severity of usability problems in secure web transactions, and what could be done in web browsers to fix them.

(more…)

The results of a recent study on security design flaws in banking websites will be presented tomorrow at the Symposium on Usability and Privacy. The research was conducted by Dr. Atul Prakash, Laura Falk, and myself (Kevin Borders). It found that flaws, such as presenting login information on an insecure page, were widespread. What does this mean for the security of the internet at large? Will hackers routinely exploit these vulnerabilities to conduct widespread fraud in the future? And, the most important question: how do we fix it?

(more…)

but the solutions would impede usability. Any security problem that we face today could probably be solved using primitives that have existed for a long time, such as encryption, authentication, digital signatures, physical isolation, firewalls, trusted computing, and mandatory access control. How can you prevent your computer from getting a virus? Do not connect it to the Internet. How do you stop spam? Only accept signed e-mail from known associates. These solutions obviously do not meet real-life usability requirements, but they highlight an interesting point. If you think that you are researching a security problem, then you are actually researching a usability problem. Any security solution that does not account for usability will not improve security one bit. Furthermore, truly revolutionary security products should have minimal or no effect on a user’s work-flow. It is very important to keep this principle in mind when designing new security systems.