Attacking Authentication

Authentication is the first line of defense against unauthorized access

• One of the most important security mechanisms; without it every other security mechanism falls.

Authentication Technologies

• Examples of technologies
  1. HTML forms-based authentication
     • One of the most common, using just a username and password
     • In security critical apps, there can be multiple stages of forms.
  2. Multifactor mechanisms
     1. In even more security critical apps, multiple factors, like physical tokens, are used for authentication.
  3. Client SSL certificates
  4. HTTP basic and digest authentication
     1. Rarely used on the internet, but are more prevalent on internal networks.
  5. Windows-integrated authentication methods like...
     • NTLM
     • Kerberos
  6. Authentication services

Design Flaws in Authentication Mechanisms

Bad Passwords

• Common issues:
  • Short or empty passwords
  • Common words and names
  • Password == Username
  • Default passwords
• If password quality is enforced only by client-side restrictions, this isn't necessarily a security issue. Attackers assigning themselves weak passwords is by no means something to worry about.

Brute-Forcible Login

• If an application does not limit login attempts properly, then the login is brute forcible. The following are three different examples of this vulnerability:
  1. May be client-enforced. For instance, a cookie might be set with a name-value pair recording the amount of failed logins.
     • By changing, the value in this pair, the brute-forcing can easily go undetected.
  2. Login attempts are recorded on the back-end and attributed to the user based on the session.
     • By obtaining a new session, this protection can be circumvented, too.
  3. Even after being locked out, subsequent login attempts may still respond whether the password was correct or not. Then, all that stands in the way of the attacker is a small delay.
• Admin passwords sometimes are set before password policies are set in place. This means that they may actually be weaker than policies lead one to believe.
• Process:
  1. Submit bad logins for your own account. After ~10 bad logins
     1. If you can still attempt to login, then there probably is not an account lockout policy
     2. If you are locked out, try now with a new account you control.
     3. Attempt logins using new cookies for each login attempt
     4. Try logging in and see if there is a difference in the response. If there is, even after lock-out an account password can be brute-force.
  2. If you do not own an account, try to find a valid username and attempt bad logins. Monitor the responses for error messages about lockouts.
  3. If a difference in successful and failed logins is found
     1. Compile a list of enumerated and common passwords fitting the password requirements.
     2. Compile a list of enumerated and usernames.
     3. Using a tool or a custom script, generate multiple login requests using all permutations of the usernames and passwords. Do so in a breadth-first approach.

Verbose Failure Messages

• This occurs whenever an application tells which credential was incorrect.
• When this happens, iterate through common usernames to find a valid user.
• Using an enumerated list of valid users, many different attacks can be initiated.
• This can be done at:
  • Login pages
  • User registration
  • Password change
  • Forgotten password
  • Public pages with usernames or emails.
• Failure message differences based upon successful or failed credential entry can be extremely subtle. For instance, format differences or additional short strings may be the only difference between these failure messages.
• Process:
  1. Knowing a valid username, submit a login using it and an incorrect password. Then, submit a login with a random username and an incorrect password.
  2. Record the server responses
  3. Attempt to find any difference in the responses
  4. If this fails, attempt the last three steps elsewhere in the application. For instance, try it with password changes.
  5. If differences are found, enumerate a list of valid and invalid usernames.
• Another way to find out usernames: Drastic differences in response time for login requests.

Vulnerable Transmission of Credentials

• Examples:
  • Unencrypted HTTP connections
  • Using a 302 redirect for logins, passing the credentials that were in a POST body as query string values
  • Storing credentials in cookies
    • Vulnerable to replay attacks
    • If these are captured, anyone can masquerade as another user on their network.
  • Credentials unsafely stored in:
    • Query string parameter values
    • Post body requests
    • Browser history
    • Web server logs
    • logs in reverse proxies
• Process:
  • Successfully login, storing both the request and the response.
  • Pay attention to if the form is loaded using HTTP, as opposed to HTTPS
  • Identify how credentials are transmitted
    • Look at cookies, query strings, or responses from the server.
  • If no credentials are identified, attempt to decode or deobfuscate other data that might contain sensitive data.

Password Change Functionality

• Reasons this is necessary:
  • Periodic password changes due to password expiration per password policy
  • Users that believe they've been compromised
• List of vulnerabilities:
  • Verbose error messages
  • Unlimited guesses of the "current password"
  • Checks on the new password and its confirmation are validated after the existing password is validated.
• If the username field of a form is stored on the client-side, authenticated-only password change forms may still be used as a medium for obtaining unauthorized access to another user's account.

Forgotten Password Functionality

• Design weaknesses:
  • Easy recovery questions
  • Brute-forceable password recovery responses
  • Password hints
  • Providing the old password after successfully guessing recovery answers
  • Putting the user in an authenticated session after guessing correctly
  • Sending a recovery URL to a specifiable email address.
  • Not sending an email notification on password reset/change

"Remember Me" Functionality

• Design weaknesses:
  • Using an insecure persistent cookie in requests
    • Contains the username as a value
    • Contains a unique identifier as a value
  • Vulnerable to capture from:
    • Cross-site scripting
    • Local access

