Credential Stuffing in Rails with Dynamodb

Credential stuffing occurs when attackers use automated requests to test breached username and password pairs against a login endpoint. In a Ruby on Rails application that stores user data in Amazon DynamoDB, several implementation choices can increase exposure. Rails controllers that perform lookup by an identifier such as email without enforcing rate limits or strong authentication create conditions where DynamoDB queries become an implicit rate-limiting surface. If the application queries DynamoDB with a simple GetItem or Query using a partition key like email = ?, each request generates a distinct DynamoDB read operation. Attackers can send many requests per second from distributed IPs, and because the requests are unauthenticated API calls, they may not trigger application-level locks quickly. DynamoDB Streams and auto scaling can mask abusive patterns, making it harder to correlate spikes with credential stuffing. Rails default behavior of rendering detailed error messages (e.g., “email not found” vs “password incorrect”) enables username enumeration, which aids attackers in refining lists. Without additional controls, the combination of a permissive authentication flow, per-request DynamoDB reads, and weak rate limiting can amplify the risk of account takeover.

To reduce credential stuffing risk while using DynamoDB as the user store in Rails, implement layered controls: rate limiting, secure comparison, and defensive logging. Use DynamoDB conditional writes and update expressions to enforce atomic counters for failed attempts without relying on external caching. The following examples assume an accounts table with a partition key email and attributes password_hash, failed_attempts, and locked_until.

Secure authentication check with conditional update

require 'aws-sdk-dynamodb'

class AuthenticateUser
  def initialize(dynamodb_client = Aws::DynamoDB::Client.new)
    @ddb = dynamodb_client
    @table = 'accounts'
  end

  def call(email, password_attempt)
    # Consistent-time comparison to avoid timing leaks
    stored = fetch_account(email)
    return { error: 'Invalid credentials' } unless stored

    # Constant-time password verification (e.g., bcrypt)
    if BCrypt::Password.new(stored['password_hash']) == password_attempt
      reset_failed_attempts(email) if stored['failed_attempts'].to_i > 0
      { success: true }
    else
      record_failure(email)
      { error: 'Invalid credentials' }
    end
  end

  private

  def fetch_account(email)
    resp = @ddb.get_item(
      table_name: @table,
      key: { 'email' => { s: email } },
      consistent_read: true
    )
    resp.item
  end

  def reset_failed_attempts(email)
    @ddb.update_item(
      table_name: @table,
      key: { 'email' => { s: email } },
      update_expression: 'SET failed_attempts = :zero, locked_until = :null',
      expression_attribute_values: {
        ':zero' => { n: '0' },
        ':null' => { null: true }
      }
    )
  end

  def record_failure(email)
    # Conditional update: increment only if not already locked
    @ddb.update_item(
      table_name: @table,
      key: { 'email' => { s: email } },
      update_expression: 'ADD failed_attempts :inc',
      condition_expression: 'attribute_not_exists(locked_until) OR locked_until <= :now',
      expression_attribute_values: {
        ':inc' => { n: '1' },
        ':now' => { n: Time.now.utc.strftime('%s') }
      },
      return_values_on_condition_check_failure: 'ALL_OLD'
    )
  rescue Aws::DynamoDB::Errors::ConditionalCheckFailedException
    # Locked state, no further increment
    nil
  end
end

Rate limiting and lockout using DynamoDB with TTL

Create a separate login_attempts table keyed by a composite identifier (e.g., IP + email hash) with an expiration attribute to automatically evict old entries. This avoids long-lived lock tables and leverages DynamoDB TTL.

class RateLimitCheck
  def initialize(ddb_client = Aws::DynamoDB::Client.new)
    @ddb = ddb_client
    @table = 'login_attempts'
  end

  def allowed?(key, max_attempts = 5, window_seconds = 60)
    now = Time.now.utc
    @ddb.put_item(
      table_name: @table,
      item: {
        'attempt_key' => { s: key },
        'count' => { n: '1' },
        'expires_at' => { n: (now.to_i + window_seconds).to_s }
      },
      condition_expression: 'attribute_not_exists(attempt_key) OR count < :max',
      expression_attribute_values: { ':max' => { n: max_attempts.to_s } },
      return_values_on_condition_check_failure: 'ALL_OLD'
    )
    true
  rescue Aws::DynamoDB::Errors::ConditionalCheckFailedException
    false
  end
end

In your Rails controller, combine both checks before issuing a password comparison call. This ensures that DynamoDB read and write costs remain bounded and that attackers cannot bypass application-level throttling by cycling credentials. Complement these technical measures with protections against user enumeration by returning uniform error messages and enforcing MFA for high-risk sign-in contexts.