Download as PDF, PPTX
Uploaded bySam Bowne
Ch 6: Attacking Authentication
This document provides a summary of authentication techniques and common vulnerabilities. It discusses how over 90% of applications use usernames and passwords for authentication. More secure authentication methods like two-factor authentication are also described. The document outlines various authentication protocols like HTTP, SAML, and JWT. It then details common design flaws such as weak passwords, password change vulnerabilities, account recovery issues, and information leakage. Specific attacks like brute force, credential stuffing, and session hijacking are examined. The summary recommends approaches to secure authentication like strong credentials, hashing passwords, multi-factor authentication, and logging authentication events.
More Related Content
Similar to Ch 6: Attacking Authentication
![Java Web Programming [9/9] : Web Application Security](https://cdn.slidesharecdn.com/ss_thumbnails/javaweb-module9-130106071127-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Ch 6: Attacking Authentication
- 1. CNIT 129S: Securing WebApplications Ch 6: Attacking Authentication Updated 2-23-2022
- 2. Authentication Technologies • Over90% of apps use name & password
- 3. More Secure Methods •Two-factor authentication (or more ) • PIN from a token, SMS message, or mobile ap p • In addition to a passwor d • Submitted through an HTML form
- 4. Cryptographic Methods • Client-sideSSL certi fi cat e • Smartcard s • More expensive, higher overhea d • SAML and JWT (at end of slides)
- 5. HTTP Authentication • Basic,Digest, and Windows-integrate d • Rarely used on the Interne t • More common in intranets, especially Windows domain s • So authenticated employees can easily access secured resources
- 6.
- 7.
- 8.
- 10. Design Flaws • BadPasswords
- 12. Brute-Force Attacks • Attackersuse lists of common password s • 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 sessio n • Attacker can just withhold the session cookie to defeat thi s • Sometimes a page continues to provide information about a password's correctness even after account lockout
- 15. Verbose Failure Messages •Friendly for legitimate user s • But helpful for attackers
- 17. Script to FindPhone #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,678234567 8 • Link Ch 6d
- 18. Username Importance • Attacksthat reveal valid usernames are called "username enumeration " • Not as bad as fi nding a password, but still a privacy intrusio n • But could be used for social engineering attacks, such as spearphishing emails
- 19. Similar but Non-Identical ErrorMessages • Any difference can be exploited; even response time
- 20.
- 21. Vulnerable Transmission of Credentials •Eavesdroppers may reside:
- 22. HTTPS Risks • Ifcredentials 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 proxie s • Many sites take credentials from a POST and then redirect it (302) to another page with credentials in the query string
- 23. HTTPS Risks • Cookierisks : • Web apps may store credentials in cookie s • Even if cookies cannot be decrypted, they can be re-use d • Many pages open a login page via HTTP and use an HTTPS request in the for m • This can be defeated by a man-in-the-middle attack, like sslstrip
- 24. Password Change Functionality • Periodicpassword change mitigates the threat of password compromise (a dubious claim ) • Users need to change their passwords when they believe them to be compromised
- 25. Vulnerable Password Change Systems •Reveal whether the requested username is vali d • Allow unrestricted guesses of the "existing password" fi el d • Validate the "existing password" fi eld before comparing the "new password" and "con fi rm new password" fi eld s • So an attacker can test passwords without making any actual change
- 26. Password Change Decision Tree •Identify the use r • Validate "existing password " • Integrate with any account lockout feature s • Compare the new passwords with each other and against password quality rule s • Feed back any error conditions to the use r • Often there are subtle logic fl aws
- 27. Forgotten Password Functionality • Oftenthe weakest lin k • Uses a secondary challenge, like "mother's maiden name " • A small set of possible answers, can be brute- force d • Often can be found from public information
- 28. Forgotten Password Functionality • Oftenusers can write their own question s • Attackers can try a long list of username s • Seeking a really weak question, like "Do I own a boat? " • Password "Hints" are often obvious
- 29. Forgotten Password Functionality • Oftenthe mechanism used to reset the password after a correct challenge answer is vulnerabl e • Some apps disclose the forgotten password to the user, so an attacker can use the account without the owner knowin g • Some applications immediately let the user in after the challenge--no password needed
- 30. Forgotten Password Functionality • Someapps allow the user to specify an email for the password reset link at the time the challenge is complete d • Or use email from a hidden fi eld or cooki e • Some apps allow a password reset and don't notify the user with an email
- 31. "Remember Me" • Sometimesa simple persistent cookie, like • RememberUser=jsmit h • Session=72 8 • No need to actually log in, if username or session ID can be guessed or found
- 32. "Remember Me" • Evenif 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
- 33. User Impersonation • Sometimeshelp desk personnel or other special accounts can impersonate user s • This may have fl aws lik e • Implemented with a "hidden" function lacking proper access controls, such as • /admin/ImpersonateUser.js p • A guessable session numbe r • A fi xed backdoor password
- 34. Incomplete Validation • Someapplications truncate passwords without telling user s • Also strip unusual character s • Link Ch 6e
- 35. Nonunique Usernames • Rarebut it happen s • You may be able to create a new account with the same username as an existing accoun t • During registration or a password chang e • If the password also matches, you can detect that from a different error messge
- 36. Predictable Usernames • Automaticallygenerated names lik e • User101, User102, ...
- 37. Predictable Initial Passwords •User accounts are create in large batche s • All have the same initial password
- 38. Insecure Distribution of Credentials •Passwords sent by email, SMS, etc . • Users may never change those credential s • Activation URLs may be predictabl e • Some apps email the new password to the user after each password change
- 39.
- 40.
- 41. Fail-Open Login • Blankor invalid username may cause an exception in the login routin e • Or very long or short value s • Or letters where numbers are expected.. . • And allow the user in
- 42. Multistage Login • Enterusername and passwor d • Enter speci fi c digits from a PIN (a CAPTCHA ) • Enter value displayed on a token
- 43. Multistage Login Defects •May allow user to skip step s • May trust data that passes step one, but let user change it, so invaid or locked-out accounts remain availabl e • May assume that the same username applies to all three stages but not verify this
- 44. Multistage Login Defects •May use a randomly-chosen question to verify the use r • But let the attacker alter that question in a hidden HTML fi eld or cooki e • Or allow many requests, so attacker can choose an easy question
- 45. Insecure Credential Storage •Plaintext passwords in databas e • Hashed with MD5 or SHA-1, easily cracked
- 46. Securing Authentication • Consideration s •How critical is security ? • Will users tolerate inconvenient controls ? • Cost of supporting a user-unfriendly syste m • Cost of alternatives, compare to revenue generated or value of assets
- 47. Strong Credentials • Minimumpassword length, requiring alphabetical, numeric, and typographic character s • Avoiding dictionary words, password same as username, re-use of old password s • Usernames should be uniqu e • Automatically generated usernames or passwords should be long and random, so they cannot be guessed or predicte d • Allow users to set strong passwords
- 48. Handle Credentials Secretively • Protectthem when created, stored, and transmitte d • Use well-established cryptography like SSL, not custom method s • Whole login page should be HTTPS, not just the login butto n • Use POST rather than GE T • Don't put credentials in URL parameters or cookies
- 49. Handle Credentials Secretively • Don'ttransmit credentials back to the client, even in parameters to a redirec t • Securely hash credentials on the server
- 50. Hashing • Password hashesmust be salted and stretche d • Salt: add random bytes to the password before hashing i t • Stretched: many rounds of hashing (Kali Linux 2 uses 5000 rounds of SHA-512)
- 52. Handle Credentials Secretively • Client-side"remember me" functionality should remember only nonsecret items such as username s • If you allow users to store passwords locally, they should be reversibly encrypted with a key known only to the serve r • And make sure there are no XSS vulnerabilities
- 53. Handle Credentials Secretively • Forceusers to change passwords periodicall y • No longer recommende d • Credentials for new users should be sent as securely as possible and time-limited; force password change on fi rst logi n • Capture some login information with drop-down lists instead of text fi elds, to defeat keyloggers
- 54. Validate Credentials Properly • Validateentire credential, with case sensitivit y • Terminate the session on any exceptio n • Review authentication logic and cod e • Strictly control user impersonation
- 55. Multistage Login • Alldata about progress and the results of previous validation tasks should be held in the server-side session object and never available to the clien t • No item of information should be submitted more than once by the use r • No means for the user to modify data after submission
- 56. Multistage Login • The fi rsttask at every stage should be to verify that all prior stages have been correctly complete d • Always proceed through all stages, even if the fi rst stage fails--don't give attacker any information about which stage failed
- 57. Prevent Information Leakage •All authentication failures should use the same code to produce the same error messag e • To avoid subtle differences that leak informatio n • Account lockout can be used for username enumeratio n • Login attempts with invalid usernames should lead to the same error messages as valid ones
- 58. Self-Registration • Allowing usersto choose usernames permits username enumeration. Better methods : • Generate unique, unpredictable username s • Use e-mail addresses as usernames and require the user to receive and use an email message
- 59. Prevent Brute-Force Attacks •At login, password change, recover lost password, etc . • Using unpredictable usernames and preventing their enumeration makes brute-force attacks more dif fi cul t • High-security apps like banks disable an account after several failed login s • Account holder must do something out-of-band to re-activate account, like phone customer support and answer security question s • A 30-minute delay is friendlier and cheaper
- 60. Prevent Brute-Force Attacks •Password Spray attac k • Use many different usernames with the same password, such as "password " • Avoids account lockout s • Defenses: strong password rules, CAPTCHA
- 61. Password Change • Noway to change usernam e • Require user to enter the old passwor d • Require new password twice (to prevent mistakes ) • Same error message for all failure s • Users should be noti fi ed out-of-band (such as via email) that the password has been changed
- 62. Account Recovery • Forsecurity-critical apps, require account recovery out-of-ban d • Don't use "password hints " • Email a unique, time-limited, unguessable, single-use recovery URL
- 63. Account Recovery • Challengequestion s • Don't let users write their own question s • Don't use questions with low-entropy answers, such as "your favorite color"
- 64. Log, Monitor, andNotify • Log all authentication-related event s • Protect logs from unauthorized acces s • Anomalies such as brute-force attacks should trigger IDS alert s • Notify users out-of-band of any critical security events, such as password change s • Notify users in-band of frequent security events, such as time and source IP of the last login
- 65.
- 66. SAML (Security Assertion MarkupLanguage) • http://samlol.samsclass.info
- 67. Send password toidentity provider
- 68.
- 69. Intercept & Decode •Change user name from user1 to admi n • Turn off Intercept • Attack fails
- 70. Remove Signatures • Change user name from user1to dem o • Turn off Intercept
- 71.
- 73. JWT Attacks • Failingto verify signature • "NONE" algorithm (no signature required) • Weak HMAC Keys • Command injection • Path traversal • SQL injection • More...