best practices for preventing garbage account creation?

[34code]

Hi,

My controllers are rate limited by rack-attack so thankfully its not as big of a problem as it can be. I'm being targeted by garbage account creation bots, and they pollute my db constantly.

I'm rate limiting by ip via the rack-attack gem

Rack::Attack.throttle("login_ip", limit: 2, period: 60) { |req|
  req.ip if req.path == "/verify-account-resend"
}

# Throttle signups per ip (2 rpm)
Rack::Attack.throttle("login_ip", limit: 2, period: 600) { |req|
  req.ip if req.post? && req.path == "/create-account"
}
# Throttle signups per email param (regardless of ip)
Rack::Attack.throttle("login_email", limit: 2, period: 600) { |req|
  req.params["email"].presence if req.post? && req.path == "/create-account"
}
# Throttle logins per ip (4 rpm)
Rack::Attack.throttle("login_ip_post", limit: 4, period: 60) { |req|
  req.ip if req.post? && req.path == "/login"
}
Rack::Attack.throttle("login_ip_get", limit: 4, period: 60) { |req|
  req.ip if req.path == "/login"
}
# Throttle logins per email param (regardless of ip) (4 rpm)
Rack::Attack.throttle("login_email", limit: 4, period: 60) { |req|
  req.params["email"].presence if req.post? && req.path == "/login"
}

I've disabled sending a welcome email (until a deposit) also enabled recaptcha but somehow the spammers are still getting through.

# rodath_main.rb

    before_create_account do
      throw_error_status(422, "Full Name", "must be present") if param("name").empty?
      throw_error_status(422, "Age", "must be present") if param("age").empty?
      throw_error_status(422, "Captcha", "must be completed") if param("g-recaptcha-response-data").empty?
      throw_error_status(422, "Address Line 1", "must be completed") if param("address_line_1 address-search").empty?
      # throw_error_status(422, "Postal Code", "must be completed") if param("address_postal_code").empty?
      throw_error_status(422, "Age", "must be greater than 0") if param("age") == 0
    end

I wanted to know what the best practices are to prevent such account creation garbage coming into my db?

[janko]

If there is a deposit for account verification, I assume spammers are managing to only create unverified accounts?

Are they using real email addresses? The Truemail gem can be used to determine whether the email address actually exists and even if it's likely a spam email. You could hook it up as follows:

class RodauthMain < Rodauth::Rails::Auth
  configure do
    login_meets_requirements? do |email|
      super(email) && truemail?(email)
    end
  end

  private

  def truemail?(email)
    return true if Truemail.valid?(email)
    set_login_requirement_error_message(:fake_email, "doesn't appear to be real email address")
    false
  end
end

Also, is Rack::Attack definitely sitting in front of Rodauth::Rails::Middleware? Do you see it taking effect on Rodauth endpoints?

[janko]

maybe you are correct in that it may not be sitting in front of the Rodauth::Rails::Middleware

You can easily check this in the rails middleware output 😉

[34code]

use ActionDispatch::HostAuthorization
use Rack::Sendfile
use ActionDispatch::Static
use ActionDispatch::Executor
use ActionDispatch::ServerTiming
use ActiveSupport::Cache::Strategy::LocalCache::Middleware
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use RequestStore::Middleware
use ActionDispatch::RemoteIp
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use Sentry::Rails::CaptureExceptions
use WebConsole::Middleware
use ActionDispatch::DebugExceptions
use BetterErrors::Middleware
use Sentry::Rails::RescuedExceptionInterceptor
use ActionDispatch::ActionableExceptions
use ActionDispatch::Reloader
use ActionDispatch::Callbacks
use ActiveRecord::Migration::CheckPending
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use ActionDispatch::ContentSecurityPolicy::Middleware
use ActionDispatch::PermissionsPolicy::Middleware
use Rack::Head
use Rack::ConditionalGet
use Rack::ETag
use Rack::TempfileReaper
use Rack::Static
use OmniAuth::Builder
use Rodauth::Rails::Middleware
use Rack::Attack
use ActionDispatch::Static
run Botflip::Application.routes

