the-web-application-hackers-handbook

Chapter 6 n Attacking Authentication 187
frequently contain security vulnerabilities — in particular, various logic flaws
(see Chapter 11).
COMMON MYTH
It is often assumed that multistage login mechanisms are less prone to security
bypasses than standard username/password authentication. This belief
is mistaken. Performing several authentication checks may add considerable
security to the mechanism. But counterbalancing this, the process is more
prone to flaws in implementation. In several cases where a combination of
flaws is present, it can even result in a solution that is less secure than a normal
login based on username and password.
Some implementations of multistage login mechanisms make potentially
unsafe assumptions at each stage about the user’s interaction with earlier stages:
n An application may assume that a user who accesses stage three must
have cleared stages one and two. Therefore, it may authenticate an attacker
who proceeds directly from stage one to stage three and correctly completes
it, enabling an attacker to log in with only one part of the various
credentials normally required.
n An application may trust some of the data being processed at stage two
because this was validated at stage one. However, an attacker may be able
to manipulate this data at stage two, giving it a different value than was
validated at stage one. For example, at stage one the application might
determine whether the user’s account has expired, is locked out, or is in
the administrative group, or whether it needs to complete further stages
of the login beyond stage two. If an attacker can interfere with these
flags as the login transitions between different stages, he may be able to
modify the application’s behavior and cause it to authenticate him with
only partial credentials or otherwise elevate privileges.
n An application may assume that the same user identity is used to complete
each stage; however, it might not explicitly check this. For example, stage
one might involve submitting a valid username and password, and stage
two might involve resubmitting the username (now in a hidden form
field) and a value from a changing physical token. If an attacker submits
valid data pairs at each stage, but for different users, the application might
authenticate the user as either one of the identities used in the two stages.
This would enable an attacker who possesses his own physical token and
discovers another user’s password to log in as that user (or vice versa).
Although the login mechanism cannot be completely compromised without
any prior information, its overall security posture is substantially
weakened, and the substantial expense and effort of implementing the
two-factor mechanism do not deliver the benefits expected.