Credential Stuffing in Aspnet (Csharp)

Credential stuffing is a volume-based attack where attackers use previously breached username and password pairs to gain unauthorized access. In an ASP.NET application written in C#, this becomes a tangible risk when authentication endpoints do not enforce adequate rate limits or anomaly detection. Because ASP.NET often relies on cookie-based session authentication or bearer tokens, a successful automated login attempt can establish a valid session that remains until explicitly revoked.

The C# ecosystem introduces specific factors that can amplify the impact. For example, if the application uses default Anti-Forgery token validation without additional request throttling, automated bots can still perform rapid sequential requests. Developers might implement simple password checks without considering threat signals such as IP reputation, user-agent anomalies, or geographic inconsistency. MiddleBrick includes rate limiting as one of its 12 parallel security checks, which highlights cases where login endpoints accept high request volumes without progressive delays or lockouts.

Moreover, ASP.NET applications that integrate external identity providers (such as OAuth or OpenID Connect) can still be vulnerable if the application layer does not validate state and nonce properly or if session fixation protections are missing. Attackers may couple credential stuffing with client-side script replay or headless browser automation to bypass basic CSRF protections. Because middleBrick tests unauthenticated attack surfaces, it can detect whether login endpoints are susceptible to high-volume requests and whether responses reveal information that aids further automation, such as distinguishable timing differences or verbose error messages.

In practice, a scanner like middleBrick will flag a login endpoint that lacks robust rate limiting or does not enforce progressive delays after failed attempts. The tool also checks whether the application inadvertently discloses whether a username exists, which reduces the effort required for attackers to refine their lists. These findings map to the OWASP API Top 10 category 'Broken Authentication' and can have implications for compliance frameworks such as PCI-DSS and GDPR.

Real-world examples include scenarios where an attacker iterates through millions of credential pairs using a botnet, leveraging weak password policies or credential reuse. If the ASP.NET application does not implement per-account lockouts or captcha challenges after repeated failures, the attack can proceed with minimal friction. MiddleBrick’s parallel checks, including Authentication and Rate Limiting, are designed to surface these weaknesses without requiring credentials or internal architecture insight.

Remediation for credential stuffing in ASP.NET with C# centers on reducing the effectiveness of automated login attempts while preserving legitimate user experience. Key strategies include introducing adaptive rate limits, enforcing account lockouts, adding captcha challenges, and improving logging for suspicious patterns. The following examples illustrate practical implementations that align with these principles.

1. Rate limiting with sliding window policies

Use middleware to restrict the number of login requests per identity or IP within a time window. The example below uses MemoryCache to track attempts and applies a sliding window to avoid burst attacks.

using Microsoft.AspNetCore.RateLimiting;
using System.Threading.RateLimiting;

// In Program.cs or Startup.cs
builder.Services.AddRateLimiter(options =>
{
    options.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>((context) =>
    {
        // Key by username or IP if username is not available
        var username = context.Request.Form["username"];
        var key = string.IsNullOrEmpty(username) ? context.Connection.RemoteIpAddress?.ToString() ?? "unknown" : username.ToString();
        return RateLimitPartition.GetSlidingWindowLimiter(
            key,
            _ => new SlidingWindowRateLimiterOptions
            {
                PermitLimit = 5,
                Window = TimeSpan.FromMinutes(1),
                SegmentsPerWindow = 4,
                QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                QueueLimit = 0
            });
    });
});

app.UseRateLimiter();

2. Account lockout with incremental delays

Track failed attempts per account and introduce increasing delays to slow down automated tools. This example stores counts in MemoryCache and applies exponential backoff.

private const int MaxAttempts = 5;
private static readonly MemoryCache FailedAttempts = MemoryCache.Default;

public IActionResult Login(LoginModel model)
{
    var cacheKey = $"login_fail_{model.Username}";
    var attempts = FailedAttempts.Get(cacheKey) as int? ?? 0;

    if (attempts >= MaxAttempts)
    {
        var delaySeconds = Math.Pow(2, attempts - MaxAttempts);
        return StatusCode(429, $"Too many attempts. Try again in {delaySeconds} seconds.");
    }

    if (!IsValidUser(model.Username, model.Password))
    {
        FailedAttempts.Set(cacheKey, attempts + 1, DateTimeOffset.UtcNow.AddMinutes(15));
        // Avoid revealing whether username exists
        return Unauthorized("Invalid credentials.");
    }

    // Reset on success
    FailedAttempts.Remove(cacheKey);
    // Establish session or token
    return Ok();
}

3. Captcha for suspicious patterns

Integrate a captcha challenge after a threshold of failures or for requests that exhibit bot-like behavior. This example conditionally requires a captcha token before proceeding with authentication.

public IActionResult Login(LoginModel model, string captchaResponse)
{
    var cacheKey = $"login_fail_{model.Username}";
    var attempts = FailedAttempts.Get(cacheKey) as int? ?? 0;

    if (attempts >= 3 && !ValidateCaptcha(captchaResponse))
    {
        return BadRequest("Captcha validation failed.");
    }

    if (!IsValidUser(model.Username, model.Password))
    {
        FailedAttempts.Set(cacheKey, attempts + 1, DateTimeOffset.UtcNow.AddMinutes(15));
        return Unauthorized("Invalid credentials.");
    }

    FailedAttempts.Remove(cacheKey);
    return Ok();
}

private bool ValidateCaptcha(string response)
{
    // Integrate with a captcha provider such as reCAPTCHA
    // Return true if valid, otherwise false
    return !string.IsNullOrEmpty(response) && response == "expected_token";
}

4. Secure logging and monitoring

Log failed attempts with contextual signals such as IP, user-agent, and timestamp to enable detection of coordinated attacks. Avoid logging passwords in clear text.

logger.LogWarning("Failed login attempt for username: {Username}, IP: {IP}, UserAgent: {UserAgent}",
    model.Username,
    HttpContext.Connection.RemoteIpAddress,
    Request.Headers["User-Agent"]);

By combining these C#-specific measures, an ASP.NET application can significantly reduce the success rate of credential stuffing attacks while maintaining compatibility with legitimate traffic. MiddleBrick scans can validate the presence of such controls by checking for rate limiting configurations and observing whether endpoints reveal account existence or lack progressive defenses.