applications may not only ask users to identify themselves, but also to authenticate that the individuals are who they claim to be.
Perhaps one of the most challenging aspects of a Web application's design is devising a user authentication mechanism that yields a high degree of accuracy while at the same time not significantly impacting the usability of the application or its performance. Given that in the case of an Internet-based Web application, users could be thousands of miles away in foreign jurisdictions and using all manner of client-side hardware and system software, this is far from a trivial task. Consequently, this is an area that will warrant comprehensive testing.
Most Web applications rely on one of three different techniques for establishing the authenticity of a user: relying upon something users know (such as passwords), something they have (like physical keys), or some physical attribute of themselves (for instance, fingerprints). These three strategies can all be implemented in a number of different ways, each with a different trade-off between cost, ease of use, and accuracy. Whichever approach is selected by the application's designers, it should be tested to ensure that the approach provides the anticipated level of accuracy.
The accuracy of an authentication mechanism can be measured in two ways: (1) the percentage of legitimate users who attempt to authenticate themselves but are rejected by the system (sometimes referred to as the false rejection rate) and (2) the percentage of unauthorized users who are able to dupe the system into wrongly thinking they are authorized to use the system (sometimes referred to as the false acceptance rate). Unfortunately, obtaining a low false acceptance rate (bad guys have a hard time getting in) typically results in a high false rejection rate (good guys are frequently turned away). For example, increasing the number of characters that users must use for their passwords may make it harder for an attacker to guess (or crack) any, but it may also increase the frequency with which legitimate users forget this information.
The risks associated with a false acceptance, compared to a false rejection, are quite different. A false acceptance may allow intruders to run amok, exploiting whatever application privileges the system had mistakenly granted them. Although a single false rejection may not be very significant, over time a large volume of false rejections can have a noticeable effect on an application. For instance, a bank that requires multiple, hard-to- remember passwords may make its Web application so user-unfriendly that its adoption rate among its clients is much lower than its competitor's. This would result in a larger percentage of its clients visiting physical branches of the bank or using its telephone banking system (both of which are more costly services to provide) and consequently giving its competitor a cost-saving advantage.
From a testing perspective, the testing team should attempt to determine if a Web application's false acceptance and false rejection rates are within the limits originally envisaged by the application's designers (and users). Additionally, because there is no guarantee that a particular authentication technique has been implemented correctly, the method by which the authentication takes place should be evaluated to ensure the authentication process itself can't be compromised (such as an attacker eavesdropping on an unencrypted application password being sent over the network). To this end, the following sections outline some of the techniques that might be implemented in order to authenticate a user of a Web application. Krutz (2001) and Smith (2001) provide additional information on user authentication strategies.
Relying upon What the User Knows: The Knows-Something Approach
The authenticity of the user is established by asking the user to provide some item of information that only the real user would be expected to know. The classic userID and password combination is by far the most common implementation of this authentication strategy. Variations of this method of authentication include asking the user to answer a secret question (such as "What's your mother's maiden name?") or provide a valid credit card number, together with corresponding billing address information.
Although the issues associated with application-level userIDs and passwords are similar to those affecting system software userIDs and passwords (see Chapter 4 for a discussion on this topic), an organization that has developed its own applications may have more flexibility in its userID and password implementations. Specifically, the organization may choose to enforce more or less rigorous standards than those implemented in the products developed by outside vendors. For instance, the organization may check that any new password selected by a user is not to be found in a dictionary, or the organization may enforce a one- user, one-machine policy (that is, no user can be logged on to more than one machine, and no machine can simultaneously support more than one user).
Therefore, in addition to the userID checklist in Table 4.17, the testing team may also want to consider including some or all of the checks in Table 5.1, depending upon what was specified in the applications security specifications.
Table 5.1: Application UserID and Password Checklist YES NO DESCRIPTION
□ □ Does the application prohibit users from choosing common (and therefore easily guessable) words for passwords?
□ □ Does the application prohibit users from choosing weak (and therefore easily deciphered) passwords, such as ones that are only four characters long?
□ □ If users are required to change their passwords every X number of weeks, does the application enforce this rule?
□ □ If users are required to use different passwords for Y generations of passwords, does the application enforce this rule?
□ □ Is the application capable of allowing more than one user on the same client machine to access the server-side component of the application at the same time?
□ □ Is the application capable of allowing one user to access the server- side component of the application from two or more client machines at the same time?
□ □ Is the authentication method's false rejection rate acceptable? Is it measured by the number of calls made to the help desk for forgotten
Relying upon What the User Has: The Has-Something Approach
Instead of relying on a user's memory, the Web application could require that users actually have in their possession some artifact or token that is not easily reproducible. The token could be physical (such as a key or smart card), software based (a personal certificate), or assigned to a piece of hardware by software (for instance, a media access control [MAC] address could be assigned to an Ethernet card, a telephone number to a telephone, or an IP address to a network device).
If this has-something approach is used to authenticate a user to a Web application, the testing team will need to test the enforcement of the technique. For instance, if the authorized user Lee Copeland has a home telephone number of (123) 456-7890, then the organization may decide to allow any device to access the organization's intranet applications if accessed from this number. The testing team could verify that this authentication method has been implemented correctly by first attempting to gain access to the applications from Lee's home and then attempting access from an unauthorized telephone number such as Lee's next-door neighbor's.
Sole reliance on an authentication method such as the telephone number or network address of the requesting machine may not make for a very secure defense. For instance, Lee's kids could access the organization's application while watching TV, or a knowledgeable intruder may be able to trick a system into thinking he is using an authorized network address when in fact he isn't (a technique commonly referred to as spoofing). Scenarios such as these illustrate why many of these has-something authentication methods are used in conjunction with a knows-something method. Two independent authentication methods provide more security (but perhaps less usability) than one. So in addition to the telephone number requirement, Lee would still need to authenticate himself with his userID and password combination.
The following section describes some of the most common has-something authentication techniques.