Timing Attack in Echo Go with Basic Auth

A timing attack in the Echo Go framework when Basic Auth is used occurs because the comparison of the client-supplied credentials with the server-stored values is often performed in a way whose execution time varies with the similarity of the strings. An attacker can measure response times to infer information about the valid username or password, effectively bypassing the intended secrecy of the credentials. This is a classic oracle-based attack where network latency and server processing become the leak channel.

In Echo Go, if the handler manually iterates over an expected password or compares byte slices using a simple equality check without constant-time guarantees, the underlying implementation may short-circuit on the first mismatched byte. For example, a naive comparison like if password == storedPassword will exit early when the leading bytes differ, making the request faster for incorrect prefixes. An attacker can send many requests while measuring round-trip times, gradually learning the correct password one byte at a time. When combined with knowledge of the username format (e.g., an email), this can lead to full credential recovery without triggering account lockouts.

The vulnerability is amplified because Basic Auth transmits credentials in an Authorization header encoded as Basic base64(username:password). While the encoding itself does not provide confidentiality, the server’s processing of the decoded string determines whether the comparison is safe. If the server decodes the header and then performs a non-constant-time string comparison, the timing side channel is exposed. Attackers can exploit this even over a network with modest latency by performing statistical analysis on many samples. Furthermore, if the server returns different HTTP status codes or response bodies for malformed versus valid-but-wrong credentials, the attacker gains additional observable signals, turning the entire handshake into a measurable oracle.

Echo Go applications that integrate third-party authentication libraries or middleware must verify that those components use constant-time primitives. Standard library functions such as bytes.Equal in Go are not guaranteed to run in constant time for all inputs in all versions, so relying on them for credential comparison is risky. The presence of multiple authentication schemes in the same codebase can also lead to inconsistent handling, where one path uses a secure compare and another does not. Continuous scanning with a tool like middleBrick can detect timing-related anomalies in the unauthenticated attack surface, flagging endpoints where response behavior correlates with credential validation logic.

To mitigate timing attacks in Echo Go with Basic Auth, you must ensure that any comparison of secrets is performed in constant time and that the server’s responses do not leak information via timing or status codes. Below are concrete, secure patterns you can apply directly in your handlers.

1. Use constant-time comparison for credentials

Replace standard equality checks with a function that always iterates over the full length of the secret. In Go, you can use subtle.ConstantTimeCompare from the crypto/subtle package. This ensures the execution time does not depend on how many leading bytes match.

package main

import (
	"crypto/subtle"
	"net/http"
	"strings"

	"github.com/labstack/echo/v4"
)

func secureBasicAuthMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
	// Expected credentials — in production, load from a secure secret store.
	const expectedUser = "admin"
	const expectedPass = "S3cur3P@ss!"

	return func(c echo.Context) error {
		auth := c.Request().Header.Get("Authorization")
		if auth == "" {
			return c.NoContent(http.StatusUnauthorized)
		}

		const prefix = "Basic "
		if !strings.HasPrefix(auth, prefix) {
			return c.NoContent(http.StatusUnauthorized)
		}

		decoded, err := base64.StdEncoding.DecodeString(auth[len(prefix):])
		if err != nil {
			// Return a uniform response to avoid leaking why the decode failed.
			return c.NoContent(http.StatusUnauthorized)
		}

		parts := strings.SplitN(string(decoded), ":", 2)
		if len(parts) != 2 {
			return c.NoContent(http.StatusUnauthorized)
		}

		user, pass := parts[0], parts[1]
		if subtle.ConstantTimeCompare([]byte(user), []byte(expectedUser)) != 1 ||
		   subtle.ConstantTimeCompare([]byte(pass), []byte(expectedPass)) != 1 {
			return c.NoContent(http.StatusUnauthorized)
		}

		return next(c)
	}
}

2. Standardize error responses

Ensure that unauthorized requests always return the same HTTP status code and similar body size to prevent timing or size-based leaks. Avoid returning detailed error messages that could aid an attacker. The middleware above returns 401 Unauthorized with no body for all failure paths, making timing measurements noisy and unhelpful.

3. Prefer token-based authentication when possible

Basic Auth sends credentials on every request, increasing exposure. If your API supports it, use bearer tokens with constant-time validation instead. Tokens can be rotated easily and are less prone to accidental leakage in logs or referrer headers.

4. Scan and monitor

Use middleBrick to scan your Echo Go endpoints and validate that no obvious timing leaks remain in the authentication path. Its LLM/AI Security checks can also probe for prompt injection or output leakage if your service incorporates any AI-assisted components. For ongoing safety, integrate the GitHub Action to fail CI/CD builds when a new endpoint drops below your chosen security threshold.