Push authenticator

Push authenticator is a third second factor, alongside the TOTP and WebAuthn factors described in Multi-factor authentication factors. It works by number matching: a challenge shows two or three numbers on the device requesting access, and the person approves it on their already-registered browser by picking the matching one — never by tapping a bare "approve" button, which is the shape that push-fatigue attacks exploit.

Registering a browser

Registration happens in the browser itself, on the push-authenticator panel of the MFA screen. It generates a P-256 key pair with WebCrypto, keeps the private key non-extractable and stored in IndexedDB, and sends only the public key to Qorionix. Nothing about the private key ever leaves the device it was created on — there is no server-side copy to steal.

A registration also optionally carries a push-delivery token (APNs, FCM or a WebPush subscription) so a challenge can be delivered as a real push notification rather than only being visible by polling. If no delivery channel is configured for your deployment, registration still works and the console prototype polls for pending challenges instead — nothing about approving a challenge requires push delivery to actually function, only to be prompt about it.

The challenge-approve flow

1. A challenge is created for a step-up action. The person's registered device is notified — by push if configured, otherwise the console polls for it.
2. The device fetches the challenge's detail: a set of choices (the numbers) and context about what is being approved. The correct number itself is never included in the push payload, only in the authenticated fetch.
3. The person picks the number that matches what they see on the requesting screen, and the browser signs that choice with the device's private key.
4. Qorionix verifies the signature, checks the number matches, and — if it does — marks the step-up satisfied. A poll token lets the requesting session check the outcome.

Every signed request carries the challenge id, the registration id, the chosen number and the action, so a captured signature cannot be replayed against a different challenge or a different registration.

The anti-fatigue limits

The combination is deliberate: an attacker who has a stolen password cannot simply fire challenge after challenge hoping for an accidental tap, because the rate limit stops them quickly and a denial locks them out of trying again for ten minutes. And because approving requires picking the correct number rather than tapping "yes," a person cannot accidentally approve a sign-in they did not initiate — the numbers on their own screen have to actually match.

Reporting a challenge as fraud does two things: it denies that specific challenge, and it raises the account's risk floor for the next 24 hours, which feeds directly into the adaptive MFA scoring described in Adaptive MFA and risk signals — a fraud report is treated as a genuine signal that the account is under attack, not just a rejected prompt.

Using it

• GET /auth/mfa lists push as an enrolled factor once you've registered a browser.
• GET /auth/step-up offers push among the accepted factors for a step-up challenge.
• POST /auth/step-up with push_challenge_id and push_poll_token consumes an approved challenge to complete the step-up.
• Session-bound management: GET|POST /auth/mfa/push/registrations, DELETE .../registrations/{id}, POST /auth/mfa/push/challenges (raise a step-up challenge), GET /auth/mfa/push/pending.
• Public, signature-authenticated, rate-limited endpoints handle the device side: GET /auth/mfa/push/challenges/{id}/device, POST .../approve, POST .../deny, POST .../status.

The console panel for registering and managing this lives on the MFA screen alongside TOTP and WebAuthn enrolment, as described in Multi-factor authentication factors — register this browser, see an inbox of pending numbers, deny or report a challenge, and send yourself a test prompt.