User Impersonation Functionality

• Design weaknesses:
  • "Hidden" functionality using an unpublicized URL or query string without any authentication.
  • Using a valid session token with a token identifying which user the client is identifying itself as.
  • Allowing impersonation of administrative users with poor impersonation logic.
  • Backdoor password used to access any user account.

Incomplete Validation of Credentials

• Examples of design weaknesses:
  • Shortening (truncating) passwords before checks
  • Case-insensitive checks
  • Stripping unusual characters before checks

Nonunique Usernames

• Reasons this is a design flaw:
  • Same username and password combinations.
    • If rejecting the user login, then the application forfeits the original user's credentials
    • If accepting the combinations, then the second user has access to the original user's account

Predictable Usernames

• Design weaknesses:
  • Automatically generating usernames in a predictable sequence

Predictable Initial Passwords

• Some applications create users in batches with automatically assigned initial passwords.
• Just like predictable usernames, these are subject to the vulnerability of being easily guessable or predictable. Worst case is that all users have the same password.

Insecure Distribution of Credentials

• Using out-of-band channels to:
  • Send out usernames and passwords...
    • Without a time limit on first usage
    • Without a requirement to change after first use
  • Sending out account activation URLs...
    • that are predictable per user
  • Sending out welcome messages...
    • With all of the user's credentials

Implementation Flaws in Authentication

Fail-Open Login Mechanisms

• If an exception or failure happens, server-side, the application login still succeeds.
• For instance, an improper check is done in the login process. Upon failure, it falls through in the logic and still successfully logs into that user.
• Process:
  1. Perform a valid login, recording all responses and requests
  2. Repeat logins using:
     • Empty string values
     • No name-value pair at all
     • Extremely long values
     • Extremely short values
     • Submitting different data types altogether
     • Submitting the same thing multiple times using identical and different values
  3. Identify differences in responses
  4. Base further test cases on these responses.

Defects in Multi-state Login Mechanisms

• This process is extremely prone to flaws in implementation and logic.
• Design weaknesses:
  • Lack of validation of previous stage completion.
  • Ignoring or not checking differences in data from previous stages.
    • Stems from a misguided trust of previous stage data
  • Ignoring or not checking changes in username or user identity later on.
  • Storing question details in a hidden form field or cookie
  • Allowing questions to be cycled through, ignoring previous attempts.
• Process:
  1. Perform successful login
  2. Identify each stage of the login
     • Detect information that is submitted in requests multiple times
       • Submit the duplicate data using different values
  3. Repeat the login process using:
     • A different sequence than normal
     • Skipping to later stages
     • Skipping each stage sequentially

Insecure Storage of Credentials

• Design weaknesses:
  • Storing in cleartext in a database
  • Using weak hashing algorithms
  • Command or SQLi vulnerabilities

Securing Authentication

Use Strong Credentials

• Enforcing minimum password quality requirements:
  • Length
  • Using different types of characters.
    • Alphanumeric and typographic
    • Uppercase and lowercase
  • Disallowing common words, names, and passwords
• Unique usernames
• Unpredictable usernames and passwords for system-generated creentials
• Allowance of long and greatly varied passwords

Handle Credentials Secretively

• Secure transmissions using encryption technology like SSL
• Only POST requests should submit credentials.
  • No parameters or cookies for even temporary credential storage
• No storage of credentials using weak hashing algorithms or in cleartext
• "Remember-me" features should only remember nonsecret information
• Implement password change functionality
• Out-of-band credential distribution should be secure and time-limited

Validate Credentials Properly

• Fully validate credentials
• Aggressively reject unexpected events in the login process
• Code-reviews of authentication logic
• User impersonation should require administrative authentication and be private
• Validation of all stages in multi-stage authentication processes
• Disallow recovery or login question cycling

Prevent Information Leakage

• Encrypt, obfuscate, or hide all authentication parameters
• Prevent any differences in responses based on lockouts, despite post-lockout successful and failed login attempts.
• Prevent enumeration of existing usernames by either:
  • creating unique and unpredictable usernames
  • Using email addresses as usernames

Prevent Brute-Force Attacks

• Use unpredictable usernames; prevent username enumeration
• Disable accounts after a small number of failed logins
  • Require out-of-band steps to re-enable them
• Prevent information leakage of usernames
• Prevent leaking metrics regarding failed login attempts or suspension period
• Prevent login attempts from suspended accounts

Prevent Misuse of the Password Change Function

• Implement password change functionality
• Only allow access when authenticated
• Disallow username entry in the process, albeit in a cookie or form field
• Disallow a previous set of passwords to be used for new passwords
• Only use generic error messages
• Notify users via an out-of-band channel of password changes

Prevent Misuse of the Account Recovery Function

• Secure out-of-band steps for account recovery
• Do not use password hints
• For using URLs, make these unique, time-limited, single-use, and unpredictable.
• Secure all secondary challenges

Log, Monitor, Notify

• Log all authentication-related events
• Alert on anomalies
• Notify users via out-of-band channels of any critical security events
• Notify users in-band of common security events