Failed sign-in lockout

A password is only as strong as the number of guesses an attacker is allowed. Querona refuses a login that has failed repeatedly, so that a short password cannot be found by an online guessing run however it is stored.

No configuration is involved, and nothing has to be enabled.

How it works

Rule	Value
Consecutive failures before a lockout	3
First lockout	1 minute
Each further lockout in a row	Twice the previous one
Longest a lockout can last	15 minutes
Failures below the threshold expire after	15 minutes without another attempt

A successful sign-in clears the count. Someone who mistypes a password waits a minute; a sustained guessing run becomes slower with each round until it reaches the cap.

Attempts for the same login and origin that present different passwords are handled one at a time, so a burst of guesses cannot pass the three-failure threshold before the lockout takes effect. Attempts arriving together with the same password are one guess: they are handled together and counted once, which is what keeps an application opening a pool of connections from waiting through one password check after another. Attempts for other login-and-origin pairs remain independent.

The lockout is capped deliberately. One that grew without limit would become a denial of service against the very account it protects, and fifteen minutes is already slow enough to make a sustained run impractical.

What is counted, and why it matters

Failures are counted per login and origin, never per login alone.

Counting per login would let any anonymous caller lock a real account out simply by guessing at its name — turning the protection into the attack it is meant to prevent. Because the origin is part of the count, a user signing in from their own workstation is unaffected by someone failing against the same account from somewhere else.

An authentication Querona performs for itself, rather than for a caller that reached it over the network, is counted separately again, so internal activity and client traffic never share a counter.

The same protection covers password sign-in through the API, including its Windows-account fallback, and the administrator credentials accepted while the Engine is in maintenance mode. A native-password failure followed by a Windows-password check is one attempt, not two.

It also covers the two places where a signed-in user proves their own password again: changing it from the profile, and the password step before setting up an authenticator. A wrong password there counts as a failure for that login and the address the request came from, and a login that is locked out is refused before its password is checked. For a login that signs in with an authenticator code, the proof is the code and the password together, and a wrong one counts the same way.

A login refused because it must set up an authenticator and its grace period has passed (see Second factor) is not counted: its password was right, and the count is cleared as for any successful check.

An attempt against a disabled account - disabled by an administrator or for inactivity, see Security policy settings - is refused whatever the password: a wrong password is answered as any wrong password is (error 18456), and the right one with error 18470, Login failed for user. Reason: The account is disabled. - the same order SQL Server applies, so the number reveals the state only to a caller who holds the password. Either refusal counts as a failure, so probing for disabled accounts is rate-limited the same way as guessing.

In maintenance mode only attempts against the administrator login are counted. Any other account is refused in that mode before its password is examined at all, so such a refusal does not raise the count and cannot leave a lockout in place once maintenance is over.

What an operator should know

Note

The count is held in memory on the node that saw the attempts. It is not stored in the metabase and is not shared between nodes.

Two consequences follow, and both are deliberate for a rate limit:

• Restarting a node clears its counts. An account locked out a moment earlier can sign in again immediately after a restart.

• In a cluster, the limit applies per node. An attacker reaching several nodes gets the threshold at each one rather than three attempts in total.

There is no screen for releasing a lockout early, and no setting for the thresholds. A lockout expires on its own; restarting the node is the only way to clear one sooner, and it clears every count on that node rather than one.

This lockout is a rate limit on a login and origin pair, not a lock on the login, so LOGINPROPERTY does not report it: IsLocked and LockoutTime answer NULL. What the function does answer is how many attempts for a login were refused since it last signed in (BadPasswordCount), an attempt refused during a lockout included, and when the last one was (BadPasswordTime), from logon tracking.

A refused sign-in is audited whether or not a lockout is in force — see Logging & diagnostics. Passwords never appear in the audit trail or in any Querona log.