A sign-in was push-approved by the user — why doesn't that prove the user started it?
answer
- Approve or deny is one bit
- The prompt describes the requester, not you
- Which way does the information travel?
- Transcription is the binding
- Cap the prompts per interval
basics
~20 sIt proves only that whoever holds the enrolled device pressed approve in response to some request. Without number matching there is nothing the approver must copy from the surface that made the request, so the approval is not bound to any particular attempt.
solid answer
~50 sA bare approve-or-deny prompt is a binary answer to a question the approver cannot inspect. The prompt's contents — application name, location, time — are derived from the *request being authenticated*, so they describe whoever sent it, not the user. The approver therefore has no way to distinguish their own sign-in from someone else's using their password. Number matching changes the shape of the control: the requesting surface displays a value, and the approver must transcribe it into the prompt. That transcription is the binding, because only a party who can see the real sign-in surface knows the value. Two other enforcement properties matter as much: whether the prompt shows enough request context to be judged at all, and whether the number of prompts per account per interval is capped. Approval with none of the three is a factor in name and a coin flip in practice.
go deeper
Know that a plain approve-or-deny prompt is a single yes-or-no answer, and that number matching asks the approver to type in a value shown on the page requesting the sign-in.
Explain where the prompt's contents come from — the request being authenticated — and why that makes the approver judge a sign-in using the requester's own data.
Show precisely what an approval does and does not establish, and name the three enforcement properties of the path: number matching, request context in the prompt, and a cap on prompts per interval.
Be ready to defend the sequencing when you cannot change every path at once: which populations move to a bound factor first, and what you tell an executive who reads an approval as proof of authorship.
## What the control is supposed to assert A second factor is meant to assert *possession*: whoever completed this sign-in also holds something the password holder does not. Push approval does assert possession — the prompt reached an enrolled device and somebody acted on it. What it does not assert, in its weakest form, is **which sign-in was approved**. ## Where the prompt's contents come from This is the fact most candidates get backwards. The application name, the location and the client shown in a push prompt are attributes of **the request being authenticated**. If a password holder submits a sign-in, the prompt describes *their* request: their client, their address's geolocation. The device owner sees a plausible-looking sign-in because they are being shown a real sign-in — just not theirs. So the approver is asked to judge intent from data supplied by the party they are being asked to authorise. Even an attentive person at a keyboard has nothing to compare against. At 06:40, half-awake, with a phone that buzzed, they have less. ## What number matching adds Number matching inverts the direction of information. The **requesting surface** displays a value; the prompt asks the approver to enter it. ``` without number matching device prompt: "Sign-in request - Mail - Frankfurt, DE" [Approve] [Deny] approver supplies: one bit with number matching sign-in page shows: 42 device prompt: "Enter the number shown" -> [__] approver supplies: a value only visible on the requesting surface ``` The binding is the transcription. A party who holds the password but is not looking at the victim's screen cannot supply the number, and the victim cannot supply it either unless they are looking at the surface that made the request. **The approval stops being a judgment about plausibility and becomes a proof of co-presence with the request.** That is a genuinely different security property, and it is why the distinction is worth an interview question rather than a footnote. ## The other two enforcement properties **Request context.** A prompt that shows nothing but "approve this sign-in?" gives the approver no grounds at all. One that shows the application, the approximate location and the client at least lets an alert person notice that they are at home and the request is not. It is weak — the data is the requester's — but it is not nothing. **A cap on prompts.** If an account can receive prompts without limit, the control degrades into an endurance contest that the party sending them always eventually wins. Rate limiting per account per interval is an enforcement property of the authentication path, decided by whoever configures it, and it is independent of how the prompts were provoked. ## The reasoning error to avoid "The user approved it, therefore the user did it" reverses the direction of the claim. What an approval supports is: *a request was made, and a party holding the enrolled device answered yes.* Who made the request is not established by the approval. This matters wherever an approved sign-in is treated as self-evidently legitimate — the approval is evidence of possession, not of intent, and certainly not of authorship. The symmetrical error is to conclude that push approval is worthless. It is not: it still requires possession of the enrolled device and it still defeats a password used alone from anywhere. The correct statement is narrower and more useful — **an unbound approval raises the price of using a stolen password from "free" to "one successful social interaction", while a number-matched approval raises it to "see the victim's screen"**, which is a different order of difficulty. ## What to argue for When asked what to change, name properties rather than products: require number matching on every path that supports it; show request context in the prompt; cap prompts per account per interval; and, where the account justifies it, move to a factor that cannot be answered remotely at all. And be precise about what remains true afterwards — an approved sign-in still means a credential was accepted and a device holder consented, which is not the same sentence as "the named person signed in".
- Where does the location shown in a push approval prompt come from?From the request being authenticated — typically a geolocation of the address that submitted the sign-in. It describes whoever sent the request, not the device holder. That is exactly why a plausible-looking prompt is not evidence: the approver is judging intent using data supplied by the party asking to be authorised.
- Does number matching make push approval phishing-resistant?No. It binds the approval to a request whose surface the approver can see, which defeats a blind approval by a party the user never interacted with. It does not bind the approval to a legitimate destination, so an approver looking at a surface an attacker controls can still read a number off it and transcribe it faithfully.
- Why cap the number of approval prompts an account can receive per interval?Because an uncapped channel turns the control into an endurance contest that the sender eventually wins. A cap is an enforcement property of the path, set independently of how the prompts were provoked, and it converts an unbounded number of chances into a small, bounded one.
saying these in an interview costs you the question
- Treats an approval as proof the named user signed in
- Believes the prompt's location reflects the approver's device
- Says number matching makes the approval phishing-resistant
- Calls push approval worthless rather than weakly bound
- Ignores that uncapped prompts are an enforcement setting