Itnetic TechnologiesThree different things people mean by "verification"
The word covers a ladder, and each rung answers a different question.
Does this connection hold a real Minecraft account? Answered by the session-server check the game itself uses in online mode. Passing it requires a real, currently-authenticated account, which is something a bot farm cannot fake and cannot buy cheaply at scale.
Is there a person here? Account ownership is buyable in bulk, so a serious attacker holding a pile of genuine accounts passes the first rung without slowing down. The rung above asks a human to do something a human does trivially and a script does expensively.
Is this still a client? Both of the above are one-off costs. Behaving like a Minecraft client for an entire session is a continuous one — see Minecraft bot attacks.
Why the account check has to be budgeted and has to fail open
The session check is the single most expensive thing in a login path, because it is an HTTPS round trip to a third party. Two rules follow from that, and both are about not letting a defence become a liability.
Budget it per address. A flood must never turn your protection into a load generator against Mojang's session servers. Whoever is attacking you should not be able to make you attack somebody else.
Fail open when it is unavailable. Sustained session-server failure should degrade the tier rather than lock every player out. A Mojang outage becoming your outage is a worse failure than briefly admitting an unverified player — your community does not care whose fault it was.
Why web CAPTCHA techniques do not transfer
The instinct is to warp some text and ask the player to read it. In Minecraft this is close to useless, and the reason is worth understanding because it generalises.
The most natural place to draw a code is on a filled map, which the game renders as a grid of colour indices. That grid arrives at the client as a small block of plain palette bytes. Nothing about it has to be rendered to be read: a scripted client sees exactly the same grid a player does, only without eyes in the way. There is no rendering step to hide behind and no canvas fingerprint to check.
So warping the glyphs is the wrong lever. A distortion strong enough to hurt a classifier hurts a tired person reading five characters at least as much — and the classifier is the one that gets to retry for free. A CAPTCHA an honest player fails is not a strong CAPTCHA, it is an outage with extra steps: they retry, get another unreadable image, and leave, while the solver keeps retrying at no cost.
What actually costs a solver something
If the glyphs cannot be made hard to recognise without hurting players more, the cost has to move somewhere a person pays for free and a script does not.
Selection by a property humans process preattentively. Deciding which characters count by colour, and naming the colour in the prompt, is nearly free for a person — picking a colour out of a field happens below the level of reading. A solver has to parse the prompt text, map a colour word onto a palette index, and only then segment the image.
Low-contrast decoys. Marks a few shades off the background sit below the contrast a person bothers with and comfortably above "pixel differs from background". This costs the player nothing and defeats the threshold-everything-and-count-blobs approach outright, though it costs a solver little once it filters by exact index. It is a cheap layer, not a strong one — and it is worth being clear about which layers are which.
Per-render variation. Layout, which colour is the key, and the exact shape each glyph takes are all re-rolled every time, so the work cannot be done once and cached. Rotating a glyph about its own centre costs a person essentially nothing while denying a template match the upright axes it keys on. Note the contrast with occlusion or severing strokes, which costs a person a real perceptual step and gets mis-read — the distinction between "harmless to a human, hostile to a matcher" and "hostile to both" is the whole craft here.
The order as a dimension. This is the strongest available layer. A still image with five characters on it is a screenshot: one packet, one recognition pass, cached forever. If instead the characters are revealed one at a time, and the answer is the order they appeared in, then no single packet holds the answer — not the first, not the last, not any one of them. Merging the frames, which is the obvious first attempt, recovers the characters and loses the order. A person watching the screen gets the order for free, because time is a dimension humans have and packet dumps do not.
The pairing detail matters and is easy to get wrong: each step must reveal more than one character, with only the prompt saying which one counts. If the only thing that ever appeared were an answer character, a solver could ignore the image entirely and read the packets in arrival order.
What a good challenge refuses to do
No external verification service. A challenge that depends on a third party inherits every outage that party has, and it sits directly on the path your players log in through. On the web that is a bad day; on a game server's login path it is the server being down.
No mod, no plugin, nothing for players to install. Anything requiring installation is protection most of your community will not have when they need it.
No pretending the player must be a paid account when the server says otherwise. A server that deliberately admits offline accounts cannot be asked to prove paid ones — the check would reject exactly the players it was told to allow. It needs a different rung, and a weaker one is honest as long as it is described as weaker.
Proving a human is not the same as proving a human is watching
Reading a code proves that something parsed a packet. Because the image arrives as plain bytes, a renderer-less script can produce the right answer without ever having a camera or a screen.
The complement is to check the parts a scripted client has no reason to fake: did the view actually move to look at the thing being read, did it get there gradually rather than in one forged jump, were the steps varied the way a hand on a mouse produces rather than uniform the way a linear sweep does, and did the other axis move at all — because nobody holds a mouse perfectly still on one axis.
One design note that matters: none of this should be judged on timing. A vanilla client sends these updates on its own fixed tick, so a real player's intervals are as regular as a script's. Treating regular timing as suspicious would fail everybody. The values are the signal; the clock is not.
And none of it is unfakeable, which is fine — a solver already driving a real client passes it for free. What it closes is the cheap path: reading bytes out of a socket without ever having a camera. That is the path worth closing, because it is the one that scales to a login flood.
Remembering a pass
Verification costs the player time and costs the network real work, so doing it on every join would be both rude and expensive. A pass has to be remembered — as a signed token the client presents next time, or, for clients too old to store one, as a coarser address-and-name association.
Two rules keep that from becoming a hole:
Bind it to the server it was earned on. A token earned on one server must be worthless on another, or an attacker verifies once and is trusted across every server on the network.
Grant exactly one thing: skipping the challenge. Trust must never bypass the ban list, the rate limits or the plan cap. It is an optimisation over re-verifying, not a privilege.
One reconnect, and why
Verification that happens in front of the server has a structural advantage worth the cost it carries. If the protection proves the account itself and then hands the player back to reconnect, the server keeps its own authentication and needs no reconfiguration at all — and the "leaked backend address lets anyone join as any username" hole that follows forwarding proxies around never opens, because the server still authenticates every player itself.
The cost is one reconnect the first time. On modern clients that is automatic and invisible; on clients older than 1.20.5 the player clicks the server once more. That is the honest trade, and it is a small one next to a server whose whole identity model depends on nobody ever finding its address.
Itnetic's game protection implements this ladder in front of Java Edition servers, with the challenge drawn inside the game and no third-party service on the login path.