Downloaded 10 times
Uploaded bySam Bowne
CNIT 129: 6. Attacking Authentication
Chapter 6 of 'Securing Web Applications' discusses various authentication attack vectors and their defenses, highlighting that over 90% of applications use username and password authentication. It emphasizes the need for stronger methods like two-factor authentication, secure credential storage, and validated password change functionalities to mitigate risks such as brute-force attacks, username enumeration, and insecure transmission of credentials. The chapter also outlines best practices for securing authentication processes, including the implementation of multi-stage logins, proper logging of events, and protecting user data from vulnerabilities.
EducationâŚ
More Related Content
Similar to CNIT 129: 6. Attacking Authentication
CNIT 129: 6. Attacking Authentication
- 1. CNIT 129S: Securing WebApplications Ch 6: Attacking Authentication Updated 2-25-2021
- 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 overhead
- 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 ⢠Strictly,"brute force" refers to trying every possible combination of character s ⢠Very slo w ⢠In practice, attackers use lists of common password s ⢠Defense: account lockout rules after too many failed login attempts
- 15. 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
- 16.
- 19. Verbose Failure Messages â˘Friendly for legitimate user s ⢠But helpful for attackers
- 21. 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
- 22. 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
- 23. Similar but Non-Identical ErrorMessages ⢠Any difference can be exploited; even response time
- 24. Demo ⢠Capture Hackazonlogin 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.
- 26.
- 27. Vulnerable Transmission of Credentials â˘Eavesdroppers may reside:
- 28. 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
- 29. 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
- 31. 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
- 32. 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
- 33. 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
- 34. 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
- 35. 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
- 36. 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
- 37. 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
- 38. "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
- 39. "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
- 40. 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
- 41. Incomplete Validation ⢠Someapplications truncate passwords without telling user s ⢠Also strip unusual character s ⢠Link Ch 6e
- 42. 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
- 43. Predictable Usernames ⢠Automaticallygenerated names lik e ⢠User101, User102, ...
- 44. Predictable Initial Passwords â˘User accounts are create in large batche s ⢠All have the same initial password
- 45. 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
- 46.
- 47.
- 48. 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
- 49. Multistage Login ⢠Enterusername and passwor d ⢠Enter speci fi c digits from a PIN (a CAPTCHA ) ⢠Enter value displayed on a token
- 50. 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
- 51. 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
- 52. Insecure Credential Storage â˘Plaintext passwords in databas e ⢠Hashed with MD5 or SHA-1, easily cracked
- 53. 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
- 54. 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
- 55. TED iOS App â˘Bad password list, part of React.js
- 56. 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
- 57. Handle Credentials Secretively ⢠Don'ttransmit credentials back to the client, even in parameters to a redirec t ⢠Securely hash credentials on the server
- 58. 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)
- 60. 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
- 61. Handle Credentials Secretively ⢠Forceusers to change passwords periodicall y ⢠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
- 62. 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
- 63. 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
- 64. 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
- 65. 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
- 66. 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
- 67. 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
- 68. 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
- 69. 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
- 70. 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
- 71. 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"
- 72. 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
- 73.