Section 13.3. Design Strategies


13.3. Design Strategies

Two strategiessecurity by designation and user-assigned identifierscan be used to implement some of the aforementioned guidelines in a broad range of situations. After describing them, I'll propose ways to solve some everyday security problems using these strategies.

13.3.1. Security by Admonition and Security by Designation

Users often want to make use of things they do not completely trust. For example, it's reasonable for people to want to run programs or visit web pages without having to understand and audit their source code. Instead of trusting the unknown entity, users trust an agent (such as a secure operating system or a secure web browser) to protect their interests by placing constraints on the unknown entity. The agent's challenge is to determine the correct constraints.

Consider two contrasting styles of establishing these security constraints that I'll call security by admonition and security by designation. Security by admonition consists of providing notifications to which the user attends in order to maintain security. With security by designation, the user simultaneously designates an action and conveys the authority to perform the action.

The case of an operating system constraining a potentially dangerous program provides an example to illustrate these concepts. I'll use Venn diagrams to depict the space of the program's possible actions. In each run of the program, its actions form a path through this space, represented by a sequence of black dots. Arrows represent user actions that trigger these program actions. The rectangle delimits the actions that the system allows; it is a simple shape to signify the rigidity of a typical policy specification. The shaded region is the set of actions acceptable to the user; its shape is irregular to signify that the user's desires are probably complex and imprecisely specified. Figure 13-5 displays these notational conventions.

Figure 13-5. This Venn diagram of the space of program actions shows the notational conventions to be used in the next two figures


13.3.1.1 Security by admonition

Figure 13-6 shows a system that enforces a static, preestablished security policy. Because the policy is only finitely detailed, it can only roughly approximate the user's desires. Because the policy is static, it must accommodate a wide range of situations other than this particular run of the program. Thus, the solid box in Figure 13-6 includes large areas outside the shaded region. On Mac OS, Unix, and Microsoft Windows systems, programs usually run with the user's full authority, creating a vast discrepancy between the sets of allowed and acceptable actions. For example, even though I may start a program intending to edit only one file, the system allows it to modify or delete any of my files, send email in my name, upload my files to the Internet, and so on.

Figure 13-6. With security by admonition, the system has to guess when to warn the user of potential dangers


To prevent the program from taking undesirable actions, the admonition approach would be to show a warning so that the user has an opportunity to intervene before the undesirable action happens. Commercial products like ZoneAlarm (see Chapter 27) do just this, stepping in with a prompt when programs access the network. Unfortunately, the computer can't read the user's mind, so it has to guess when to warn and when to proceed. Warning too little places the user at risk; warning too much annoys the user. The larger the discrepancy between acceptable and allowed actions, the more severely we are forced to compromise between security and usability.

13.3.1.2 Security by designation

Figure 13-7 acknowledges that user expectations change over time and that the security policy should change to match. In this approach, the program starts out with minimal authority (solid box). As before, the user can interact with the program's user interface (solid arrow) to have the program carry out actions using its initial authority. When the user wants to take an action requiring new authority, the user interacts with the system's user interface (dotted arrows) to express both the command and the extension of authority (dotted box) at the same time. Combining the authorization with the designation of intent in a single user action maintains a close, dynamic match between the allowed set and the acceptable set of actions. Users don't have to establish a detailed security policy beforehand and don't have to express their intentions twice.

Figure 13-7. With security by designation, the user simultaneously designates an action and conveys the authority to take that action


13.3.1.3 Advantages of designation

Software commonly employs a mix of these two approaches. Launching a program is a case of security by designation: users don't have to select a program and then separately grant memory to the newly created process; a single action accomplishes both. Sending an email attachment is another example of designation: users don't have to select a file to attach and then separately assign read permissions to the recipient of the message; dropping the attachment into the message designates the attachment, the recipient, and the intended authorization in a single act. When a web browser asks for confirmation before submitting a form, or when Microsoft Word asks whether to enable macros upon opening a document, these are cases of security by admonition.

