CNIT 129S - Ch 6a: Attacking Authentication
0 likes873 views
Chapter 6 of CNIT 129S discusses various vulnerabilities in web application authentication systems, highlighting the prevalence of username and password combinations, the importance of two-factor authentication, and common attack vectors like brute-force attacks and account enumeration. It addresses flaws in password reset mechanisms, session management, and credential storage, advocating for best practices in securing user credentials, such as using secure hashing methods and enforcing strong password regulations. Additionally, the chapter emphasizes the need for logging and monitoring authentication events to detect and respond to security incidents effectively.
CNIT 129S - Ch 6a: Attacking Authentication
- 1. CNIT 129S: Securing Web Applications Ch 6: Attacking Authentication Updated 2-21-28
- 2. Authentication Technologies • Over 90% of apps use name & password
- 3. More Secure Methods • Two-factor authentication (or more) • PIN from a token, SMS message, or mobile app • In addition to a password • Submitted through an HTML form
- 4. Cryptographic Methods • Client-side SSL certificate • Smartcards • More expensive, higher overhead
- 5. HTTP Authentication • Basic, Digest, and Windows-integrated • Rarely used on the Internet • More common in intranets, especially Windows domains • So authenticated employees can easily access secured resources
- 9. Design Flaws • Bad Passwords
- 11. Brute-Force Attacks • Strictly, "brute force" refers to trying every possible combination of characters • Very slow • In practice, attackers use lists of common passwords • Defense: account lockout rules after too many failed login attempts
- 14. Poor Attempt Counters • Cookie containing failedlogins=1 • Failed login counter held within the current session • Attacker can just withhold the session cookie to defeat this • Sometimes a page continues to provide information about a password's correctness even after account lockout
- 15. Insecure Lockout
- 18. Verbose Failure Messages • Friendly for legitimate users • But helpful for attackers
- 20. Script to Find Phone #s • echo $1,`curl -d "customerEmailAddress= $1" "https://www.att.com/olam/ submitSLIDEmailForgotIdSlid.myworld" - silent| grep -Po '(?<=provided ()d*'` • When you run getatt.sh john.smith@example.com it will output a line of text that looks like: • john.smith@example.com,6782345678 • Link Ch 6d
- 21. Username Importance • Attacks that reveal valid usernames are called "username enumeration" • Not as bad as finding a password, but still a privacy intrusion • But could be used for social engineering attacks, such as spearphishing emails
- 22. Similar but Non-Identical Error Messages • Any difference can be exploited; even response time
- 23. Demo • Capture Hackazon login with invalid username and password • In Proxy, HTTP History, right-click POST and Send to Comparer (Response) • Repeat with valid username and invalid password • On Comparer tab, compare Words
- 25. A
- 26. Vulnerable Transmission of Credentials • Eavesdroppers may reside:
- 27. HTTPS Risks • If credentials are sent unencrypted, the eavesdropper's task is trivial, but even HTTPS can't prevent these risks: • Credentials sent in the query string are likely to appear in server logs, browser history, and logs of reverse proxies • Many sites take credentials from a POST and then redirect it (302) to another page with credentials in the query string
- 28. HTTPS Risks • Cookie risks: • Web apps may store credentials in cookies • Even if cookies cannot be decrypted, they can be re-used • Many pages open a login page via HTTP and use an HTTPS request in the form • This can be defeated by a man-in-the-middle attack, like sslstrip
- 30. Password Change Functionality • Periodic password change mitigates the threat of password compromise (a dubious claim) • Users need to change their passwords when they believe them to be compromised
- 31. Vulnerable Password Change Systems • Reveal whether the requested username is valid • Allow unrestricted guesses of the "existing password" field • Validate the "existing password" field before comparing the "new password" and "confirm new password" fields • So an attacker can test passwords without making any actual change
- 32. Password Change Decision Tree • Identify the user • Validate "existing password" • Integrate with any account lockout features • Compare the new passwords with each other and against password quality rules • Feed back any error conditions to the user • Often there are subtle logic flaws
- 33. Forgotten Password Functionality • Often the weakest link • Uses a secondary challenge, like "mother's maiden name" • A small set of possible answers, can be brute- forced • Often can be found from public information
- 34. Forgotten Password Functionality • Often users can write their own questions • Attackers can try a long list of usernames • Seeking a really weak question, like "Do I own a boat?" • Password "Hints" are often obvious
- 35. Forgotten Password Functionality • Often the mechanism used to reset the password after a correct challenge answer is vulnerable • Some apps disclose the forgotten password to the user, so an attacker can use the account without the owner knowing • Some applications immediately let the user in after the challenge--no password needed
- 36. Forgotten Password Functionality • Some apps allow the user to specify an email for the password reset link at the time the challenge is completed • Or use email from a hidden field or cookie • Some apps allow a password reset and don't notify the user with an email
- 37. "Remember Me" • Sometimes a simple persistent cookie, like • RememberUser=jsmith • Session=728 • No need to actually log in, if username or session ID can be guessed or found
- 38. "Remember Me" • Even if the userid or session token is properly encrypted, it can be stolen via XSS or by getting access to a user's phone or PC
- 39. User Impersonation • Sometimes help desk personnel or other special accounts can impersonate users • This may have flaws like • Implemented with a "hidden" function lacking proper access controls, such as • /admin/ImpersonateUser.jsp • A guessable session number • A fixed backdoor password
- 40. Incomplete Validation • Some applications truncate passwords without telling users • Also strip unusual characters • Link Ch 6e
- 41. Nonunique Usernames • Rare but it happens • You may be able to create a new account with the same username as an existing account • During registration or a password change • If the password also matches, you can detect that from a different error messge
- 42. Predictable Usernames • Automatically generated names like • User101, User102, ...
- 43. Predictable Initial Passwords • User accounts are create in large batches • All have the same initial password
- 44. Insecure Distribution of Credentials • Passwords sent by email, SMS, etc. • Users may never change those credentials • Activation URLs may be predictable • Some apps email the new password to the user after each password change
- 45. B
- 47. Fail-Open Login • Blank or invalid username may cause an exception in the login routine • Or very long or short values • Or letters where numbers are expected... • And allow the user in
- 48. Multistage Login • Enter username and password • Enter specific digits from a PIN (a CAPTCHA) • Enter value displayed on a token
- 49. Multistage Login Defects • May allow user to skip steps • May trust data that passes step one, but let user change it, so invaid or locked-out accounts remain available • May assume that the same username applies to all three stages but not verify this
- 50. Multistage Login Defects • May use a randomly-chosen question to verify the user • But let the attacker alter that question in a hidden HTML field or cookie • Or allow many requests, so attacker can choose an easy question
- 51. Insecure Credential Storage • Plaintext passwords in database • Hashed with MD5 or SHA-1, easily cracked
- 52. Securing Authentication • Considerations • How critical is security? • Will users tolerate inconvenient controls? • Cost of supporting a user-unfriendly system • Cost of alternatives, compare to revenue generated or value of assets
- 53. Strong Credentials • Minimum password length, requiring alphabetical, numeric, and typographic characters • Avoiding dictionary words, password same as username, re-use of old passwords • Usernames should be unique • Automatically generated usernames or passwords should be long and random, so they cannot be guessed or predicted • Allow users to set strong passwords
- 54. Handle Credentials Secretively • Protect them when created, stored, and transmitted • Use well-established cryptography like SSL, not custom methods • Whole login page should be HTTPS, not just the login button • Use POST rather than GET • Don't put credentials in URL parameters or cookies
- 55. Handle Credentials Secretively • Don't transmit credentials back to the client, even in parameters to a redirect • Securely hash credentials on the server
- 56. Hashing • Password hashes must be salted and stretched • Salt: add random bytes to the password before hashing it • Stretched: many rounds of hashing (Kali Linux 2 uses 5000 rounds of SHA-512)
- 58. Handle Credentials Secretively • Client-side "remember me" functionality should remember only nonsecret items such as usernames • If you allow users to store passwords locally, they should be reversibly encrypted with a key known only to the server • And make sure there are no XSS vulnerabilities
- 59. Handle Credentials Secretively • Force users to change passwords periodically • Credentials for new users should be sent as securely as possible and time-limited; force password change on first login • Capture some login information with drop-down lists instead of text fields, to defeat keyloggers
- 60. Validate Credentials Properly • Validate entire credential, with case sensitivity • Terminate the session on any exception • Review authentication logic and code • Strictly control user impersonation
- 61. Multistage Login • All data about progress and the results of previous validation tasks should be held in the server-side session object and never available to the client • No item of information should be submitted more than once by the user • No means for the user to modify data after submission
- 62. Multistage Login • The first task at every stage should be to verify that all prior stages have been correctly completed • Always proceed through all stages, even if the first stage fails--don't give attacker any information about which stage failed
- 63. Prevent Information Leakage • All authentication failures should use the same code to produce the same error message • To avoid subtle differences that leak information • Account lockout can be used for username enumeration • Login attempts with invalid usernames should lead to the same error messages as valid ones
- 64. Self-Registration • Allowing users to choose usernames permits username enumeration. Better methods: • Generate unique, unpredictable usernames • Use e-mail addresses as usernames and require the user to receive and use an email message
- 65. Prevent Brute-Force Attacks • At login, password change, recover lost password, etc. • Using unpredictable usernames and preventing their enumeration makes brute-force attacks more difficult • High-security apps like banks disable an account after several failed logins • Account holder must do something out-of-band to re-activate account, like phone customer support and answer security questions • A 30-minute delay is friendlier and cheaper
- 66. Prevent Brute-Force Attacks • Consider this type of attack • Use many different usernames with the same password, such as "password" • Defenses: strong password rules, CAPTCHA
- 67. Password Change • No way to change username • Require user to enter the old password • Require new password twice (to prevent mistakes) • Same error message for all failures • Users should be notified out-of-band (such as via email) that the password has been changed
- 68. Account Recovery • For security-critical apps, require account recovery out-of-band • Don't use "password hints" • Email a unique, time-limited, unguessable, single-use recovery URL
- 69. Account Recovery • Challenge questions • Don't let users write their own questions • Don't use questions with low-entropy answers, such as "your favorite color"
- 70. Log, Monitor, and Notify • Log all authentication-related events • Protect logs from unauthorized access • Anomalies such as brute-force attacks should trigger IDS alerts • Notify users out-of-band of any critical security events, such as password changes • Notify users in-band of frequent security events, such as time and source IP of the last login
- 71. C