Password Spraying in Aspnet with Firestore

Password spraying is an attack technique where a single password is tried against many accounts. In an ASP.NET application that uses Google Cloud Firestore as its user store, this pattern can be subtly enabled by application design choices and Firestore query behavior. Unlike credential stuffing, which relies on reused passwords across sites, password spraying tests common passwords such as Password123 or Company2024! across a list of known usernames or email addresses.

In ASP.NET, authentication logic that retrieves users by email or username from Firestore can inadvertently facilitate spraying if it reveals whether an account exists before checking rate limits or lockout policies. A typical vulnerable flow is: the endpoint accepts an email, queries Firestore for a matching document, and then performs a password comparison only if the document exists. An attacker can observe timing differences or response messages to enumerate valid accounts. Firestore queries are fast and return consistent latencies for missing documents when using indexed fields, but subtle differences between a document miss and a password check failure can leak information.

The combination of ASP.NET’s model binding and Firestore’s document-based model can also encourage storing minimal user metadata directly in documents, such as password hashes and last login timestamps. Without server-side rate limiting or account lockout implemented in the business logic, an attacker can perform thousands of password attempts across many accounts within a short window. Firestore security rules do not enforce authentication-rate controls; they focus on read/write permissions. Therefore, the application must implement rate limiting and progressive delays on the server side to mitigate spraying.

Attackers may also probe unauthenticated endpoints that return user profile data from Firestore. If these endpoints do not validate the requesting user’s identity correctly, an attacker can enumerate usernames and infer account existence before password spraying even begins. In ASP.NET, this can occur when route parameters map directly to Firestore document IDs without verifying ownership or access rights. The scanner’s authentication checks and BOLA/IDOR tests are designed to detect these authorization gaps by comparing unauthenticated responses to authenticated baselines.

Real-world attack patterns include using common passwords from public lists and distributing attempts across many IP addresses to evade simple IP-based thresholds. The scanner’s rate limiting check flags missing or weak controls, while the input validation check ensures that email and username inputs are sanitized before constructing Firestore queries to prevent injection or malformed document lookups. Because Firestore indexes document fields used in queries, ensure that security-sensitive fields such as password hashes are never indexed in a way that assists enumeration.

Finally, the LLM/AI Security checks offered by middleBrick are unique in detecting prompt injection attempts against any AI components that might interface with Firestore-backed user data. These probes test system prompt leakage, jailbreak techniques, and output scanning for sensitive data. For purely API security posture scoring, the tool evaluates the authentication mechanisms, rate limiting, and input validation that intersect with Firestore usage in ASP.NET applications.

Remediation focuses on making password verification timing consistent, enforcing rate limits, and ensuring Firestore queries do not expose account existence. Below are concrete examples using the Google Cloud Firestore client for ASP.NET-compatible environments.

Consistent timing and secure password checking

Use a hashed comparison that always takes the same amount of time regardless of whether the user exists. Retrieve a dummy hash when the user is not found to avoid early exits.

using Google.Cloud.Firestore;
using System.Security.Cryptography;
using System.Threading.Tasks;

public class UserService
{
    private readonly FirestoreDb _db;
    private const string DummyHash = "$2a$11$DummyHashForTimingConsistencyRegardlessOfInputLength123456";

    public UserService()
    {
        _db = FirestoreDb.Create("your-project-id");
    }

    public async Task<bool> ValidatePasswordAsync(string email, string providedPassword)
    {
        DocumentReference docRef = _db.Collection("users").Document(email);
        DocumentSnapshot snapshot = await docRef.GetSnapshotAsync();
        string storedHash = DummyHash; // default to dummy to keep timing consistent

        if (snapshot.Exists && snapshot.TryGetValue("password_hash", out string hash))
        {
            storedHash = hash;
        }

        bool isValid = VerifyHashedPassword(providedPassword, storedHash);
        // Always perform a dummy iteration to mask timing differences
        using (var hmac = new HMACSHA256())
        {
            byte[] dummy = hmac.ComputeHash(System.Text.Encoding.UTF8.GetBytes(DummyHash));
        }
        return isValid;
    }

    private bool VerifyHashedPassword(string password, string storedHash)
    {
        // Use a constant-time comparer or a well-vetted library such as BCrypt.Net-Next
        return BCrypt.Net.BCrypt.Verify(password, storedHash);
    }
}

Rate limiting and lockout logic

Track attempts per user or per IP address in a separate collection with TTL to avoid unbounded growth. Enforce delays and lockouts before checking the password hash.

using Google.Cloud.Firestore;
using System;
using System.Threading.Tasks;

public class RateLimitService
{
    private readonly FirestoreDb _db;

    public RateLimitService()
    {
        _db = FirestoreDb.Create("your-project-id");
    }

    public async Task<bool> CanAttemptAsync(string key, int maxAttempts = 5, int windowSeconds = 60)
    {
        DocumentReference ref = _db.Collection("rate_limits").Document(key);
        DocumentSnapshot snap = await ref.GetSnapshotAsync();
        var now = DateTime.UtcNow;

        if (!snap.Exists)
        {
            await ref.SetAsync(new { Count = 1, FirstSeen = now, Expiry = now.AddSeconds(windowSeconds) });
            return true;
        }

        dynamic data = snap.ConvertTo<object>();
        int count = data.count;
        DateTime firstSeen = data.first_seen;
        DateTime expiry = data.expiry;

        if (now > expiry)
        {
            await ref.SetAsync(new { Count = 1, FirstSeen = now, Expiry = now.AddSeconds(windowSeconds) });
            return true;
        }

        if (count >= maxAttempts)
        {
            return false;
        }

        await ref.UpdateAsync("count", count + 1);
        return true;
    }
}

Safe Firestore queries and input validation

Validate and normalize email inputs before using them as document IDs or query values. Avoid direct concatenation into query strings and use parameterized collection/document references.

using Google.Cloud.Firestore;
using System;
using System.Threading.Tasks;

public class UserRepository
{
    private readonly CollectionReference _users;

    public UserRepository()
    {
        FirestoreDb db = FirestoreDb.Create("your-project-id");
        _users = db.Collection("users");
    }

    public async Task<DocumentSnapshot> FindByEmailAsync(string email)
    {
        // Normalize and validate before using
        if (!System.Text.RegularExpressions.Regex.IsMatch(email, @"^[^\s@]+@[^\s@]+\.[^\s@]+$"))
        {
            throw new ArgumentException("Invalid email format");
        }

        // Use document reference directly; avoid raw queries that may expose enumeration
        DocumentReference doc = _users.Document(email.Trim().ToLowerInvariant());
        return await doc.GetSnapshotAsync();
    }
}

For applications using middleBrick, the CLI can be integrated into scripts to scan endpoints and verify that authentication and rate limiting findings are addressed. The GitHub Action can enforce a maximum risk score threshold before merges, while the MCP Server allows scanning APIs directly from AI coding assistants to catch insecure patterns early in development.