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 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 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