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