Shared Knowledge to Authenticate the Site to the User
Web applications may embed information into their application and pages that is meant to authenticate the web application to the user, or to achieve the weakr goal of giving the user confidence in the trustworthiness of the site. As ContextPresentation laysout, there are a number of ways that a site can attempt to use shared knowledge to prove its identity to the end user. This knowledge may be a shared secret (such as a user selected image or passphrase), publicly available knowledge about the user (such as mother's maiden name, user's full name), or site context specific user information (personalization knowledge, account history, time of last login). Context specific information that is part of the user's transactions with the site (login time, account information) is particularly attractive since it requires no additional input from the user to provide it, and little or no additional storage and management on the part of the site to maintain it. It can be a very natural way for the site to engender trust in the user, since it leaves the user with the impression that the site is familiar with the user. [ref Patrick, Briggs, Marsh].
There are several ways this form of site authentication can not work, or be undermined.
Users need to be authenticated to the site in order to see the information (since it is specific to the person, and meant not be trivailly available to would-be attackers). If the user authentication credential can be used to impersonate the user (such as a password), significant information is already exposed to the attacker before this check can be made by the user.
The exposure of the user's credentials is less severe when context specific or personalization knownledge is displayed to the user in a form of a multiple choice question. Answering that question also provides the site with a weak form of pre- or re- authentication of the user. For example, if the user has registered the type of car they drive, they may be asked the question "What model car do you drive? (a) 1977 Ford Pinto, (b) 2004 Ford Mustang, (c) 2007 Toyota Prius, (d) 1981 AMC Pacer".
Users could not notice its absence. A number of references indicate that not all users notice the absence of passive, positive security indicators [Phishing Works, Gathering Evidence], and few will change their behavior based on their absence [Emperor]. Other parts of the recommendation address security context information targetted at user input of sensitive data.
Users can be convinced that the absence is not a problem. An attacker's site may state that there is a problem with the subsystem that usually provides the shared knowledge, or that it is down for regular maintanence. The attack might link their requests for private information to the claimed problem ("your account information needs to be restored").
Attackers can produce the information. The less secret and private the shared knowledge is, the more opportunities there are for an attacker to guess, steal, or approximate the information. The easiest form of knowledge to attack is Shared Public Knowledge (e.g. full name, mother's maiden name, zip code). Man in the middle attacks can also allow the attacker to produce the information by relaying it from the site to the user, after relaying the user's authentication to the site. There seems to be no way today to prevent these attacks with currently deployed web technology.
Site's cannot provide strong site authentication through web content. The WG's recommendations for the strongest site authentication involve the web user agent's chrome (protected areas).
It is inevitable that site's will continue to identify themselves to the user through their web content. From branding, to look and feel, to personalization. These aspects are important in terms of marketing, usability, and consumability of web sites and applications. They also naturally engender trust in users.
[The recommendations after this point are not yet internally consistent. They're meant as a basis for group discussion.]
Web sites should not attempt to authenticate themselves by their web content to the user with technology that is vulnerable to MitM attacks, or with information that is publically available or easily guessed. In other words, with today's deployed technology. Branding and personalization are sufficient for no/low risk situations. Other recommendations will cover how a site deploys so that the user agent can authenticate them to the user in medium/high risk situations. Consistancy in this aspect across conformant sites will reinforce best practice with the end user.
Web sites should actively avoid using in their content information that is similiar to or identical to user agent security context information displays, in current user agents, or recommended by this wg. While providing a security context indicator that can be replicated in content is a weak form of display, open to attack, displaying similiar information in web content muddies the difference between a conformant site and a malicious site, and trains users to expect trust signals that can easily be false. The cannonical example of an icon to be avoided because it is currently used to represent certain forms of secured connections is the padlock.
Best practice for web applications - if personalization and/or security context information normally presented to the user (either directly through web content or indirectly via the user agent) is not available in the form users understand and expect, do not provide any information or functions that are user specific. Users should expect only publicly available information that is not personalized when the web site is unable to conform to the recommendations of this wg, and to its normal practices. (Just what information web sites should provide via security context information to the user agent will be a topic of other parts of this recommendation.)