Your server pins each stored session record to the client address seen at login — what does that buy, and what breaks?
answer
- raises cost, never prevents
- the caller did not prove it
- roaming clients re-address mid-session
- compare the prefix, not the value
basics
~20 sPinning raises the cost of using a stolen session reference — the thief must also call from that network — but never prevents it. The price is paid by legitimate callers whose address moves: roaming clients, carrier re-addressing and shared egress pools.
solid answer
~50 sIt buys cost, not prevention. A thief holding the opaque session identifier must now call from the pinned address too, which rules out a casual replay from elsewhere but not a caller on the same network, behind the same shared egress, or at the same shared terminal. Real users pay for it: a client moving between wireless and cellular re-addresses, a carrier rotates addresses behind a shared gateway, and a corporate egress pool can hand out a different address per request. Two decisions make it survivable — compare a **coarse unit** such as the network prefix or the operator rather than the exact value, and treat a change as a signal that raises suspicion rather than a rule that ends the record. Remember the value you compare is whichever hop your deployment treats as authoritative, not something the caller proved.
code
pseudocode · 15 lines# at login, stored on the server-side session record
record.bind = { net: prefix_of(observed_address), operator: operator_of(observed_address) }
# on every later request
now = { net: prefix_of(observed_address), operator: operator_of(observed_address) }
if now.net == record.bind.net:
score = 0 # same coarse network: no signal at all
else if now.operator == record.bind.operator:
score = 1 # re-addressed inside one carrier: weak signal
else:
score = 3 # a different operator entirely: worth combining
emit_signal(record.id, "network-move", score) # an input to the verdict, never the verdict
record.bind = now # re-baseline AFTER scoring, not beforego deeper
Know that a network address says where a request came from, not who sent it, and that one person's address can change during a single sitting while several people can share one.
Explain the mechanics: what the pin is compared against, why a coarse prefix survives lease renewal and hand-off, and why the value behind a proxy is whatever the deployment decides to trust.
Demonstrate that you priced it — measured forced sign-ins per population before enabling it, routed a mismatch to a challenge rather than a logout, and re-baselined accepted moves.
Frame it as a cost-versus-coverage trade with a number on both sides, and be willing to conclude that on some deployments the correct binding is none at all.
## What the value is, and where it comes from The client address is the strongest of the three commonly-bound signals and it is still not proof. Its strength is that, unlike a header, the caller does not simply assert it: on a completed connection the peer address is where your bytes actually go back to, so choosing a false one means giving up the replies. Its weakness is everything else. - Once there is a reverse proxy, a gateway or a content network in front of you, your application does not see the peer address at all — it sees whatever the fronting layer reports, and **which hop is authoritative is a deployment decision** made in the proxy chain configuration, not something the session layer can verify. - The address identifies a **network position**, never a person. Everyone behind one office gateway, one carrier gateway, or one ward switch shares it. - One person's address is **not stable**: it changes on network hand-off, on lease renewal, on a carrier moving a subscriber between gateways, and per-request when an egress pool round-robins. Binding means storing the observed value on the **server-side session record** at login and comparing later requests against it. The comparison is entirely yours; nothing in the cookie carries or enforces it. ## What the pin buys It narrows **where** a copied session identifier can be replayed. An attacker who lifted the reference from a log, a shared machine or an injected script and calls from their own network now fails a cheap check, and fails it on the first request rather than after the damage. That is a real, if modest, increase in cost, and it is the honest claim to make in an interview. What it does **not** do is make the stolen reference unusable. An attacker on the same network, behind the same corporate egress, on the same carrier gateway, or physically at the same terminal presents exactly the value you pinned. Binding raises the cost of using a stolen reference; it never prevents it. ## Who pays for it | Population | What happens to the address | Cost of exact matching | |---|---|---| | Client moving between wireless and cellular | changes at every hand-off | a forced re-authentication per hand-off | | Subscriber behind a carrier gateway | rotates on the carrier's schedule | unpredictable mid-session failures | | Staff behind a corporate egress pool | may differ per request | the check fails constantly and randomly | | Mobile cart roaming ward access points | changes per subnet crossed | several forced sign-ins per shift | | Fixed cabled terminal | never changes | no false positives and no true positives | The last row is the interesting one: a signal that cannot vary cannot discriminate, so the deployments where pinning is painless are exactly the deployments where it catches nothing. ## Coarsening the unit The usual repair is to bind to something coarser than the exact value: 1. **The network prefix** — survives lease renewal and small movements inside one network, and still separates a caller in another country. 2. **The operator or autonomous system** — survives a carrier moving a subscriber between gateways, which is the single largest source of false positives on mobile clients. 3. **The coarse geography derived from an address-to-location database** — useful for the impossible-travel check rather than for a gate, and wrong often enough that it must never end a session on its own. Coarsening trades detection range for stability, and you should be able to say which you gave up: bind to the operator and an attacker inside the same large consumer carrier becomes invisible to the check. ## The decision to actually defend - Decide **what a mismatch does**: record it, raise the assurance you demand, or end the record. The middle option is almost always right, because a probabilistic signal should buy a challenge and not a logout. - Decide **how often it will fire on honest traffic**, per population, from measured data rather than from intuition — and be willing to bind nothing when the number is bad. - **Re-baseline** after an accepted change, or one legitimate move is held against the session for the rest of its life. - Keep the claim honest in writing: the pin is a cost increase for the attacker, not a control that stops session reuse.
- Why does pinning behave so differently for a fixed cabled terminal than for a roaming client?On the fixed terminal the address never changes, so the check never fires — and it also never catches anything, because an attacker on that same network presents the identical value. On a roaming client it fires several times a shift on legitimate hand-offs while still missing anyone sharing the egress. Same mechanism, opposite failure.
- What coarse unit would you bind to, and what does the coarsening cost you?The network prefix first, the operator when clients are mobile. It survives lease renewal and carrier re-addressing, which are the bulk of the false positives. The cost is detection range: an attacker inside the same prefix, or behind the same large consumer carrier, now passes the check invisibly.
- Is the address your application compares actually the client's?Only if your deployment says so. Behind a reverse proxy or a content network the application sees whatever the fronting layer reports, and which hop is authoritative is a configuration decision in that chain. Pin against a value the platform is known to set, not against whatever the request happens to carry.
saying these in an interview costs you the question
- Says address pinning makes a stolen session identifier useless
- Assumes one user keeps one address for the life of a session
- Treats the address the application sees as something the caller proved
- Believes a shared egress address distinguishes one caller from another
- Pins to the exact address and calls the resulting logouts a user problem