In this section we present a password selection and input scheme which uses textual passwords augmented by some minimal graphical capabilities that enable the decoupling of temporal order of input and the position in which characters are input. This scheme is interesting because it simply demonstrates the power of graphical input abilities while yielding a scheme that is convincingly stronger than textual passwords are today.
We start by defining a normal, k-character textual password as a total function , where is the set of allowed characters for the textual password. Intuitively, the domain of denotes the temporal order of inputs, so that the user first enters , then , and so on. That is, for a password ``tomato'', we have , , , , , and .
Now suppose that the user is presented with a simple graphical input display consisting of, say, eight positions into which to enter a textual password, as illustrated in Figure 1. In this figure, step 0 is the initial row of blanks, and steps 1-6 indicate the temporal order in which the user fills in the blanks; i.e., is entered in row i. The password can be placed in the ``normal'', left-to-right positions as shown in Figure 1a. Due to the graphical nature of the input interface, however, the user could enter the password in other positions, as well. For example, Figure 1b shows a modification in which the user enters the password in a left-to-right manner, but starting from a different initial position than the leftmost. Figure 1c shows entering the password in an ``outside-in'' strategy. And, of course, these variations can be combined in the obvious way, as shown in Figure 1d.
Formally, a k-character graphical password in this scheme can be defined by a total function , where is the number of positions into which characters can be entered (m = 8 in Figure 1). If , then this means that the i-th entry (temporally) is the character c in position j. A conventional textual password , entered in the standard left-to-right way, can be expressed in this scheme as a graphical password where . But as shown in Figure 1, more generally we can have variations in which and . In fact, it is easy to see that each k-character conventional password yields m!/(m-k)! graphical passwords , and indeed this is the factor by which the size of the graphical password space exceeds the k-character conventional password space. This can be a relatively large number: e.g., for k = 8 and m = 10, this factor is approximately .
Of course, there are far fewer than variations of each 8-character password that are memorable for human users. However, it is easy to derive a convincing lower bound on the improvement this achieves over a conventional password scheme. It is conservative to assume that the m positional rotations of a password, plus perhaps a handful of others (e.g., reversal, outside-in, inside-out, evens-then-odds, odds-then-evens), and combinations thereof, are memorable, because the choices of position involved in these cases can be derived from simple algorithms that are more memorable than the positions themselves. (We will return to this characteristic of memorability in the next section.) The attacker's work load will thus be increased by a factor of at least m. An important feature of this scheme is that it is at least as strong as the initial textual password that was chosen by the user, assuming that users do not reduce the size of the space of character sequences that they choose in response to the need to remember a positional order.
There are a number of steps that we can take to make this scheme more usable. First, to maximize the ease of inputting passwords with varied position, each character should be echoed once the user places it in a position, at least with a nondescript character (e.g., ``'') but preferably with the letter itself. This is a departure from most password-input interfaces, which echo at most a nondescript character in order to protect the password from onlooking persons. However, for the platforms by which we are primarily motivated, i.e., hand-held PDAs such as the Palm Pilot, it is much easier to shield the screen from onlookers entirely. Going further, the interface might allow the user to first enter the password ``normally'' (left-to-right), and then drag each character to its final position.
Inevitably, there are numerous variations on the scheme presented here. One direction includes arranging the k input positions in some other way than a straight line (e.g., a grid), to promote other variations in position. Rather than pursuing these options here, we instead explore a purely graphical approach.