Password Spraying in Aspnet with Bearer Tokens

Password spraying is an authentication attack technique where an adversary uses a small number of common passwords against many user accounts to avoid account lockouts. In ASP.NET applications that rely on bearer token authentication—typically implemented via OAuth 2.0 or OpenID Connect—this attack surface exists at the token issuance endpoint (often /connect/token or a similar login route). Even when tokens are used for subsequent authorization, the initial credential validation step remains vulnerable to spraying if rate limiting and authentication controls are weak.

When an ASP.NET app issues bearer tokens after validating username and password, an attacker can send many requests with a single common password (e.g., Password123) across numerous usernames. If the application does not enforce per-user or per-client rate limits, each request returns a distinct error—such as invalid_grant or invalid_scope—revealing whether a username is valid. This behavior enables the attacker to enumerate valid accounts without triggering account lockout mechanisms that typically protect against password guessing.

The combination of bearer token flows and weak authentication logic also amplifies risks around token binding and replay. For example, if the token endpoint does not adequately validate the client_id or enforce strict origin checks, an attacker may leverage a valid username–password pair obtained via spraying to acquire a bearer token and use it to access protected API resources. Common implementation gaps include missing protections against BOLA (Broken Object Level Authorization) post-authentication and insufficient monitoring of token issuance patterns, which allow low-and-slow spraying campaigns to remain undetected.

OWASP API Top 10 categories such as 2023 – A02: Broken Authentication and A07: Identification and Authentication Failures map closely to these risks. Inadequate rate limiting, verbose error messages, and inconsistent handling of token requests across user accounts create exploitable conditions. Attack patterns like credential stuffing and password spraying often intersect with SSRF or insecure configuration, further expanding the attack surface in environments where token endpoints are exposed without proper guards.

Real-world scanning with tools that perform active authentication testing can detect these weaknesses by analyzing error consistency, timing differences, and token issuance behavior across multiple usernames with a single password. Findings typically highlight the absence of progressive delays, lack of account lockout, and missing multi-factor authentication options where appropriate. Addressing these issues requires a combination of secure coding practices, infrastructure-level protections, and continuous scanning integrated into development and deployment workflows using tools such as the middleBrick CLI or GitHub Action to detect regressions before they reach production.

Securing bearer token endpoints in ASP.NET requires hardened authentication logic, explicit validation, and defense-in-depth measures such as rate limiting and monitoring. Below are concrete remediation strategies with code examples that reduce the risk of password spraying and token misuse.

1. Enforce per-request rate limiting and delay injection

Apply rate limiting at the token endpoint to slow down iterative requests. Use sliding windows and introduce constant-time delays to obscure validation behavior.

// Program.cs or Startup.cs (ASP.NET Core)
builder.Services.AddRateLimiter(options =
{
    GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(_ =
        RateLimitPartition.GetSlidingWindowLimiter(
            partitionKey: context => context.User.Identity?.Name ?? context.Request.Headers["Client-Id"].ToString(),
            factory: _ => new SlidingWindowRateLimiterOptions
            {
                PermitLimit = 5,
                Window = TimeSpan.FromSeconds(30),
                SegmentsPerWindow = 4,
                QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                QueueLimit = 0
            }));
});

app.UseRateLimiter();

2. Standardize error responses to avoid user enumeration

Return the same HTTP status code and generic message for invalid credentials, regardless of whether the username exists.

// In your token controller or middleware
[HttpPost("connect/token")]
public async Task PostToken(TokenRequest request)
{
    var user = await userManager.FindByNameAsync(request.Username);
    if (user == null)
    {
        // Simulate password check to keep timing similar
        await hasher.HashPasswordAsync(null, request.Password);
        return Unauthorized(new { error = "invalid_grant", error_description = "Invalid username or password" });
    }

    var result = await signInManager.CheckPasswordSignInAsync(user, request.Password, false);
    if (!result.Succeeded)
    {
        return Unauthorized(new { error = "invalid_grant", error_description = "Invalid username or password" });
    }

    var token = await tokenService.GenerateBearerToken(user);
    return Ok(new { access_token = token, token_type = "Bearer" });
}

3. Bind tokens to client and audience claims; validate strictly

Ensure issued bearer tokens contain the client_id and aud claims, and validate them on each request to prevent misuse across clients.

// Token generation with explicit claims
var claims = new List<Claim>
{
    new Claim(ClaimTypes.Name, user.UserName),
    new Claim(JwtRegisteredClaimNames.ClientId, clientId),
    new Claim(JwtRegisteredClaimNames.Aud, "api1")
};

var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(config["Jwt:Key"]));
var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);

var token = new JwtSecurityToken(
    issuer: config["Jwt:Issuer"],
    audience: config["Jwt:Audience"],
    claims: claims,
    expires: DateTime.UtcNow.AddMinutes(30),
    signingCredentials: creds);

return new JwtSecurityTokenHandler().WriteToken(token);

4. Apply strict CORS and origin checks on token endpoint

Limit which origins can request tokens to prevent cross-origin misuse and CSRF-related token leakage.

// Program.cs
builder.Services.AddCors(options =>
{
    options.AddPolicy("TokenPolicy", policy =>
    {
        policy.WithOrigins("https://trusted-client.example.com")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});
app.UseCors("TokenPolicy");

5. Monitor and log token issuance anomalies

Log token request metadata without exposing secrets, and integrate alerting for patterns consistent with spraying, such as many token requests for a single password across multiple usernames within a short window.

// Example structured logging in token endpoint
logger.LogInformation("TokenRequest: ClientId={ClientId}, Username={Username}, Status={Status}, IP={IP}",
    clientId, request.Username, result.Succeeded ? "success" : "failure", HttpContext.Connection.RemoteIpAddress);

These steps—combined with scanning using the middleBrick Pro plan for continuous monitoring and the GitHub Action for CI/CD integration—help ensure that bearer token flows remain resilient against password spraying and related authentication abuse.