When security by designation is possible, it is convenient and straightforward because it achieves the ideal of integrating security decisions with the user's primary task. On the other hand, security by admonition demands the user's attention to a secondary source of information. With designation, the authorization is part of a user-initiated action, so the user has the necessary context to know the reason for the authorization. With admonition, the request for authority is initiated outside the user, so the user may not have the context needed to decide whether to approve it.

13.3.1.4 Implementing security by designation

To implement the designation strategy, we have to find an act of designation with which to associate the authorization. When we are tempted to ask the user whether a particular action is acceptable, we instead determine how the user originally specified that action. The action may have been conveyed through several software components, so we must follow it back to the originating user interaction. Then we move that user interaction into a software layer that the user trusts to handle the relevant authority and convey the authority together with the designation of the action. The example in the later "Securing file access" section will demonstrate how this is done.

13.3.1.5 Implementing security by admonition

It may be necessary to fall back on admonition when security by designation isn't feasiblefor example, if the original designating interaction is inaccessible or untrustworthy. It is usually better to inform users without interrupting their workflow. Forcing users to answer a prompt is a terrible way to present a notification: it teaches users that security issues obstruct their work and trains them to dismiss prompts carelessly instead of making meaningful decisions.

Seek designs that are noticeable by their proximity and relevance to the matter at hand, not by their aggressiveness. For example, the Firefox web browser notifies the user when an unknown site tries to install software by adding a transient bar to the browser window; the bar does not prevent the user from viewing the page as a prompt box would. Notifications concerning a particular operation can be displayed just for the duration of the operation. Later in this chapter, Figure 13-15 shows a note about passwords appearing next to a password field while the field is active; the note disappears when the user moves to another field. Displaying tips near the mouse cursor or changing the mouse cursor are also ways to provide clear yet noninterrupting feedback.

13.3.2. User-Assigned Identifiers

Practically every user interaction depends on the correct designation of an object or action. The names by which a user refers to objects and actions come from many different sources: some are assigned by the user, some are assigned by other users, some are allocated by global or local organizations, and some are assigned by programs.

Giving objects the power to choose their own names places the user at a significant disadvantage. Unless another naming mechanism is provided, the user is forced to work with identifiers controlled by outside partiespotentially, to communicate with his or her most trusted software agents using terms defined by an adversary. Each name that enters the user's sphere is a potential avenue of attack if it can be made misleading or confusing.

A good way to avoid the danger of identification problems is to let users assign and use their own local identifiers for objects and actions. Computers are harder to confuse than humans; they can take care of the translation between users' familiar names and the names used by machines or other people.

You already use user-assigned identifiers all the time. For example, each file on your desktop has a name that you can assign. The true, unique identifier for each file is a number that tells the system how to locate the file on the disk. But you never have to deal with that number; you assign a filename, and the operating system takes care of translating between the name and the number. Imagine how difficult it would be to identify files if the desktop displayed only disk addresses instead of filenames, or how inconvenient it would be if files all chose names for themselves that you couldn't change.

Another means of user-controlled identification is the assignment of positions to icons. Preserving the positions of the icons on the desktop helps you find them later. Some systems also let you assign colors to icons. These mechanisms give you more control over how you identify objects, improving your ability to designate them accurately.

13.3.3. Applying the Strategies to Everyday Security Problems

Let's look at a few examples to see how security by designation and user-assigned identifiers help us address security problems in practice.

13.3.3.1 Email viruses

Self-propagating email attachments have caused widespread havoc in the last few years. Some exploit software bugs in the operating system or mail program, but bugs are not the whole story. Many email viruses , such as MyDoom, Netsky, and Sobig, rely on humans to activate them by opening executable attachments, and would continue to spread even with bug-free software.

On Microsoft Windows and Mac OS systems, double-clicking serves two very different purposes: opening documents and launching applications. Whereas documents are usually inert, starting an application grants it complete access to the user's account. Thus, a user can double-click an attachment, intending only to read it, and instead hand over control of the computer to an email virus.

