Credential Stuffing in Aspnet with Firestore

Credential stuffing occurs when attackers use lists of previously breached username and password pairs to gain unauthorized access to accounts. In an ASP.NET application that uses Google Cloud Firestore as its user store, several factors can increase exposure. First, if the application does not enforce adequate rate limiting or anomaly detection on authentication endpoints, attackers can submit large volumes of credentials without triggering defensive controls. Second, weak or missing multi-factor authentication (MFA) for user accounts makes automated credential spraying more likely to succeed.

Firestore-specific risks arise from how permissions and data access rules are configured. Overly permissive Firestore security rules may allow unauthenticated or improperly scoped reads and writes to user collections, making it easier for an attacker who has obtained a valid credential pair to read or modify sensitive profile data. Additionally, if the ASP.NET backend exposes user lookup endpoints that return predictable references or metadata (such as document IDs or collection paths), attackers can enumerate valid accounts without needing to know the exact Firestore document ID ahead of time.

Another contributing factor is inconsistent validation of authentication tokens and session cookies. If the application does not rigorously verify identity tokens and relies only on client-supplied identifiers, an attacker may be able to chain a valid credential with a manipulated session context. Because Firestore rules often evaluate request.auth.uid, mismatches between the authenticated UID and the resource being accessed can lead to authorization issues that credential stuffing can exploit to escalate across user boundaries.

Credential stuffing attacks against this stack also risk triggering or bypassing logging and monitoring gaps. If failed authentication attempts are not correlated with user identity or request context, security teams may miss patterns of distributed probes that precede a successful compromise. Attackers may further leverage automation to rotate IPs and user agents, reducing the likelihood of detection by simple threshold-based alarms.

Overall, the combination of ASP.NET application logic, Firestore security rules, and operational visibility shapes the attack surface. Defenses must address not only credential quality and MFA, but also request rate controls, secure token validation, and precise Firestore rules that enforce user-level isolation for every authenticated operation.

Remediation focuses on tightening authentication flows, enforcing strict Firestore rules, and adding runtime protections. Below are concrete code examples for an ASP.NET Core application using the Google Cloud Firestore client library.

1. Secure Firestore Security Rules (Firestore Console or gcloud)

Define rules that enforce user-specific access and avoid broad allow read/writes. These rules assume UID-based document ownership:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    match /other-collection/{docId} {
      allow read: if request.auth != null && isPublicDocument(docId);
      allow write: if request.auth != null && request.auth.uid == request.resource.data.ownerId;
    }
  }
}

function isPublicDocument(docId: string): bool {
  // Implement your own deterministic rule, e.g., prefix-based or allow-listed paths
  return docId.hasPrefix('public/');
}

2. ASP.NET Core Authentication and Firestore Initialization

Ensure the app validates Firebase ID tokens on each request and binds the UID to Firestore operations:

using Google.Apis.Auth.AspNetCore3;
using Google.Cloud.Firestore;
using Microsoft.AspNetCore.Authentication.JwtBearer;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddGoogle(options =>
    {
        options.ClientId = builder.Configuration["Authentication:Google:ClientId"];
    });

FirestoreDb db = FirestoreDb.Create(builder.Configuration["Firestore:ProjectId"]);
builder.Services.AddSingleton(db);

var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();

3. Rate Limiting and Anomaly Detection on Authentication Endpoints

Use ASP.NET Core policies to limit login attempts per identity or IP. Example using a sliding window count stored in Firestore:

public class RateLimitService
{
    private readonly FirestoreDb _db;
    public RateLimitService(FirestoreDb db) => _db = db;

    public async Task AllowRequestAsync(string identifier, int maxRequests, TimeSpan window)
    {
        var docRef = _db.Collection("rate_limits").Document(identifier);
        var snapshot = await docRef.GetSnapshotAsync();
        var now = DateTime.UtcNow;
        var record = snapshot.Exists
            ? snapshot.ConvertTo<RateRecord>()
            : new RateRecord { Count = 0, WindowStart = now };

        if (now - record.WindowStart > window)
        {
            record = new RateRecord { Count = 1, WindowStart = now };
        }
        else
        {
            record.Count += 1;
        }

        if (record.Count > maxRequests) return false;
        await docRef.SetAsync(record);
        return true;
    }
}

public class RateRecord { public int Count; public DateTime WindowStart; }

4. Secure Sign-In Handler with MFA Hinting

Avoid leaking user existence and enforce MFA where applicable. Do not reveal whether an email is registered; perform the same steps regardless:

[HttpPost("login")]
public async Task<IActionResult> Login(LoginModel model)
{
    // Always run the same steps to avoid user enumeration
    var userDoc = await db.Collection("users").WhereEqualTo("email", model.Email).Limit(1).GetSnapshotAsync();
    var user = userDoc.Documents.FirstOrDefault()?.ConvertTo<User>();

    if (user != null && VerifyPassword(model.Password, user.PasswordHash))
    {
        // Enforce MFA if enabled
        if (user.MfaEnabled)
        {
            return Challenge(new AuthenticationProperties { RedirectUri = "/mfa" }, "FirebaseBearer");
        }

        var claims = new List<Claim>
        {
            new Claim(ClaimTypes.NameIdentifier, user.Uid),
            new Claim(ClaimTypes.Name, model.Email)
        };
        var identity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
        await HttpContext.SignInAsync(new ClaimsPrincipal(identity));
        return RedirectToLocal("~/dashboard");
    }

    // Always delay to prevent timing attacks
    await Task.Delay(TimeSpan.FromSeconds(1));
    return Unauthorized();
}

5. Validate and Scope Firestore Reads

When retrieving user data, always reference the authenticated UID rather than trusting client input:

[HttpGet("profile")]
public async Task<ActionResult<Profile>> GetProfile()
{
    var userId = User.FindFirstValue(ClaimTypes.NameIdentifier);
    if (string.IsNullOrEmpty(userId)) return Unauthorized();

    var doc = await db.Collection("users").Document(userId).GetSnapshotAsync();
    if (!doc.Exists) return NotFound();

    return doc.ConvertTo<Profile>();
}

These measures reduce the effectiveness of credential stuffing by limiting enumeration, enforcing strict rules, and ensuring that every Firestore operation is scoped to the authenticated user’s identity.