Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never trust the client

gafferongames.com

Post reply on HN
Print view View original

31–40 of 155 posts

Re: Never trust the client

#31

Post by turaw »

MBCook wrote: post #7

Since this is a multi-player game this is obviously a big problem but I've always wondered how you'd handle this in a single player game with a leaderboard. Let's say you have a Bejeweled clone/match-3 game and a global high score board. What can you do to prevent fake scores? You can obviously obfuscate things, sign requests, etc but at some point the client needs to sign the score it's sending up so the client has…

Recording and playing back input events, at least, shouldn't be that expensive unless you're emulating the entire stack up to the application. If the logic is written in some portable manner (Xamarin [1], etc.) you could just re-execute on the server with the same logic as the client. It requires a fair amount of discipline to keep everything deterministic, too. The real difficulty would be identifying the AI players from the humans; you'd basically have to recreate re-captcha's humanity checkbox, and that's still not a guarantee.

Or, identify that your business need is just to provide 'some' sort of ranking and compare the user against their Facebook/G+/Twitter friends, who are probably less likely to cheat.

[1]: https://www.xamarin.com/

Re: Never trust the client

#32

Post by JoshTriplett »

rosalinekarr wrote: post #27
iLoch wrote: post #17

Earlier quoted context omitted.

This is actually impossible without hardware encryption. Apple should have no problem with this since they have control over their hardware, but they don't do anything to prevent fake scores from showing up in their leaderboards. Xbox is a great example of being able to trust the client. The console tells the server that it has unlocked an achievement by using a signed request which was signed by the secure chip. The…

> Apple should have no problem with this since they have control over their hardware, but they don't do anything to prevent fake scores from showing up in their leaderboards. Apple has leaderboards? For what?

Apple's "Game Center" (https://en.wikipedia.org/wiki/Game_Center) provides integrated cross-game leaderboards and achievements/badges.

Re: Never trust the client

#33

Post by vvanders »

Jare wrote: post #25
vvanders wrote: post #2

They missed one key bit on CS's network model(which is what made it so great) is that they would actually re-wind the gamestate to do hitchecks so you could have a latency of 200ms+ and have a reasonable experience. Also the common term for resolving these types of things on the client is called "dead-reckoning". You've always got a diverging states from latency so you're continuously trying to reconcile this on the…

A quick note, I think dead reckoning is not about correcting for latency. It is a conscious decision on the server to send less precise (cheaper), incremental data to the client most of the time. The client extrapolates from this imprecise data to still provide a fluid and continuous motion. The server performs the same extrapolation, and precisely tracks the error accumulated by the client to decide when to send a m…

That's the traditional term, but it has specific meaning in game network programming. For instance we never send back the "error accumulated" to the server. Instead the server usually sends a PVS(potentially visible set) that the client handles displaying in a meaningful way(and reconciling and discrepancies). This PVS set is usually absolute values but at a discrete snapshot in time(of which the client can never be certain due to latency and there not being a single global clock). The client is basically guessing where the simulation is going and then smoothly handling(normally interpolation over your usual time-slice) differences from the server snapshot.

That PVS is why you'll see map hacks where people can see through walls and whatnot. The server is doing less expensive checks(not doing a ray cast per-client to client which is n^2) and the cheat takes advantage of that data in memory.

Re: Never trust the client

#34

Post by greenail »

amelius wrote: post #24
MBCook wrote: post #7

Since this is a multi-player game this is obviously a big problem but I've always wondered how you'd handle this in a single player game with a leaderboard. Let's say you have a Bejeweled clone/match-3 game and a global high score board. What can you do to prevent fake scores? You can obviously obfuscate things, sign requests, etc but at some point the client needs to sign the score it's sending up so the client has…

Perhaps you can solve this as follows. The client is going to go through a series of states, guided by some inputs. You can compute a hash from these states. Now you let the server go through the same states (using the same inputs), and compute the hash, and compare the hash codes from server and client. This sounds prohibitively complicated (and requires work from the server). But note that the state can be a partia…

