Skip to main content

Brute-force protection

Brute-force protection​

Last verified: 2026-07-08.

Awthy watches for repeated failed sign-in attempts and quietly slows them down, so someone guessing passwords gets nowhere while a real person who mistyped their password barely notices. The protection and its email alerts are free.

How it responds​

Awthy counts failed sign-ins and answers a flood of them in two ways:

  • Progressive delay (soft friction) — the default. Each failed attempt against an account adds a small, growing delay before the next try is allowed. The first slip costs almost nothing; a machine hammering away is slowed to a crawl. A real person who fixes their password is let straight through.
  • Hard temporary lock (optional) — a conservative cap that, for an egregious burst of failures, blocks further attempts for a short, fixed period. This is off or set high by default so it only ever catches an obvious attack, not a forgetful user.

The progressive delay does the everyday work. The hard lock is there for extreme cases and stays out of the way the rest of the time.

Per-account and per-source counting​

Awthy counts failures from two angles at once:

  • Per account — too many failures against a single account slow down attempts on that account, so one targeted user is protected.
  • Per source IP — too many failures coming from one address slow down that address, even when an attacker spreads guesses across many usernames.

Counting both ways means an attacker cannot slip past by switching usernames, and a single fat-fingered password on one account does not slow anyone else down.

Recovery is never throttled by your network​

The per-source-IP slow-down only applies to attempts to guess a sign-in — passwords and second-factor codes. It deliberately does not apply when a locked-out owner asks Awthy to email them a recovery link.

That carve-out matters for real people on shared connections. On a busy office, school, or mobile-carrier network, many users can share one public IP address. If that address has built up a slow-down from someone else's failed logins — or from your own mistyped codes — you can still email yourself a recovery link and get back in. The recovery email only ever goes to the address already on file for the account, so it cannot be brute-forced; the network slow-down would add no security there, only the risk of locking a genuine owner out of their safe way back in. Recovery emails are still paced by their own per-account limit so the feature cannot be used to flood an inbox.

Alerts you receive​

When the failure count crosses the threshold, Awthy sends a free email alert:

  • The affected user is told that someone has been failing to sign in to their account, so they know to check their password and recovery options.
  • Administrators are told when an account or a source IP crosses the threshold, so a site-wide attack is something they notice early.

An Awthy alert will never ask for your password or a one-time code, and never contains them. If a message claiming to be from Awthy asks for credentials, treat it as phishing.

Default thresholds​

Out of the box, Awthy raises an alert after 5 failed attempts in 15 minutes, counted both per account and per source IP. The progressive delay starts building before that point, so attempts are already being slowed by the time an alert goes out. Administrators can tune the threshold and the optional hard lock under Awthy Security → Login activity.

Brute Force Activity screen​

The Brute Force Activity screen shows recent throttled sign-in attempts and the policy state that produced them. Use it to confirm whether Awthy is slowing account-specific attempts, source-IP attempts, or both.

The screen is for operational triage. It should not be treated as a full forensic export, and support workflows should avoid copying raw IP addresses or full user-agent strings into tickets.

Relationship to other controls​

Brute-force protection works well with:

The last administrator can never be locked out​

This is a firm guarantee: Awthy will never apply a hard temporary lock to the last remaining administrator of your site.

It protects you from two directions at once:

  • An attacker cannot deliberately fail logins to lock the owner out and seize control of the site.
  • A mistyped password cannot accidentally lock you out of your own site.

The progressive delay may still gently slow repeated failures on an admin account, but the door is never bolted shut on the one person who can open it. You will always be able to get back in.

Last updated on