Timing Attack in Chi with Basic Auth

A timing attack in the Chi HTTP server becomes relevant when endpoints use HTTP Basic Authentication and the comparison of the client-supplied credentials is performed in a way whose execution time depends on the input. In Chi, this typically manifests when a developer compares the Authorization header value or the decoded username/password using a non-constant-time string comparison. An attacker can measure response times to infer information about the expected credentials, gradually narrowing down valid characters or hashes.

Chi itself does not enforce any particular authentication mechanism; it is a composable router. Therefore, the vulnerability arises from how the developer wires authentication into the middleware or handler chain. For example, if you decode the Basic Auth credential and compare the password byte-by-byte using a simple equality check, the first mismatching character may cause an earlier return, allowing an attacker to infer partial values from timing differences. This is especially relevant when the valid password or hash is long or when the comparison is implemented manually rather than using a constant-time utility.

Consider a Chi route that expects a Base64-encoded Authorization header. A naive handler might decode the token, split username and password, then compare the password against a stored value using a standard equality operator. Because standard string or byte equality in many languages is short-circuiting, the time taken grows with the number of matching leading characters. In a controlled network environment, an attacker can send many requests with slightly altered credentials and measure round-trip times to statistically infer the correct password or hash. This weakens the security of otherwise strong passwords or API keys stored as hashes.

Real-world attack patterns relevant to this scenario include variants of the Lucky Thirteen or similar timing-based oracle attacks, adapted to authentication comparisons. While Chi does not prescribe a specific auth scheme, frameworks and libraries commonly integrated with Chi may expose timing differences if not used carefully. For instance, comparing HMACs or password digests without a constant-time routine introduces a measurable side channel. OWASP API Security Top 10 categories such as Broken Object Level Authorization and Improper Rate Limiting can intersect here, as attackers may combine timing observations with other checks to enumerate valid accounts.

Because the scan categories in middleBrick include Authentication and Input Validation, a scan against a Chi service using Basic Auth can surface findings if the implementation lacks constant-time checks. The scanner tests unauthenticated endpoints and can detect timing-related deviations by observing response consistency across crafted inputs. This helps identify whether authentication paths introduce observable timing differences that could be leveraged in practice.

To mitigate timing attacks in Chi when using HTTP Basic Authentication, ensure that any credential comparison uses a constant-time routine. In languages such as Go, use functions like subtle.ConstantTimeCompare from the standard library when comparing byte representations of passwords or HMAC digests. Avoid manual loops or string equality that short-circuits on the first mismatch. Additionally, structure your middleware so that authentication parsing and validation do not branch early based on partial credential knowledge.

Below are example implementations that demonstrate secure handling of Basic Auth in Chi. These snippets show how to extract credentials and perform comparisons in a way that reduces timing side channels.

Example 1: Constant-time password comparison in Chi middleware (Go)

package main

import (
    "crypto/subtle"
    "encoding/base64"
    "net/http"
    "strings"
)

// constantTimeBasicAuth returns a Chi middleware that validates Basic Auth
// using a constant-time comparison for the password digest.
func constantTimeBasicAuth(expectedUser, expectedPasswordDigest string) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            auth := r.Header.Get("Authorization")
            if auth == "" || !strings.HasPrefix(auth, "Basic ") {
                http.Error(w, "Unauthorized", http.StatusUnauthorized)
                return
            }
            payload, err := base64.StdEncoding.DecodeString(strings.TrimPrefix(auth, "Basic "))
            if err != nil {
                http.Error(w, "Bad Request", http.StatusBadRequest)
                return
            }
            // Expected format: user:password
            parts := strings.SplitN(string(payload), ":", 2)
            if len(parts) != 2 {
                http.Error(w, "Bad Request", http.StatusBadRequest)
                return
            }
            user, pass := parts[0], parts[1]
            if subtle.ConstantTimeCompare([]byte(user), []byte(expectedUser)) != 1 {
                http.Error(w, "Unauthorized", http.StatusUnauthorized)
                return
            }
            // Compare password digests in constant time
            if subtle.ConstantTimeCompare([]byte(pass), []byte(expectedPasswordDigest)) != 1 {
                http.Error(w, "Unauthorized", http.StatusUnauthorized)
                return
            }
            next.ServeHTTP(w, r)
        })
    }
}

// Usage:
// r := chi.NewRouter()
// r.Use(constantTimeBasicAuth("apiuser", "5f4dcc3b5aa765d61d8327deb882cf99")) // MD5 of "password" for illustration only
// r.Get("/secure", func(w http.ResponseWriter, r *http.Request) { w.Write([]byte("OK")) })

Example 2: Rejecting short-circuit comparisons and using fixed-time validation

package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/base64"
    "net/http"
    "strings"
)

// verifyHMACConstantTime verifies a Base64-encoded HMAC in the Authorization header
// using constant-time comparison to avoid timing leaks.
func verifyHMACConstantTime(secret string, expectedMAC string) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            auth := r.Header.Get("Authorization")
            if auth == "" || !strings.HasPrefix(auth, "Basic ") {
                http.Error(w, "Unauthorized", http.StatusUnauthorized)
                return
            }
            payload, err := base64.StdEncoding.DecodeString(strings.TrimPrefix(auth, "Basic "))
            if err != nil {
                http.Error(w, "Bad Request", http.StatusBadRequest)
                return
            }
            // Here payload is treated as the HMAC of the request content or a nonce.
            mac := hmac.New(sha256.New, []byte(secret))
            mac.Write([]byte(r.URL.Path)) // example input
            expected := mac.Sum(nil)
            if !hmac.Equal(expected, []byte(expectedMAC)) {
                http.Error(w, "Unauthorized", http.StatusUnauthorized)
                return
            }
            next.ServeHTTP(w, r)
        })
    }
}

In addition to code-level fixes, consider operational practices such as rate limiting and monitoring for abnormal request patterns that could indicate probing. While middleBrick can highlight authentication timing risks in scans, remediation requires deliberate implementation of constant-time utilities and disciplined handling of credentials within Chi routes and middleware.