Account lockout as permanent denial of service

The observation

While testing login rate limits, repeated invalid passwords locked my account. The unexpected part was that the lockout also destroyed an already authenticated browser session.

Confirming account-based behavior

I signed in on an Android device using a different network, then triggered the lockout from another client. The Android session was terminated too. That confirmed the lockout was tied to the account rather than the source IP.

The abuse case

An attacker did not need the correct password. They could submit enough incorrect attempts for a known account, force every active session to end, and repeat the process whenever the victim regained access. Automating the same action across known accounts could expand the disruption.

Triage and clarification

The first response treated the report as informative and assumed a man-in-the-middle position was required. It was not: the attacker only needed the victim’s login identifier and the public login form.

Initial triage response closing the account lockout report as informative — The initial response did not recognize the unauthenticated abuse path.

The initial response did not recognize the unauthenticated abuse path.

Follow-up explaining that repeated wrong passwords remotely invalidated another user session — I clarified that no network interception or valid password was required.

I clarified that no network interception or valid password was required.

After further review, the report was reopened, triaged, and rated High because the behavior enabled persistent denial of service against one or many accounts.

Report update showing triaged status and High severity for the account lockout issue — The program later recognized the account-level denial-of-service impact.

The program later recognized the account-level denial-of-service impact.

Disclosure timeline

1 April 2021: report submitted.
9 April 2021: closed as informative; clarification sent.
29 July 2021: reopened and triaged as High.

I published the testing idea on X in October 2021 so other researchers could check the same product decision in their targets.

Public X graphic explaining how login lockout could terminate a victim session — The public summary of the account-lockout test.

The public summary of the account-lockout test.

A friend later applied the technique and received a reward, which reinforced the value of documenting reusable product-logic tests.

Reward email received by another researcher after applying the account lockout technique — A later result shared by another researcher.

A later result shared by another researcher.

Takeaway

Protecting login does not require destroying trusted sessions. Lockout logic should slow or challenge suspicious authentication attempts without giving unauthenticated users a reliable way to remove legitimate users from the product.