The missing specification of intent here is the choice between viewing and executing. The user is not given a way to make this choice, so the computer guesses, with potentially dangerous consequences. A bad solution would be to patch over this guess with a prompt asking the user "Do you really want to run this application?" every time an application icon is double-clicked. To find a better solution, we need to consider how users specify the intent to run a new application.

What do users already do when they install applications? On a Mac, most applications are installed by dropping a single icon into the Applications folder. So, suppose that double-clicking files in the Applications folder launches them, and double-clicking files elsewhere only passively views them. Suppose also that the Applications folder can only contain files that the user has placed there. The resulting system would respect a distinction between viewing and executing established by the convention users already know. Programs would run only if installed by the user. The main propagation method of email attachment viruses would be eliminated with virtually no loss of usability, because Mac users normally run their applications from the Applications folder. As for Windows, dropping a single icon is simpler to do and understand than running a multistep application installer, so switching to a drag-and-drop style of installation would simultaneously improve both security and usability for Windows users.

13.3.3.2 Other viruses and spyware

Although distinguishing viewing from execution would be better than what we have now, it provides a defense only when opening email attachments. Any program the user installs voluntarily, including downloaded programs that might contain viruses or spyware, would still run with the user's full access rights, exposing the user to tremendous risk.

The lack of fine-grained access controls on application programs is an architectural failure of Windows, Mac OS, and Unix systems. Such fine-grained control would enable a true solution to the virus and spyware problems. Let's consider how to control two major kinds of access exploited by viruses: file access and email access.

13.3.3.3 Securing file access

How do users specify the intent to read or write a particular file? In current graphical user interfaces, files are mainly designated in two ways: by pointing at file icons and by selecting filenames in dialog boxes. With Mac OS and Windows, both of these functions are implemented in the operating system. However, selecting a file passes the file's name to an application, not the file itself. The application then asks the operating system to open the file by name, receiving an object called a filehandle that represents the file. Applications on Windows, Mac OS, and Unix systems assume the user's identity when accessing the disk, so they can ask the system to open any of the user's files.

Here's an analogy to illustrate the concept of filehandles. Suppose that I have a telephone and I'd like to call my mother to wish her a happy birthday, but unfortunately I am a terrible singer. On the other hand, you have no telephone, but you have a wonderful voice and kindly offer to sing "Happy Birthday." I have two options: I could let you use my telephone, give you my mother's phone number, and ask you to call her (Figure 13-8a). But that would let you dial any number and call anyone with my phone, just as an application can "dial up" any file by its name. Instead, I could call my mother on the phone and then hand you only the receiver (Figure 13-8b). That way, I'd be sure that you were speaking only to her, and I wouldn't have to reveal her phone number to you. I could even disconnect you if necessary. Handing you a telephone receiver that's connected to another party is like giving a filehandle to an application.

Figure 13-8. (a, left) Handing over the entire telephone conveys the authority to dial any number; (b, right) handing over only the receiver is more consistent with the principle of least authority


To perform security by designation, we would stop providing applications with all the user's authority to access the disk; applications would start with access only to their own program files and a limited scratch space. Instead of returning a filename, the file dialog would open the selected file and return a filehandle to it (Figure 13-9). Similarly, dropping a file on an application would send the application a filehandle rather than a filename. The user experience of opening files would be exactly the same, yet security would be improved significantly because programs would get access only to user-selected files. Viruses and spyware wouldn't be able to install themselves or modify files without the user's specific consent.

Some special programs, such as search tools and disk repair utilities, do require access to the entire disk. For these programs, the user could convey access to the entire disk by installing them in a "Disk Tools" subfolder of the Applications folder. This would require a bit more effort than dropping everything in the Applications folder, but it isn't an alien concept: on Windows systems, for example, disk utilities are already kept in an "Administrative Tools" subfolder of the Start Menu.

13.3.3.4 Securing email access

How do users specify the intent to send email to a particular person? They usually choose recipients by selecting names from an address book or by typing in email addresses. To control access to email capabilities, we might add a mailhandle abstraction to the operating system, which represents the ability to send mail to a particular address just as a filehandle