from my recollections forever ago, RTS games like the spring engine use checksums on state to prevent manipulation. the game client gets "out of sync" if a client's checksum doesn't match. The state checksum is computed at every tick of the simulation. This makes it so you don't have to run the simulation on the server. Debugging is very hard though, and odd things like FPU precision on different processors can create all kinds of difficult bugs.

Re: Never trust the client

#35

Post by JoshTriplett »

ksk wrote: post #21
xenadu02 wrote: post #12

"Never trust the client" is good advice for every kind of application. Clients are filthy liars. Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you. The server should always be the source of truth. It shoul…

With caveats. What you're also implying is that clients should do no processing - because clients can't be trusted to do anything. If you apply this logic to web-browsing, you're asking the server to send the client a bitmap image of what the rendered page should look like.

Not at all. It's fine for the client to handle processing when the only thing they could hurt is the user of the client. If the client renders a web page incorrectly, only the user of the client gets hurt by that. But the server API must not allow a malicious client to do damage that affects other clients.

Re: Never trust the client

#36

Post by beachy »

ksk wrote: post #21
xenadu02 wrote: post #12

"Never trust the client" is good advice for every kind of application. Clients are filthy liars. Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you. The server should always be the source of truth. It shoul…

With caveats. What you're also implying is that clients should do no processing - because clients can't be trusted to do anything. If you apply this logic to web-browsing, you're asking the server to send the client a bitmap image of what the rendered page should look like.

Your example is about the client misreporting server state to the end user.

The big deal is instead about a badly behaved client being able to make "illegal" changes to the server state.

Re: Never trust the client

#37

Post by vvanders »

MBCook wrote: post #7

Since this is a multi-player game this is obviously a big problem but I've always wondered how you'd handle this in a single player game with a leaderboard. Let's say you have a Bejeweled clone/match-3 game and a global high score board. What can you do to prevent fake scores? You can obviously obfuscate things, sign requests, etc but at some point the client needs to sign the score it's sending up so the client has…

If you have a deterministic game model(RNG seeded properly, pure functions, etc) you can actually just send the user inputs(which are very small compared to the whole game state) and replay the whole game to verify.

This is the common model in RTS games called Lock Step since all clients are advancing a number of frames based on all inputs from other clients in "lock step".

It's also very common way to implement replay and debugging for reproducing rare network bugs.

Re: Never trust the client

#38

Post by vvanders »

turaw wrote: post #31
MBCook wrote: post #7

Since this is a multi-player game this is obviously a big problem but I've always wondered how you'd handle this in a single player game with a leaderboard. Let's say you have a Bejeweled clone/match-3 game and a global high score board. What can you do to prevent fake scores? You can obviously obfuscate things, sign requests, etc but at some point the client needs to sign the score it's sending up so the client has…

Recording and playing back input events, at least, shouldn't be that expensive unless you're emulating the entire stack up to the application. If the logic is written in some portable manner (Xamarin [1], etc.) you could just re-execute on the server with the same logic as the client. It requires a fair amount of discipline to keep everything deterministic, too. The real difficulty would be identifying the AI players…

Ah shoot, you beat me to it by 5 minutes :). Yeah, that's how you do it in practice.

Re: Never trust the client

#39

Post by beachy »

forgotmypassw wrote: post #29

I thought it was a common sense to treat the client as merely the data representation and nothing else, sad to see that multi million dollar companies make rookie mistakes.

I guess in the eyes of a corporate, it's only a mistake if it harms the bottom line.

Sounds like this would though, if players can't enjoy a fair experience.

Re: Never trust the client

#40

Post by cortesoft »

ksk wrote: post #21
xenadu02 wrote: post #12

"Never trust the client" is good advice for every kind of application. Clients are filthy liars. Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you. The server should always be the source of truth. It shoul…

With caveats. What you're also implying is that clients should do no processing - because clients can't be trusted to do anything. If you apply this logic to web-browsing, you're asking the server to send the client a bitmap image of what the rendered page should look like.

I think that is misinterpreting what the person you are replying to is saying.

They aren't saying "don't let the clients do anything", they are saying "don't trust the values the clients send back"

If the client messes up the rendering, the only person affected is the client. There is no 'trust' required, because you are not relying on anything the client has done.

The idea of trust only comes into play if there is a consequence to that trust being broken.

Post reply on HN