Rack::Attack is there but its below Rodath::Rails::Middleware.. does ordering matter?

[janko]

Yes, it does. If Rack::Attack comes after Rodauth::Rails::Middleware, then requests to Rodauth routes will be processed without throttling. The way it works is:

1. incoming request (e.g. to POST /create-account) travels down the middleware stack
2. Rodauth::Rails:Middleware calls RodauthApp's route block with the request
   • if the request is not a Rodauth route, r.rodauth exits and request is forwarded further down the middleware stack
   • if the request is a Rodauth route, r.rodauth renders the response immediately, so downstream middleware isn't called

It should be enough to add this line to your config/application.rb:

config.middleware.insert_before Rack::Attack, Rodauth::Rails::Middleware

Afterwards please re-check the rails middleware output to confirm that none of the middlewares got added twice. If they did, you can disable rodauth-rails' automatic middleware insertion and add it manually:

# config/initializers/rodauth.rb

Rodauth::Rails.configure do |config|
  config.app = "RodauthApp"
  config.middleware = false
end

Rails.application.config.middleware.insert_after Rack::Attack, Rodauth::Rails::Middleware

[34code]

hmm strange, both approaches are complaining that rack attack is not a valid middleware..

/Users/sambit/.gem/ruby/3.2.3/gems/actionpack-8.0.0/lib/action_dispatch/middleware/stack.rb:180:in `assert_index': No such middleware to insert before: Rack::Attack (RuntimeError)

/Users/sambit/.gem/ruby/3.2.3/gems/actionpack-8.0.0/lib/action_dispatch/middleware/stack.rb:180:in `assert_index': No such middleware to insert after: Rack::Attack (RuntimeError)

Thanks for your help on this!

[34code]

I'm dumb.. after much conversation with Claude I figured out the order in the gemfile matters! Just put the rack-attack gem above rodauth-rails and its all good now.

[34code]

They seem to be using real emails for now..

[34code]

Hi @oyenmwen were you able to integrate this (invisible_captcha) with rodauth? If so, what controller actions did you set up to protect? I'm curious about all the controller actions available to me under RodauthController.. not seeing any docs re: this so far..

[34code]

I know ":login" is one .. wondering what is the equivalent for others like "create account", "edit account" etc..

[janko]

The Rodauth action names match the route helpers:

• login_path => :login
• create_account_path => :create_account
• verify_account_path => :verify_account
• ...

Current route was added here (and then here), not sure where/how to document it. You can see it in the controller action request logging, e.g. RodauthController#verify_account.

[janko]

I've included the route name in the output of the rodauth:routes rake task:

                   login  GET|POST  /login                   rodauth.login_path
          create_account  GET|POST  /create-account          rodauth.create_account_path
                  logout  GET|POST  /logout                  rodauth.logout_path
  reset_password_request  GET|POST  /reset-password-request  rodauth.reset_password_request_path
          reset_password  GET|POST  /reset-password          rodauth.reset_password_path
         change_password  GET|POST  /change-password         rodauth.change_password_path
            change_login  GET|POST  /change-login            rodauth.change_login_path
     verify_login_change  GET|POST  /verify-login-change     rodauth.verify_login_change_path
           close_account  GET|POST  /close-account           rodauth.close_account_path
   verify_account_resend  GET|POST  /verify-account-resend   rodauth.verify_account_resend_path
          verify_account  GET|POST  /verify-account          rodauth.verify_account_path

I've also mentioned the route name in route descriptions in rodauth-openapi, see https://github.com/janko/rodauth-openapi/releases/tag/v0.2.0.

I hope that helps 🙂

[34code]

Thanks @janko, great support and thanks for building this amazing library