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

91–100 of 155 posts

Re: Never trust the client

#91

Post by SolarNet »

vvanders wrote: post #37
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 repl…

This works great for proper RTS games because the steps are usually pretty lengthy (in game terms, like around 200ms) and the way the game genre typically works means relatively little prediction or complicated simulation design are needed to make even huge steps feel responsive.

Re: Never trust the client

#92

Post by flashman »

MustardTiger wrote: post #6

I'm still constantly shocked at how many games do this. In the MMOG world it is really easy to do everything right, UO came out in 1997 and the devs outright told everyone working on similar games "never trust the client" and "the client is in the hands of the enemy". Yet games like FFXI and WOW that came out many years later have the client setting the position of the player and the server just blindly accepting it,…

One I have experience with is DayZ, which has terrible hacking/scripting problems because it is based on the ARMA military simulator whose audience wasn't inclined towards cheating; the server thus trusts many client actions. They're rewriting the whole engine partly because of this.

Re: Never trust the client

#93

Post by stefs »

another recent example of "never trust the client" is the amazon kindle unlimited debacle.

in case you missed it: the client syncs the last page read. so you can buy a book, jump to the last side and amazon marks it as read, without checking for intermediate states.

the problem is: amazon pays authors by "pages read". so people publish fake books with 3000 pages, let sweat shops try the book for free and just jump from the first to the last page, sync and it registers with "this customer read all 3k pages".

now create 20 fake author accounts and 30 fake reader accounts, publish 20 fake 3k books (one for each fake author account and they're practically filled with 3k pages of randomly scraped web content) and you got 20303000 = 1.800.000 pages read.

if you are an aspiring author and publish a novella with, say, 50 pages and 10.000 readers devour every single page of it, you've got 500.000 pages read.

the faker can do this in a week and take about 4 times more than, even though it took you 2 months to write it. payouts are out of a pot shared between all authors. thus, authors lose in the short run (less money now), cheaters win big time (a lot money now), amazon doesn't lose money (now) because the payout is the same.

in the long run it's still problematic because small authors are unhappy once they realize what's afoot (and earn 1k instead of 10k). big name authors don't care as much if they earn 1m or 1.1m. customers aren't likely to buy the fake books anyway (cheaters take them offline before the free trial period ends) so they're not really affected.

Re: Never trust the client

#94

Post by Thaxll »

MustardTiger wrote: post #85
Thaxll wrote: post #83

Earlier quoted context omitted.

Because it's very expensive to run almost everything server side, it's not the incompetence of the devs it's just about costs.

No it is not, as I said many games do it correctly. It is a very simple distance check, you can perform millions per second on cheap commodity hardware.

So why do you think most games use p2p?

Re: Never trust the client

#95

Post by andyburke »

golergka wrote: post #80
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…

Not every. Right now I'm working on an app where we trust the client. We know that a hacker can compromise a client and send any kind of bogus data, we're just completely OK with it from business perspective.

Can you give any more insight into this product? Curious what kind of product would have that be ok from a business perspective...

Re: Never trust the client

#96

Post by wolfgke »

cortesoft wrote: post #40
ksk wrote: post #21

Earlier quoted context omitted.

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…

> If the client messes up the rendering, the only person affected is the client.

No, just google "wallhack".

Re: Never trust the client

#97

Post by cmdrfred »

andyburke wrote: post #95
golergka wrote: post #80

Earlier quoted context omitted.

Not every. Right now I'm working on an app where we trust the client. We know that a hacker can compromise a client and send any kind of bogus data, we're just completely OK with it from business perspective.

Can you give any more insight into this product? Curious what kind of product would have that be ok from a business perspective...

Closed network with locked down terminals?

Re: Never trust the client

#98

Post by mentos »

bdavisx wrote: post #15

I doubt that the developer's didn't know not to trust the client - they likely made a business decision. I (used to a lot more) play Elite: Dangerous. A space sim that has multi-player. They made the decision to use (mostly) p2p/client networking to save money - they wouldn't need nearly as many servers. This has caused other issues in addition to cheating - a low limit on the number of players in the same "instance"…

Yea and I'll go out on a limb and say it was the correct one. The shelf life of a popular game like this is probably shorter than most people think so it makes sense to offer an amazing experience that you couldn't necessarily achieve with an authoritative server model and then by the time hackers have defeated the game players have probably moved on to the next.

Re: Never trust the client

#99

Post by shinymark »

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…

Your second point is the important one for most games I think. Global leaderboards on a popular game are meaningless for the vast majority of players (do you care that you are in position 324,675?) and almost all of the implementations I've seen have been hacked. As this thread has discussed it's hard to protect false data from getting in the leaderboard.

Limiting leaderboards to friends both gives relevant context for fun competition and mostly eliminates the cheating problem by making it a social issue. I know my friends wouldn't be happy if we were all competing on a game and I cheated.

Re: Never trust the client

#100

Post by nhaehnle »

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…

The article does mention it, though without going into detail - it's called lag compensation.
Post reply on HN