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

21–30 of 155 posts

Re: Never trust the client

#21

Post by ksk »

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.

Re: Never trust the client

#22

Post by secoif »

Ubisoft appears to have some institutional problems. Their other recent Tom Clancy title, Rainbow Six Siege, is hands-down one of the most rewarding & intense shooters I've ever played, however it too is yet to realise its full potential due to amateur-hour quality issues and ongoing troubles with hackers.

Re: Never trust the client

#23

Post by [deleted] »

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…

[deleted]

Re: Never trust the client

#24

Post by amelius »

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 partial state (with obviously weaker protection against hacking), but perhaps still good enough.

Re: Never trust the client

#25

Post by Jare »

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 more expensive and precise packet that corrects the divergence.

Re: Never trust the client

#26

Post by onewaystreet »

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…

> You could use this model of recording inputs and playing them back on the server

Before King was known for its mobile games they were a cash tournaments website (now royalgames.com). This is what they did as well as recording a user's mouse movements.

Re: Never trust the client

#27

Post by rosalinekarr »

iLoch wrote: post #17
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…

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?

Re: Never trust the client

#28

Post by Retric »

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…

There are basically two low cost solutions that work well. A rolling window so your score is in the top X% out of the last 1,000 scores. People may still cheat, but doing so get's boring in the long term so most scores are real. Second validating some chunk of the game. So, for example with chess if you validate every move was valid, and then pick a few random moves and validate that's what your engine would pick.

Note, both of these fail if the high score has any real value.

PS: Another option is to more heavily validate higher scores, keep the top 0.5% honest and cheating to get a lower high score has less value.

Re: Never trust the client

#30

Post by ageektrapped »

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…

> The server should always be the source of truth. It should always enforce all the consistency rules. Database schemas can be a critical tool here as well.

Amen. And I'm a client developer. Clients aren't for data validation, etc. That's the server's job because the server has to store it, use it, ship it off to other things.

Clients are for displaying all that data in a way a human can understand. It has people skills, damn it!

Post reply on HN