Figure 13-9. (a, top) In today's Mac OS and Microsoft Windows systems, file dialogs return a filename; applications use their unlimited user file access (bold arrow) to open the selected file; (b, bottom) returning a filehandle is simpler and more secure while requiring no visible changes to the user interface; applications' access to user files is restricted to only files that the user designates, thereby protecting the user from malicious programs such as viruses and spyware


represents the ability to read or write a particular file. Then, selecting names from a standard system-wide address book would return mailhandles to the application, just as a secure file selection dialog would return filehandles. Using mailhandles would allow us to stop providing general network access to all programs, rendering viruses unable to email themselves to new victims.

13.3.3.5 Cookie management

Cookies are small data records that web sites ask browsers to retain and present in order to identify users when they return to the same site. They enable web sites to perform automatic login and personalization. However, they also raise privacy concerns about the tracking of user behavior and raise security risks by providing an avenue for circumventing logins. Users need some control over when and where cookies are sent.

Many browsers address this issue by prompting users to accept or reject each received cookie. But cookies are so ubiquitous that this causes users to be constantly pestered with irritating prompt boxes. To reduce workload, some browsers provide an option to accept or reject all cookies from the current site, as in Figure 13-10. After one has chosen a site-wide policy, it can be tricky to find and reverse the decision. Yet the decision to accept cookies is immaterial, as the real security risks lie in sending cookies. Moreover, the term "cookie" refers to an implementation mechanism and has no relevance to user tasks; if cookies appear at all in the interface, their appearance should relate to the function they serve.

Figure 13-10. Internet Explorer 6.0 prompts the user to accept a cookie


The missing specification of intent here is whether the user, upon returning to a web site, wants to continue with the same settings and context from the last session. To find a better solution, consider how users specify that they want to return to web sites they've seen before.

The existing user interface mechanism for this purpose is the bookmark list: users designate the site they want by selecting a bookmark. Therefore, suppose that each bookmark has its own associated "cookie jar." One jar at a time would be the active cookie jar, from which cookies are sent and where received cookies are stored. When the user creates a bookmark, the cookies for the current session are placed in the new bookmark's cookie jar,[9] and it becomes the active cookie jar. When the user selects a bookmark, its cookie jar becomes active. This is a change from today's typical browsers, but the usage is easily explained: "Bookmark a site if you want to continue later where you left off."

[9] Some cookies are temporary, marked to expire automatically at the end of a session. Others are persistent, marked to be saved for future sessions. In the design proposed here, only persistent cookies issued by the bookmarked site would be stored in the cookie jar with a bookmark. Cookies issued by third parties would be ignored.

Bookmarks containing cookies would be displayed with a mark to show that they are personalized. In the example in Figure 13-11, personalized bookmarks are marked with a small heart symbol. A bookmark icon in the location bar would indicate whether there are bookmarks for the current site, and it would also be marked to show whether the current view is personalized. Clicking on the icon would show a menu of bookmarks for the site as in Figure 13-12, enabling users to switch to a personalized session if they want.

Figure 13-11. In the proposed design, bookmarks that the user has created for personalized sessions are marked with a small heart in the bookmark list; selecting such a bookmark restores the session


Figure 13-12. (a, left) A bookmark icon next to the URL indicates that the user has bookmarks for the current site; the user can select a bookmark to switch to a personalized session; (b, right) an advanced user has created and named bookmarks for two different logins; the bookmark icon next to the URL is marked with a small heart to show that the current session is personalized, and the drop-down menu allows the user to switch to a different personalized session


This solution would eliminate the need for prompts or lists of cookie-enabled and cookie-disabled sites to manage. In fact, there would be no need to mention "cookies" in the user interface at all; one would simply describe some sessions as personalized. Login cookies would no longer be left lingering on public-access machines. Users' privacy would be better protected. Sites would no longer mysteriously change their appearance depending on hidden state. And users would gain additional functionality: advanced users could manage multiple logins or multiple suspended transactions simply by creating bookmarks. Security and usability would both be simultaneously improved.

