ATTACKING
AUTHENTICATION
The Web Application Hacker’s Handbook, Ch. 6
Presenter: Jie Huang
10/31/2012
Authentication is Everywhere
• Probably the simplest security mechanisms
within web applications
• Front line of defense against malicious attack
• Widely used technology: HTML forms-based
authentication
• You might use it every day! (username +
password)
Other Authentication Technologies
• Multi-factor mechanisms
• Client SSL certificates and/or smartcards
• HTTP basic and digest authentication
• Windows-integrated authentication
• Authentication services
It Could Be the Achilles’ Heel As Well
• You think your password is strong enough?
• You think using https to transmit your login
information is secure enough?
• Probably NOT!
• Authentication might be the weakest link
within the whole application
Two Major Flaws in Authentication
• Design flaws
• Authentication functionality is subject to more
design weakness than any other security
mechanism employed in web applications
• Implementation flaws
• Even a well-designed authentication mechanism
may be highly insecure due to mistakes made in its
implementation
Design Flaws
• Something you did not think it can be a
vulnerability
• Verbose Failure Messages - gives attackers lots of
information to collect
• Vulnerable Transmission of Credentials
• Password Change Functionality
• Forgotten Password Functionality
• Incomplete Validation of Credentials
Verbose Failure Messages
• Error messages can have much information for
attackers to harvest
Verbose Failure Messages
• This vulnerability can be in more subtle ways
• Error messages might be the same for both valid
and invalid usernames, but there might be some
differences hidden in HTML source (comments or
layout differences, etc.)
Verbose Failure Messages
• What if the sources are also the same?
• Potential vulnerabilities are still there - difference in
responding time for valid and invalid credentials
Vulnerable Transmission of Credentials
• We all know HTTPS should be used. But from
which stage should it be used?
• When the login information needs to be submitted?
• Or when the login page is loaded?
• You can’t trust the login page if it is loaded as
HTTP since you can’t tell its authenticity
Password Change Functionality
• This function is needed for users to periodically
change the password
• Still, it is vulnerable by design
• It might provide a verbose error message indicating
whether the requested username is valid
• It might allow unrestricted guesses of the “existing
password” field
Forgotten Password Functionality
• Similar to change password function, this
function is needed
• However, it might be the weakest link at which
to attack the overall authentication logic!
Forgotten Password Functionality
• Users are inclined to set extremely insecure
challenges with the false assumption that only
they will be presented with them
• Example: “Do I own a boat?”
• Now the attacker has 50% chance of guessing it
correctly (only two possible answers: yes or no)
• Some applications disclose the existing,
forgotten password to the user after successful
completion of challengs
Forgotten Password Functionality
• Some applications immediately drop the user
into an authenticated session after successful
completion of challenges
• Some apps send a unique recovery URL to the
email address specified by the user at the time
the challenge is completed
• Some apps allow users(attackers) to reset
password directly after successful completion
of challenge, without sending a notification to
the real user
Incomplete Validation of Credentials
• Believe it or not, some applications truncate
passwords and so only validate the first n
characters
• Some apps strip out unusual characters
• Some apps perform a case-insensitive check of
passwords
• Each of the above reduces by an order of
magnitude the number of available passwords
in the pool of possible passwords!
Implementation Flaws
• Even if the design is perfectly secure, hackers
still get some chances
• Defects in multistage login mechanisms
Defects in Multistage Login Mechanisms
• Multistage mechanisms often have logic flaws
• They often make unsafe assumptions
• It may assume that a user who accessed stage three
must have cleared stages one and two
• It may trust some of the data being processed at
stage two because it was validated at stage one
Defects in Multistage Login Mechanisms
• Some apps employ a randomly varying
question at one of the stages of the login
process
• This functionality can be broken in some cases
• The app may store the details of the challenge
question within a hidden HTML form or cookie,
rather than on the server. Attackers can capture
user’s input and reuse it later
• The app may ask the user a fresh question when the
user tries to login again after a failed attempt
Securing Authentication
• Use strong credentials
• Handle credentials secretively
• Validate credentials properly
• Prevent information leakage
• Prevent brute-force attack
• Prevent misuse of password change function
• Prevent misuse of account recovery function
• Log, monitor, and notify