the-web-application-hackers-handbook

174 Chapter 6 n Attacking Authentication
to set extremely insecure challenges, presumably on the false assumption
that only they will ever be presented with them. An example is “Do I own
a boat?” In this situation, an attacker who wants to gain access can use
an automated attack to iterate through a list of enumerated or common
usernames, log all the password recovery challenges, and select those that
appear most easily guessable. (See Chapter 14 for techniques regarding
how to grab this kind of data in a scripted attack.)
n As with password change functionality, application developers commonly
overlook the possibility of brute-forcing the response to a password recovery
challenge, even when they block this attack on the main login page. If
an application allows unrestricted attempts to answer password recovery
challenges, it is highly likely to be compromised by a determined attacker.
n In some applications, the recovery challenge is replaced with a simple
password “hint” that is configured by users during registration. Users
commonly set extremely obvious hints, perhaps even one that is identical
to the password itself, on the false assumption that only they will
ever see them. Again, an attacker with a list of common or enumerated
usernames can easily capture a large number of password hints and then
start guessing.
n The mechanism by which an application enables users to regain control of
their account after correctly responding to a challenge is often vulnerable.
One reasonably secure means of implementing this is to send a unique,
unguessable, time-limited recovery URL to the e-mail address that the
user provided during registration. Visiting this URL within a few minutes
enables the user to set a new password. However, other mechanisms for
account recovery are often encountered that are insecure by design:
n Some applications disclose the existing, forgotten password to the user
after successful completion of a challenge, enabling an attacker to use
the account indefinitely without any risk of detection by the owner.
Even if the account owner subsequently changes the blown password,
the attacker can simply repeat the same challenge to obtain the new
password.
n Some applications immediately drop the user into an authenticated
session after successful completion of a challenge, again enabling an
attacker to use the account indefinitely without detection, and without
ever needing to know the user’s password.
n Some applications employ the mechanism of sending a unique recovery
URL but send this to an e-mail address specified by the user at the
time the challenge is completed. This provides absolutely no enhanced
security for the recovery process beyond possibly logging the e-mail
address used by an attacker.