Notice that security by designation has helped us to arrive at a design that follows several of the guidelines identified earlier: by requiring a user action to save cookies instead of a user action to reject cookies, we match the safer option with the path of least effort. By activating cookies based on the selection of a bookmark, we associate the sending of cookies with an authorizing act. By identifying which session is active, we help the user maintain awareness of the authority the user wields. And instead of having to express policy decisions in the unfamiliar language of cookies, the user expresses these decisions by creating and using bookmarks, which serve a useful and familiar task.

13.3.3.6 Phishing attacks

Forged email messages and web sites designed to steal passwords are a common method of stealing private information. SMTP, the dominant Internet mail protocol, places no restrictions on the "From:" field of an email message, so messages can be easily forged to appear to come from anyone. In a typical so-called phishing attack, a user receives an email message that appears to be from a bank, asking the user to click on a link and verify account information. The link appears to point to the bank's web site, but actually takes the user to an identity thief's web site, made to look just like the bank's official site. If an unsuspecting user enters personal information there, the identity thief captures it.

Here, the missing specification of intent is the intended recipient of the form submission. In one scam, for example, an imitation of PayPal was hosted at paypai.com. This problem is tricky because the system has no way of knowing whether the user intended to go to paypal.com and was misdirected to paypai.com, or whether the user really wanted to go to paypai.com. The intention resides only in the user's mind.

The designation at the heart of this security problem is the link address. Yet the specification of that address does not come from the user; the user merely clicks in the email message. Our problem would be solved if we could secure the email channel and determine the source of the message. But until we can convince most users to switch to secure email, there is no trustworthy designation on which to hang a security decision.

In this case, practical constraints make security by designation infeasible. The user is required to identify a web site by observation rather than by designation. The site has total control over its appearance; even the URL is mostly chosen by the site itself.

To protect the user, we have to provide some helpful information. Traditional admonition-style thinking would suggest warning the user when submitting forms to a suspicious-looking site. Such a prompt might look something like Figure 13-13.

Figure 13-13. Prompting is a traditional method of phishing protection


Indeed, this is exactly the approach taken by many antiphishing tools . Perhaps the most sophisticated is a commercial program called Web Caller-ID, which employs "hundreds of routines that examine the elements of a web site" to decide whether a site is fraudulent.[10] This type of solution is unreliable because it makes guesses based on assumptions about good and bad sites. The creators of Web Caller-ID claim that their routines can detect 98% of spoof sitesan impressive figure. But because there are more than 1,400 different phishing attacks per month (and this number is rising),[11] and each one could target thousands of users, the missed 2% can still do considerable damage. Moreover, any scheme based on heuristics generates spurious warnings. A false-positive rate of even 1% could be enough to train users to ignore warning messages.

[10] WholeSecurity, "Web Caller-ID Core Technology"; http://wholesecurity.com/products/wcid_core_technology.html.

[11] Anti-Phishing Working Group, "Phishing Attack Trends Report, June 2004"; http://antiphishing.org/APWG_Phishing_Attack_Report-Jun2004.pdf.

A better solution is to give the user control over the name used to identify the site. The petname toolbar[12] provides a text field, as shown in Figure 13-14, where the user can enter a petname for the current site (a nickname for the site specific to just this user). The user would assign a name to a site when registering for an account at the site.

[12] Waterken Inc., "Petname Toolbar"; http://www.waterken.com/user/PetnameTool/.

Figure 13-14. The petname toolbar, shown in untrusted (top) and trusted (bottom) states, supports user-assigned site names


The user-assigned name appears in the text field whenever the user returns to the same site. If the user hasn't assigned a name, the field shows that the site is unknown. As long as the user is aware of the petname, it doesn't matter what domain name a scammer uses. The act of assigning the name is initiated by the user, at the time the user chooses to enter a trust relationship with the site, in a context that the user understands.

