The Wristband Problem

A few years ago I stayed at an all-inclusive resort for a friend's wedding. At check-in, they scanned my ID, took a photo, and clipped a paper wristband around my wrist. "Don't take this off," the receptionist said. "It's your key to everything here, restaurants, pools, the bar, your room hallway."

For the first day, I noticed staff checking it constantly. Scanned at the buffet. Glanced at by the pool bar. Checked again at the beach club entrance.

By day three, nobody was checking it anymore.

I don't mean they checked it less carefully, I mean they had genuinely stopped looking. The wristband had become part of the scenery. Staff recognized returning guests by face, by routine, by the general shape of "someone who belongs here," and the actual verification; the thing that was supposed to prove I was allowed past that door, quietly disappeared.

One afternoon, a guy at the pool bar noticed my wristband was fraying and asked, half-joking, where he could get a spare one. He wasn't a guest. He'd wandered in from the public beach next door, and once he was inside the perimeter, nobody asked him for anything again. Nobody re-checked. He got a drink, sat at the pool, and left two hours later, unbothered.

He hadn't broken in. He'd just noticed that the actual checkpoint; the one moment where identity mattered, was right at the very beginning, and after that, everything ran on inertia.

The checkpoint that only happens once!

This is, almost exactly, how most web applications handle sessions.

You log in. The server checks your password, maybe asks for a second factor, confirms it's really you, and hands you something; a session token, usually stored in a cookie, that says, in effect, this person is verified, let them through from here on.

From that point forward, nothing re-checks who's actually holding the token. Every click, every page, every sensitive action; password changes, payouts, data exports, API key generation, gets waved through because the wristband is on the wrist. The system isn't looking at the person anymore. It's looking at the token.

And that's a completely reasonable design, in the same way it's reasonable for a resort not to card every guest at every doorway all week. Constant re-verification would be exhausting for everyone. The problem isn't that the shortcut exists. The problem is what happens when the wristband ends up on the wrong wrist.

How the wristband actually gets copied?

Nobody steals a session by guessing a password. That's the slow, loud way in, and most systems are reasonably well defended against it. Session hijacking works by going around the checkpoint entirely, and it tends to happen in one of a few shapes.

Sometimes it's a scripting flaw, an injected snippet of code sitting quietly on a page, reading the session cookie straight out of the browser and mailing it home, the digital equivalent of someone lifting the wristband off your wrist while you're asleep by the pool.

Sometimes it's malware sitting on a laptop, doing the same thing at scale; not targeting one guest, but harvesting wristbands off everyone who walks past.

Sometimes it's a network in between, an open connection somewhere that lets an attacker watch traffic go by and simply copy the token as it travels, no different from photographing a wristband through a window.

And increasingly, it's something more patient: a phishing page that sits between the real login and the user, letting the actual login happen, second factor and all, and quietly keeping a copy of whatever gets issued at the end. The person typing their password did everything right. The checkpoint worked exactly as designed. The copy just got made on the way out the door.

None of these require cracking anything. They all rely on the same quiet assumption the resort staff made by day three: once someone's past the entrance, nobody's really looking anymore.

The failure isn't the theft: it's the silence afterwards!

Here's the part that took me a while to actually sit with. The guy at the pool bar wasn't dangerous. He had a drink and left. But the same gap that let him in would have let in someone with much worse intentions, and nothing about the resort's systems would have looked any different in either case.

That's the real risk with session hijacking. It's not just that tokens can be copied; tokens can always, in principle, be copied. It's that once copied, they're indistinguishable from the real thing, and most applications have no second layer that asks: does this still look like the same person who logged in three hours ago, from three hours ago's device, on three hours ago's network, doing the kinds of things they normally do?

A stolen session replayed from a new device, a new country, or a new pattern of behavior is still, technically, a valid session. The token checks out. The signature is fine. Nothing in the login flow ever gets touched again, because the login flow already did its job hours earlier.

This is the actual lesson from watching how the wristband system degraded over three days. The failure wasn't the moment someone got a copy. The failure was that the system had no mechanism to notice afterward that something didn't match, and by the time anyone might have noticed, the person was already gone.

What checking again actually looks like?

None of this is an argument against sessions, or against trusting a token for reasonable stretches of time. Nobody wants to re-enter their password on every click, in the same way nobody wants to be carded at every doorway of a resort they're already staying at.

The fix isn't more friction everywhere. It's re-checking at the moments that actually matter, the equivalent of a bartender not caring who you are for a poolside drink, but absolutely caring who you are before handing over a room key or charging something to your account.

In practice, that means treating a session less like a fixed pass and more like something that keeps quietly earning its trust:

● Does this session's device, location, and behavior still look like the one that logged in earlier, or has something shifted?

● Is this session attempting something sensitive: a password reset, a payout, an admin change; that deserves a second look regardless of how old the token is?

● If the pattern breaks, does anything happen, or does the token just keep working because nothing was built to ask the question?

Most applications answer "no" to that last one, not out of carelessness, but because session-checking was built once, at login, and nobody came back to revisit it as the product grew.

This is the layer we built SentinelLayer around. Not replacing the login, not adding friction to it; but continuously watching what happens to a session after the door has already opened, and stepping in with a real-time ALLOW, CHALLENGE, or BLOCK decision at the exact moments where a copied token would otherwise sail through unnoticed.

The wristband, revisited..

I still think about that resort sometimes, mostly because the failure was so mundane. Nobody made a dramatic mistake. The system just quietly stopped doing the one thing it was designed to do, a little at a time, until the checkpoint existed in name only.

That's usually how it goes with session security too. It's rarely a single catastrophic hole. It's a login flow that got real investment, followed by a session that was trusted by default and never revisited; right up until the day someone else is wearing the wristband, and nothing in the system was built to notice.