Attack protection

Authio watches every password sign-in, every password recovery request and every sign-in request sent to a phone for the shapes attacks leave, and answers them by itself. Each answer is aimed at the attacker, never at the person attacked, and is recorded on an incident you read in Attack protection.

There is nothing to switch on or tune. The engine runs in every realm with the same thresholds, and what is left for a person is to confirm what happened, lift a measure that caught legitimate traffic, and decide whether the realm should be stricter.

How it works

Each failed password, each request refused on a phone and each recovery request is counted per source address and per account, never per realm: a realm’s traffic swings with the hour and the season, but one address trying eight accounts in ten minutes does not happen by accident. When a count crosses a threshold, the platform takes a measure at once and records it on the realm’s incident for that kind of attack.

• Aimed at the attack, never at the owner. A source is blocked, an account refuses addresses it was never approved at, a phone stops receiving requests. The person under attack keeps signing in from where they always do, so an attacker cannot lock somebody out of their own account.
• Every measure lapses by itself. Blocks and pauses run for a set time and end on their own, and you can lift one earlier. Only a password treated as exposed does not lapse: it has to be changed.
• Datacenters and Tor exits are held to half the threshold. People rarely sign in from either; scripts nearly always do. The halving is recorded among the reasons of the measure.
• It never stops sign-in because of its own failure. The engine counts in a shared cache, and when that cache cannot be read the attempt goes on as if the protection were not there.

What it detects

Every incident is one of five kinds of attack, and the kind is its title on the list. A blocked source is classified by what it was doing; the phone and recovery detections have kinds of their own.

A correct password arriving from an attack is not a sixth kind. It is recorded as Password exposed on the incident of the attack that carried it, credential stuffing or password spraying, and turns that incident critical.

When it acts, and for how long

These rules are the platform’s, the same in every realm, and cannot be changed per realm or per account. Each measure names the factors that set it off, so a blocked office can be explained rather than guessed at.

Shared networks

An address that 5 or more accounts of the realm have approved is read as an office or a campus. It is never blocked whole, and a correct password from it is never treated as exposed. Its accounts still lock against strangers one by one.

What a blocked source sees

A blocked source is refused before any account is looked up, with the same answer as a rate limit (TooManyRequests): wait a few minutes and try again. The answer is the same whatever name was typed and says nothing about the password, so a person caught behind a blocked address is not told their password is wrong.

The realm’s own lockout

The realm’s Max Failed Attempts and Lockout Duration (Security policies) keep applying beside the engine, with one difference: a failure from an address the account was never approved at counts against that address alone, never against the account. After the realm’s number of such failures within an hour, that address is locked out of the account for the realm’s duration, while the addresses the account was approved at follow the ordinary lockout. This lock opens no incident.

Incidents

Detections of the same kind against one realm join a single incident as long as each arrives within 30 minutes of the last, so an attack spread over three hundred addresses reads as one incident with three hundred blocked sources. Each incident names its realm and the client its first detection came through.

Severity

An incident keeps the highest severity it reached.

Statuses

Measures

Each measure also says what it is aimed at and why: the factors counted, such as failures, different accounts, the share of unknown accounts, a datacenter network or Tor exit, requests refused on the phone or a correct password. It reads In force, lapses … while it holds, Lapsed once its time ran out, Lifted … when somebody lifted it, and Change required for an exposed password.

The attacks screen

Attack protection reads the realm chosen in the realm selector, or every realm you administer under All realms, and a client filter narrows all of it to what came through one client. It has nothing to configure.

Reading an incident

Clicking an incident opens it beside the list:

• What that kind of attack is.
• Refused attempts, Blocked sources, Protected accounts and Exposed passwords: the attempts its measures refused, the sources it blocked, the accounts it put a measure on and the accounts whose correct password arrived from it.
• Started, Last activity, Closed and Detections: when it was first detected, when it last had a detection or a refused attempt, when it closed and how many detections joined it.
• The AI analyst’s reading, when your account has one.
• Measures taken, each with its reasons and its standing, and Lift on those still in force.

The Dashboard shows the same protection over the last 30 days in its Attack protection block, with Open attack protection. On a person’s page in Users, Password exposed in an attack stays visible while their current password is still the one an attack proved.

