ATTACKING AUTHENTICATION

1. ATTACKING AUTHENTICATION The Web Application Hacker’s Handbook, Ch. 6 Presenter: Jie Huang 10/31/2012

2. 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)

3. Other Authentication Technologies • Multi-factor mechanisms • Client SSL certificates and/or smartcards • HTTP basic and digest authentication • Windows-integrated authentication • Authentication services

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

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

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

7. Verbose Failure Messages • Error messages can have much information for attackers to harvest

8. 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.)

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

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

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

12. 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!

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

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

15. 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!

16. Implementation Flaws • Even if the design is perfectly secure, hackers still get some chances • Defects in multistage login mechanisms

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

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

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

20. Thank You!