WordPress Authentication: Cookies & Sessions

Summary: Learning about How WordPress Authentication works, How are Cookies and Sessions are used for the WordPress Authentication.

Basic Concepts

• Session: A way to store user-specific data across multiple HTTP requests. Sessions can be server-side (stored in databases, files, or caches) or client-side (stored in cookies).
• Stateless Session: All session data is stored on the client side, usually in cookies. JSON Web Tokens (JWTs) are often used to secure these cookies and prevent tampering.
• Session ID: A unique identifier for each session, typically a long, random string.
• Session Cookie: A cookie that carries the session ID to maintain state between the client and server across requests.
• PHP Sessions: PHP provides built-in session management using session IDs stored in cookies and session data saved on the server.

<?php

session_start();

if (empty($_SESSION['count'])) {
   $_SESSION['count'] = 1;
} else {
   $_SESSION['count']++;
}
?>

<p>
You have seen this page <?php echo $_SESSION['count']; ?> times.
</p>

WordPress Authentication Cookies

• Authentication Cookies: In WordPress these are called “auth cookies” and are used to maintain the user’s authenticated state.

Exploration of WordPress’s Session Management

1. Session Creation:
   • wp_set_auth_cookie function initializes a new session after user authentication.
   • The function determines session expiration based on user input (e.g., “remember me”).
   • Uses WP_Session_Tokens to create a session token and save session data in the database.
2. Creating a Session & Session ID:
   • WordPress version 4.0+ introduced database-backed sessions.
   • The session ID is a 43-character random string.
   • Sessions include user IP, user agent, and timestamps.
3. Creating a Signed Cookie:
   • wp_generate_auth_cookie generates a cryptographically signed cookie containing the session ID.
   • The cookie includes username, expiration, and a cryptographic hash to ensure data integrity.
4. Session Validation:
   • wp_validate_auth_cookie verifies the auth cookie on each request.
   • Checks the signature and validates the session ID against the database.

function wp_set_auth_cookie($user_id, $remember = false, $secure = '', $token = '') {
    // CUT FOR BREVITY
    
    if ($remember) {
        $expiration = time() + apply_filters('auth_cookie_expiration', 14 * DAY_IN_SECONDS, $user_id, $remember);
    } else {
        $expiration = time() + apply_filters('auth_cookie_expiration', 2 * DAY_IN_SECONDS, $user_id, $remember);
    }
    
    // CUT FOR BREVITY
    
    if ('' === $token) {
        $manager = WP_Session_Tokens::get_instance($user_id);
        $token = $manager->create($expiration);
    }
    
    $auth_cookie = wp_generate_auth_cookie($user_id, $expiration, $scheme, $token);
    $logged_in_cookie = wp_generate_auth_cookie($user_id, $expiration, 'logged_in', $token);
    
    // COOKIE is sent to the client here via setcookie()
}

Why WordPress Uses a Combination of Stateless and Stateful Sessions

• WordPress combines elements of both JWT-style (stateless) and server-side (stateful) sessions.
• This hybrid approach introduces complexity and technical debt, potentially due to historical reasons and backwards compatibility.

Security & Threat Model

1. No Threats:
   • Cross-Site Scripting (XSS): The session cookies are marked as httpOnly, preventing JavaScript access.
   • Session Fixation: Impossible as WordPress only accepts session IDs it generates.
   • Brute-Force/Session ID Prediction: The session ID is sufficiently random (43 characters).
2. Potential Threats:
   • Man-in-the-Middle (MITM) Attacks: Cookies can be intercepted if HTTPS is not used or on untrusted networks.
   • Malware on Local Devices: Malware on a user’s device can hijack sessions. WordPress lacks built-in mechanisms like session rotation and idle timeouts to mitigate this risk.