Lift a measure or dismiss an incident

Both actions need permission to update realms (realm:update); without it the screen is read-only. There is no manual block: every measure is one the platform took.

Every lift and dismissal is recorded in the change trail as an update, under the name of whoever did it.

The AI analyst

When your plan includes the AI advisor and the realm gave it consent, an AI analyst reads each incident and writes what it makes of it in the incident’s side panel. It reads the incident’s figures only, without addresses or names, and never sits in the path of a sign-in: the engine decides as the attempt arrives, the analyst reads afterwards, and an analyst that is slow or down changes nothing about who gets in.

To turn it on, open the realm in Realms, choose AI advisor and switch on Let the AI advisor analyse this realm; see Authio AI. Without the plan or the consent, the side panel simply shows no analysis. Consent is checked again when each reading runs.

When it reads

Readings are scheduled every 5 minutes, each of the three at most once per incident, and an account gets at most 12 readings per UTC day, so an attacker cannot run up a bill by opening incidents. Earlier readings fold under the latest. A reading that failed can be asked for again with Try again.

What a reading says

• Classification: one of the five kinds of attack, Legitimate surge, Misconfiguration or Inconclusive, with its confidence.
• What happened, What was done and Exposed passwords.
• Recommended changes for the realm.
• In the closing reading, the Post-incident report.

Recommended changes

A reading carries up to three changes, and each can only make the realm stricter. Each shows the change, the realm’s current value and what your users will notice. They change the realm’s own account rules:

• Apply asks for confirmation and changes the realm for every application that signs in through it. Whether the change still tightens the realm is checked again at that moment; one the realm already meets reads Already in place.
• Undo puts the previous value back from the same incident, as long as the realm still holds the value that was applied. A change somebody made since is left alone.
• Applying and undoing are recorded in the change trail, like any change to the realm.

Post-incident report

The closing reading adds a report shaped after what Brazil’s data protection authority (ANPD) asks of a security incident communication (Resolução CD/ANPD nº 15/2024): Nature of the incident, Data and people affected, Risks, Measures and Communication. Copy report puts it on the clipboard with the incident’s dates and counts.

Notifications and webhooks

The platform tells the account’s operators, the realm’s webhooks and the person whose password was exposed, without anyone opening the screen.

• In Preferences, the account owner decides whether Attacks detected also goes out by e-mail and by webhook, or is not raised at all. See Notifications.
• The same account is reported at most once an hour. A list replayed against the realm is still refused every time, but the incident, the notification, the webhook and the e-mail are not repeated.
• Only realm endpoints receive the attack events. What each one carries is in Webhooks.

Read and act from the Admin API

Incidents are in the Admin API, called with an API secret in the x-api-key header. Paths are relative to /api/v1/admin, and lists are paginated with pageNumber and pageSize.

curl 'https://authio.api.hyperio.tech/api/v1/admin/threat-incidents?incidentStatus=Active&pageNumber=1&pageSize=20' \
  -H "x-api-key: $AUTHIO_API_KEY"

Respond to an incident

By the time you look, the platform has already acted. Your part is to confirm what it was, deal with exposed passwords, and decide whether the realm should be stricter.

1. 1

   Read what it was

   Open the incident in Attack protection and read its kind and description: is it an attack, or traffic of your own?

2. 2

   Read the measures

   Under Measures taken, see which sources are blocked and why, and whether any Password exposed appears.

3. 3

   Deal with exposed passwords

   Each owner has already been asked to change the password, but sessions they had open stay open until they are ended. If the account could have been used meanwhile, end its sessions in Sessions.

4. 4

   Trace the source

   Open Audit › Access and search for the blocked address to read every attempt it made, successful ones included.

5. 5

   Decide

   If it was legitimate traffic, choose Dismiss as not an attack. If it was real, read the AI analyst’s recommendations and apply the ones that fit.

6. 6

   Keep the record

   Once the incident closes, copy the post-incident report if you need to communicate it.

Permissions

With the account roles, an Auditor reads everything here but cannot act; a Developer, Admin or Owner can also act.

Next steps