OWASP Broken Authentication

NTRODUCTION

The ability to authenticate to an application and persist session and other states are fundamental components needed to build useful, secure, and user-friendly software. Session security begins as soon as the user visits the site — even before they log in – and ends only after the session identifier is destroyed. Standards like OAuth, SAML, and OIDC even allow for user state that is persisted beyond traditional session lifetimes.

When we talk about broken authentication and session management, we’re not talking just about logging in and creating a session identifier. Features like password change requests, forgotten password functionality, and user registration should be treated with the same amount of care when it comes to security controls.

The topic of authentication and session management is extremely broad and complex. This lesson will provide a high-level overview. If you want more details, the OWASP Application Security Verification Standard Project will provide multiple layers of guidance regarding these topics. Also consider the NIST Special Publication 800-63-3 on Digital Identity Guidelines, which is a recent comprehensive standard that covers identity proofing and authentication of users.

At a high level, authentication is the act of confirming an entity as authentic. This entity may be an end user entering their credentials (username and password) into a web application, or the entity may be a software program utilizing a token to verify its identity. Authentication is a core tenant to building any secure system that relies on digital identity to carry out its functionality.

Let’s look at the different types of authentication.

HTTP Basic

A method for the client to provide a username and a password when making a request. HTTP basic authentication doesn’t use cookies or sessions to maintain state. Instead, the client must send an authorization HTTP header with every request it makes. This header contains the concatenated username and password, which is also encoded using Base64. HTTP basic authentication has long been considered one of the most insecure authentication mechanisms and should be avoided for several reasons. The username and password are easily reversible, as they are simply encoded and sent with every request. This greatly increases the probability of the credentials being intercepted. HTTP basic authentication also does not give developers a way to log users out, as there is no concept of state. Avoid HTTP basic authentication at all costs.

Password Authentication

Password-based authentication has long been the de facto method for authenticating to systems and applications. In the famous “something you have“, “something you know“, “something you are” authentication triad, passwords fall under the “something you know” pillar. At a high level, password-based authentication typically relies on a client submitting a password along with a user identifier such as an email address to the server, where it is then hashed. The resulting hash is validated against a list of hashed passwords for validity, and the user is either successfully authenticated or denied access.

TOTP – Multi Factor Authentication (MFA)

TOTP stands for time-based one-time password algorithm. In two-factor authentication scenarios, TOTP MFA requires that a user must enter a traditional, static password as well as a TOTP to gain access to a given system. TOTP MFA is often implemented as an SMS message or even an email containing the one-time passcode.

FIDO – U2F Multi Factor Authentication

U2F is an open authentication standard that enables internet users to securely access any number of online services with one single device, with no client software needed. A common implementation of U2F is the use of a hardware device such as a YubiKey.

Session Security Overview

SESSION SECURITY OVERVIEW

Sessions should be built to allow users to securely persist state while using an application. Once created and in use, a session identifier is a very powerful piece of data. If a valid session identifier falls into the hands of an attacker, it can be used to completely hijack a victim’s existing session, allowing the attacker to bypass standard authentication protection.

Stateful Sessions

Stateful sessions rely on maintaining a record of a session on the server side, often in the form of a database entry. Cookie-based authentication is one method of stateful session management. Cookie-based sessions generally begin with a user entering credentials (such as a username and password) in an HTML form. The credentials are sent to the server using a POST request, and the server validates the authenticity of these credentials. If the identity is confirmed, the server sends a Set-Cookie HTTP response header. The browser then puts the value in a cookie jar, and the cookie will be sent along with every request made to the same origin in the Cookie HTTP header. The server then verifies the authenticity of the cookie with a stored value and performs the requested action based on the result of the verification.

Stateless Sessions

Many modern, distributed services have been transitioning to session tokens that do not rely on storing session data on the server side. Stateless sessions rely on cryptography to consume “opaque” tokens from the client, which are encrypted by a private key stored on the server side. Complete

JSON Web Tokens (JWTs) are a very popular and widely adopted form of stateless token. A JWT is self-contained and consists of three parts:

  • Header. Contains the type of the token and the hashing algorithm.
  • Payload. Contains the claims, which are statements about an entity (typically, the user) and additional metadata.
  • Signature. Used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn’t changed along the way.

Building session management securely can seem like a daunting task. The OWASP Session Management Cheat Sheet, as well as the OWASP Application Security Verification Standard sections on Session Management Verification Requirements, covers these and other topics in great depth.

Session Security Considerations

