The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

170

Chapter 6 

■

Attacking Authentication

70779c06.qxd:WileyRed  9/14/07  3:13 PM  Page 170

---

■■

Features such as password “hints” should absolutely never be used,

since they mainly serve to assist an attacker in trawling for accounts

with obvious hints set.

■■

The best automated solution for enabling users to regain control of

accounts is to email the user a unique, time-limited, unguessable, 

single-use recovery URL. This email should be sent to the address that

the user provided during registration. Visiting the URL will allow the

user to set a new password. After this has been done, a second email

should be sent, indicating that a password change was made. To pre-

vent an attacker denying service to users by continually requesting

password reactivation emails, the user’s existing credentials should

remain valid until such time as they are changed.

■■

To further protect against unauthorized access, applications may pre-

sent users with a secondary challenge that they must complete before

gaining access to the password reset function. Care must taken to

ensure that the design of this challenge does not introduce new 

vulnerabilities:

■■

The challenge should implement the same question or set of ques-

tions for everyone, mandated by the application during registration.

If users provide their own challenge, it is likely that some of these

will be very weak, and this also enables an attacker to enumerate

valid accounts by identifying those which have a challenge set.

■■

Responses to the challenge should contain sufficient entropy that

they cannot be easily guessed. For example, asking the user for the

name of their first school is preferable to asking for their favorite

color.

■■

Accounts should be temporarily suspended following a number of

failed attempts to complete the challenge, to prevent brute-force

attacks.

■■

The application should not leak any information in the event of

failed responses to the challenge — regarding the validity of the

username, any suspension of the account, and so on.

■■

Successful completion of the challenge should be followed by the

process described previously, in which a message is sent to the

user’s registered email address containing a reactivation URL.

Under no circumstances should the application disclose the user’s

forgotten password or simply drop the user into an authenticated

session. Even proceeding directly to the password reset function is

undesirable, because the response to the account recovery challenge

will in general be easier for an attacker to guess than the original

password, and so it should not be relied upon on its own to authen-

ticate the user.