Password Spraying in Chi with Basic Auth

Chi is a lightweight HTTP framework for .NET that enables minimal APIs and endpoint definitions. When Basic Authentication is used in Chi, credentials are transmitted in the Authorization header as base64(user:password). Although base64 is not encryption, the risk in Chi emerges when the application processes many authentication attempts against a single account or a list of common credentials across multiple accounts. Password spraying in this context involves iterating over a list of passwords for each discovered user, or iterating over a small list of common passwords across many accounts, to avoid account lockout while still finding valid credentials.

If a Chi endpoint performs authentication synchronously and does not enforce rate limiting or account lockout, an attacker can send many requests in a short time. Because middleBrick tests authentication and rate limiting as part of its 12 parallel security checks, it can identify whether a Chi service is vulnerable to password spraying via Basic Auth. Without additional protections, each request returns 401 until the correct password is found, giving an attacker observable feedback that confirms valid accounts and successful authentication without triggering defenses.

For example, an endpoint defined in Chi might look like this, using Basic Auth for a single route:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAuthentication("Basic")
    .AddScheme("Basic", null);
var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.MapGet("/secure", (HttpContext context) => Results.Ok("Authenticated"))
    .RequireAuthorization();
app.Run();

If the BasicHandler validates credentials against a user store without throttling, an attacker can run a password spraying attack by iterating over passwords for a known set of usernames. middleBrick’s Authentication check would flag this as a finding, noting the lack of rate limiting and the presence of Basic Auth over TLS, which is necessary but insufficient on its own. The scan also checks for data exposure and encryption, ensuring credentials are not leaked in logs or error responses.

In environments where Chi services are exposed publicly, password spraying via Basic Auth becomes a practical threat because attackers can enumerate valid accounts through repeated 401 responses. The combination of predictable endpoints, weak password policies, and missing per-account rate limiting amplifies the risk. middleBrick’s checks for Authentication, Rate Limiting, and Data Exposure work together to surface these weaknesses, providing prioritized findings and remediation guidance rather than attempting to block or fix the service.

To mitigate password spraying in Chi when using Basic Auth, apply layered controls around authentication logic and infrastructure. The most effective remediation combines protocol-level protections, application-side rate limiting, and secure credential handling. Below are concrete code examples that you can adapt in a Chi application.

1. Enforce TLS and reject non-TLS requests.

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps();
    });
});
var app = builder.Build();
app.UseHttpsRedirection();

2. Implement per-user or per-IP rate limiting using middleware or a distributed cache. This example uses a simple in-memory sliding window; in production, use a robust store such as Redis.

builder.Services.AddRateLimiter(options =>
{
    options.GlobalLimiter = PartitionedRateLimiter.Create(context =>
    {
        var username = context.User.Identity?.Name ?? context.Request.Headers["X-Forwarded-User"];
        return RateLimitPartition.GetSlidingWindowLimiter(
            partitionKey: username ?? context.Connection.RemoteIpAddress?.ToString(),
            factory: _ => new SlidingWindowRateLimiterOptions
            {
                PermitLimit = 5,
                Window = TimeSpan.FromMinutes(1),
                SegmentsPerWindow = 4,
                QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                QueueLimit = 0
            });
    });
});
app.UseRateLimiter();

3. Avoid returning distinct messages for invalid users. Standardize 401 responses so that an attacker cannot enumerate valid accounts. Combine this with secure password hashing for credential validation.

app.UseAuthentication();
app.UseAuthorization();
app.MapPost("/login", (HttpContext context) =>
{
    var authHeader = context.Request.Headers.Authorization;
    if (authHeader?.StartsWith("Basic ") != true)
    {
        context.Response.StatusCode = 401;
        return Results.Json(new { error = "Unauthorized" });
    }
    var credentialBytes = Convert.FromBase64String(authHeader.Substring("Basic ".Length));
    var credentials = Encoding.UTF8.GetString(credentialBytes).Split(':', 2);
    var username = credentials[0];
    var password = credentials[1];
    // Validate username and hashed password using a constant-time comparison
    if (!CheckUserPassword(username, password)) // implement secure check
    {
        context.Response.StatusCode = 401;
        return Results.Json(new { error = "Unauthorized" });
    }
    // Issue token or session as appropriate
    return Results.Ok(new { token = GenerateToken(username) });
});

4. Complement application controls with infrastructure protections such as API gateways or load balancers that enforce global rate limits and IP reputation checks. This reduces the load on the Chi app and provides an additional layer against automated spraying.

middleBrick’s CLI can be used to verify that these changes reduce risk by rescoring the endpoint. For teams managing many services, the Pro plan’s continuous monitoring and GitHub Action integration can prevent regressions by failing builds when authentication or rate-limiting configurations weaken.