There are a number of important things to consider when building, maintaining, or testing an application that utilizes sessions.

  • Keep session IDs private. Session IDs should never be exposed in URLs.
  • Expire sessions automatically. In order to minimize the time period an attacker can launch attacks on active sessions, all sessions should expire automatically after a predetermined amount of time. There are two approaches to this strategy, which can be used concurrently:
    • Absolute timeouts define a maximum amount of time a session can be active, regardless of whether the user is actively using the application.
    • Idle timeouts expire sessions after a period of inactivity.
  • Destroy/invalidate expired sessions. When ending a session on logout or timeout, it is important to completely destroy and invalidate the session.
    • For server-side sessions, this means invalidating the session on the server. Deleting a cookie that only holds a “session id” is often not fully destroying the session!
    • For client-side “stateless” sessions, revocation should still be a capability on the server side. Since stateless tokens are validated cryptographically, if a token is compromised, it should be included in a blacklist that is stored on the server side and checked with every request. Another layer of defense is to set very short expiration dates on stateless tokens. Once the token expires, the user or service is forced to re-authenticate. 
    • After being destroyed, the session should not have the ability to be used again.
  • Always use HTTPS for applications. Without encryption in place, an attacker could easily sniff the traffic to obtain a valid token or session identifier.
  • Always use security attributes. Always use security attributes such as HttpOnly, Secure, and SameSite for cookies that contain session identifiers.
  • Make session identifiers with high entropy. Session identifiers should never be predictable (high entropy) and be at least 20 bytes in length.

Complete

Authentication is what stands between a random passerby on the internet and a legitimate user of your application. Authentication mechanisms typically involve at least the use of a user ID and password. We highly recommend using stronger methods of authentication in addition (such as biometrics and hardware tokens), which are becoming more common and less costly to deploy. This section will focus on username and password authentication, which is the core of most authentication schemes.

Below are some guidelines to make sure your authentication mechanisms are deployed in a secure manner:

  • Enforce strong password strength restrictions that require a minimum size and complexity. You can even blacklist the use of known-weak passwords (such as “password123”).
  • Password change and password reset controls are just as important to secure as the login page. Make sure to check out the OWASP Forgot Password Cheat Sheet, which goes into much greater detail on this subject.
  • Always protect authentication credentials (such as passwords) with an adaptive one-way function with a slow work factor (such as bcrypt or Argon2). This will make passwords extremely difficult to reverse into plaintext in case of a database compromise. See OWASP Password Storage Cheat Sheet for more information.
  • Implement two-factor authentication for your application and make sure to enforce it for all sensitive actions, not just logging in. This includes password change functionality.
  • Support users of password managers. This can be done by using standard HTML forms for username and password fields, not using multi-stage login schemes, and not disabling copy and paste on HTML form fields.
  • If you are using alternative authentication protocols that do not require passwords (such as OAuth, OpenID, or SAML), make sure to reference the specific Synopsys courses for each protocol, as they each present their own security challenges.

OWASP has published a comprehensive Authentication Cheat Sheet that dives into authentication security. Also see the OWASP Application Security Verification Standard section on Authentication Verification Requirements, which covers these and other topics in great depth.

A Leaky Vault

Many Mac users are familiar with their tightly integrated “vault” software called Keychain that claims to be a secure space for users to store sensitive data such as passwords, cryptographic keys, and credit card numbers. The keychain has been designed it so that installed applications are not able to access its contents without the user entering a master password. Do you see where we are going here?

In late 2017, a security researcher named Patrick Wardle challenged this implementation head on. He was able to successfully demonstrate an attack on the vault where a rogue application is installed on the High Sierra OS and exfiltrates all of the passwords stored in the keychain and uploads them to a remote server. The attack requires no user interaction beyond the initial installation of the app, and neither the app nor macOS provides any warning or seeks permission. Scary stuff, to say the least.

Always treat your password database as though it is going to be compromised. Implement the guidelines in this lesson and the OWASP Password Storage Cheat Sheet.

Additional Resources: Password-theft 0-day imperils users of High Sierra and earlier macOS versions

Authentication Solutions : Build Vs Buy

When it comes to authentication solutions, the trend is moving away from building your own digital identity feature suite towards buying commercial products. Commercial providers such as Ping Identity and Okta, as well as frameworks such as OIDC, provide robust authentication flows that give developers and system administrators tremendous flexibility when building out identity and access management systems. The industry is shifting towards these tools for good reason. These systems reduce complexity and creates a more tightly integrated user experience, with less management overhead.  

But be warned that managing commercial identity solutions is a complex proposition. Be sure to dedicate significant resources to understanding, configuring, updating, maintaining, and monitoring these solutions over time.

Knowledge Check

Which algorithm is BEST for storing passwords?

  • SAML
  • MD5
  • OIDC
  • bcrypt