Using History, Collaboration, and Transparency to Provide Security

With some digressions on usability and security of web service authentication in general

Mary Ellen Zurko, Dave Wilson, IBM Software Group

Position Paper for Toward a More Secure Web

W3C Workshop on Transparency and Usability of Web Authentication

As the commercial, economic, and financial attractiveness of the data and interactions that occur on the Web rises, so does the activity by persons and organizations who would take advantage of it for their gain, licit and illicit. We see the same phenomena with spam in email. The web and email infrastructures are global and open to (practically) anyone, requiring only either modest means or physical access to some populous center of activity. In the past, physical limitations, closed communities, and heterogeneity of software provided bottlenecks on the kinds of attacks and scams possible. These constraints do not exist in the web. While non-functional attributes such as performance and usability have substantially increased with recent web programming approaches such as AJAX, there are no practical programming techniques or patterns proposed to increase security on the web.
Pure authentication of web sites will not solve the problem of scam web sites. By analogy with spam again, there is some evidence that the early adopters of new email authentication technologies such as Sender Policy Framework (SPF) are spammers. SSL provides web site server authentication and is supported by all widely deployed web clients. Being able to authenticate in classic web and security parlance means almost nothing to the vast majority of users when the identity that is authenticated is meaningless to their task at hand. Domain names are not useful identities. Even users who can parse a web site’s domain name and compare it to what they expect can experience uncertainty or “false positive” security concerns in a world where even legitimate businesses use multiple domain names, and out sourcing will continue to occur. The current emphasis on web services will only increase out sourcing of business activities to web sites in another domain. Authentication of a computer identity can be useful in more constrained worlds where the association between computer identity and warm body is known (such as in an enterprise). This association allows retribution and recovery after the fact, targeted at the identifiable scofflaw. Obviously this is much more problematic on the Web.
How do users know if a site is trustworthy? Today, they use a wide range of indicators, as borne out in studies by researchers such as Andrew Patrick. They look at the professionalism of the design, and many other attributes that have nothing to do with security mechanisms. This happens in potential spam too. Even savvy computer professionals will scan the body of a spam email checking for signs in the content if something else does not seem right (DNS domains, for example). On top of that, different web sites are likely to be trusted for different information. Company confidential information is fine for any web site my company runs and owns. Phishing attacks currently target information that can be used to impersonate the user in a wide array of circumstances (name and social security number or credit card) or more limited circumstances (name and password to a financial web site). Targeted changes can protect limited circumstances (specific banks requiring or supporting two factor authentication), but do not solve the broader problems.
It’s unlikely any of these problems will be solved without deployment of additional client side software, in the form of updates to browsers, add ons to browsers, or other changes.
While, sadly, nothing in this world is absolute, there are four types of information that can indicate with some real world assurance how trustworthy a site is:
1.    The user’s personal history with the site,
2.    What others say about or have done with the site
3.    What a knowledgeable and responsible part says about the site
4.    The time line for any of the information about the trustworthiness of the site
The most obvious and easiest to integrate information is the user’s personal history with the site. Have they been to the DNS domain before? Did they generally use a secured protocol for the current URL, or for the URL they are requesting or posting to? Did they send identical data there before? Did they send anything there before? Obviously browsers can do a better job of checking and representing this information. Some begin to. A more detailed and stronger model of what is trustworthy, or conversely what should be flagged as untrustworthy or even unknown, is useful and attainable. Following the same link in a phishing email twice, or two different links in that phishing email, should not make a site appear to be a peer of sites the user has gone to and interacted with successfully in the past.
Once we have an established model for how a user’s history can help, the history of others can help establish the trustworthiness of a site as well. The user’s relationship to those others, and the reliability of that information, becomes an issue. In a constrained environment, such as an enterprise, there’s a ready made population of reliable colleagues whose history can be tapped. These sources are reliable because of the real world relationship between them and the user (employed by the same business, potentially direct and known colleagues if scoped to the org chart). This is reflected in the authentication and naming mechanisms in place in the organization. In the consumer and individual’s case, ensuring reliability is more complex. Approaches with potential include “friends and family” (what history do people in your address book have with them?) and a “wisdom of the crowds” (what history does the general populace have, and how does that compare with their history with supposedly similar institutions?). Willingness to share, safety of and controls on who can see what’s shared (people in your own address book, for example), and reliability of the information from a computer systems point of view (is it really from the people you think it’s from?) are all issues to be addressed.
Already in the definition of others we see that some “others” are more fit for the purpose, more trustworthy with respect to an individual, than others. Specifically knowledgeable and responsible parties, authorities, can provide accountability and specific and targeted guidance. While those are innate in enterprises, the history of authorities for recommendations on the web is not good. Neither PICS nor P3P authorities seem to have emerged. SSL authentication authorities for web sites have, but that seems to be part of the problem. Any web site can get an SSL certificate. It’s not clear users check for SSL or balk at a self signed certificate. And authentication of the DNS name has not proven to be very useful, since there is not hard link between institutions and their DNS name(s). In general, users don’t configure their SSL authorities (they come with the browser or are augmented when they say “OK” to annoying dialogs) or their P3P preferences (they too come with the browser).
Once a relationship is established, an institution could in theory act as an authority on its DNS names itself. This pushes a multitude of security and usability issues into one place, and also brings up the issue of spoofing at the UI level. The ability for scripting to overlay trustworthiness indicators is one of the many current problems. The traditional solution is to allocate secure processing areas that cannot be overwritten by untrusted processing (scripting). An alternative might be to use the natural processes of user customization and personalization. No one’s computer desktop looks the same, if they run in an environment that is highly personalizable and responsive to application customizations. A security indicator that was naturally easy to move around to an appropriate place and that provided feedback based on the user’s history would be difficult to over write accurately by scripts (assuming a scripting language with a security model that made sure the scripts could not query the placement and contents). Supporting scripting language with no security model makes the problem intractable, or forces it into the lower supporting layers.
To some extent, the time line of the history information is also potentially useful, in particular for damping down “flash crowds” from phishing scams. The longer a scam needs to go on, the more difficult it is to pull it off. This couples well with the transparency of sharing information about interacting with sites. The more visible the activity is, the more difficult it is to continue it if it’s a scam. The transparency provided by collaboration and sharing can counter balance the lack of authority and constraints that make these problems seem much harder to solve in the web. Privacy concerns are the obvious reason that it will be hard to make information available to others. Privacy preserving techniques (anonymizing) can help, but recent US government calls for records from search companies will make trust in any central point more difficult to come by. Authentication authorities such as OpenID may provide a third party who can report activity data.
While the recommendations detailed above require additional client side software they also require a corresponding change in client side behavior to pay attention to or take advantage of these new capabilities.  Another -- more active -- change in client behavior is to incorporate personalized experiences into the web server server authentication mechanisms.  Passmark ( provides an authentication platform where the user personalizes their authentication experience with text phrases, challenge questions, and images.  When the user authenticates to a Passmark enabled system, they first enter just their user name, are brought to an area that they've personalized (via text phrases and image selection), and then enter their password from this interface that they've had a hand in creating.   Phishers cast with a large net, hoping to obtain data by presenting a standard interface to all users; adding personalization to the interface disrupts this model.

A lot of “bread and butter” work needs to go with whatever direction is adopted. Claims of usability need to be tested, using the recognized practices in the CHI community for doing user testing to validate usability claims (lab tests, field tests). See the “Usability Design and Evaluation for Privacy and Security Solutions” in Security and Usability: Designing Secure Systems That People Can Use. (In general this book is an excellent resource on the current state of the art and industry on the topic of security and usability.) Claims of secure usability need to be tested as well. That field is less mature than either pure usability or pure security testing alone. Security testing can also occur in the lab (red teaming) or in the field (ethical hacking). The challenge for usable security testing in the lab is to not create a situation where the user has heightened sensitivity to potential attacks, particularly since those come with far less regularity in the wild. The challenge for usable security testing in the field is setting up a situation that is safe and ethical for the user, again with the need for them to not know about attacks a priori.
The call for the workshop also mentions web client safety. The biggest challenge to safe Web client behavior is active content (such as Java, Javascript, and other scripting languages). Web clients should never support any code that comes from the web without a security model. Preferably a security model that involves digital signatures. There’s copious research and deployment experience on security models for active content, including our work in the context of Notes/Domino. It remains the hardest area of security to also make usable, since it’s innately about code, which is something most users should not need to understand.
While usable security as a field has been around three decades, there are still many challenges. Substantial work has gone into making user authentication more usable, though most is still in the research phase. Both expert reviews and testing techniques from both disciplines are being successfully applied to specific technologies. Principles are beginning to emerge. In the context of web site authentication, we think integrated and transparent security through history and collaboration state hold the best promise.