This way of browsing would be completely safe against misidentification, without any heuristics or false positives, as long as the user notices the petname in the toolbar. Checking the toolbar is a change from current practice, so an admonition that brings the petname closer to the user's natural workflow might be needed to help users migrate. Figure 13-15 shows a message that might appear as the user enters a password on a site he or she hasn't named. The admonition is a temporary message, not a prompt window, so it informs the user without interrupting. Interrupting the user with a prompt would defeat our purpose: it would encourage users to assign petnames to sites in response to the prompt, instead of assigning names on their own initiative.

Figure 13-15. An admonition appears while the user is entering a password into a scam site


This petname scheme contrasts with today's centralized public key infrastructure (PKI) of digital certificates issued by certification authorities. PKI was intended to prevent just the type of misidentification that is exploited in phishing attacks, yet phishing is rampant. Some might say the problem is that users don't check certificates. But users rightly feel no compulsion to rely on a naming system with which they have no involvement and no trust relationship. (I'll bet you don't know who issued the certificate for the last secure web site you visited.) Carl Ellison has identified many problems with centralized PKI.[13], [14] Chapter 16 describes how key management can be made vastly simpler and more useful by using local namespaces instead of centralized authorities. Enabling users to assign personally meaningful names frees users from external sources of confusion, political battles, or dependence on unfamiliar third parties. See the Pet Name Markup Language[15] for further elaboration of the petname concept.

[13] Carl Ellison and Bruce Schneier, "Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure," Computer Security Journal 16 (Winter 2000); http://www.schneier.com/paper-pki.pdf.

[14] Carl Ellison, "Improvements on Conventional PKI Wisdom," Proceedings of the 1st Annual PKI Research Workshop (NIST, 2002); http://www.cs.dartmouth.edu/~pki02/Ellison/.

[15] Mark Miller, "Lambda for Humans: The Pet Name Markup Language"; http://erights.org/elib/capability/pnml.html.

13.3.3.7 Real implementations

CapDesk[16] and Polaris[17] are two research projects that apply the design ideas and strategies described in this chapter:

[16] David Wagner and Dean Tribble, "A Security Analysis of the Combex DarpaBrowser Architecture"; http://combex.com/papers/darpa-review/index.html.

[17] Marc Stiegler, Alan Karp, Ka-Ping Yee, and Mark S. Miller, "Polaris: Virus Safe Computing for Windows," HP Labs Technical Report HPL-2004-221; http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html.

  • CapDesk. A desktop shell that lets users safely run downloaded software in a familiar graphical environment. The CapDesk system and applications are written in the secure programming language, E.[18]

    [18] Mark Miller, "E: Open Source Distributed Capabilities"; http://erights.org/.

  • Polaris. A safe environment for running existing Microsoft Windows applications. With Polaris, one can use programs normally, enable macros, and open email attachments without experiencing ill effects from viruses or spyware.

Both of these projects are based on the object-capability paradigm,[19] in which combining designation with authority is a central design principle. The object-capability model has a long history of development in computer systems research, particularly secure operating systems[20], [21] and secure programming languages.[22] It is no coincidence that object-capability design yields benefits at the user level as well as the system level: the object-capability model has its roots in object-oriented programming, which was a breakthrough at both levels.

[19] Miller and Shapiro.

[20] Norman Hardy, "The KeyKOS Architecture," Operating Systems Review 19 (October 1985), 825; http://www.cis.upenn.edu/~KeyKOS/OSRpaper.html.

[21] Jonathan Shapiro, "EROS: A Fast Capability System," Proceedings of the 17th ACM Symposium on Operating Systems Principles (New York: ACM Press, 1999); http://www.eros-os.org/papers/sosp99-eros-preprint.ps.

[22] Miller, "E: Open Source Distributed Capabilities."



Security and Usability. Designing Secure Systems that People Can Use
Security and Usability: Designing Secure Systems That People Can Use
ISBN: 0596008279
EAN: 2147483647
Year: 2004
Pages: 295

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net