Storing game data on user end?

Question

A thought occurred to me after seeing this question: Storing data - think character data for an online game - on the user`s computer is definitely less safe (maybe an understatement) than on a server under your control, but...

• Is such a mechanism feasible? (while preventing cheating and such, of course...) If yes - why is it not used? Is it just me who hadn't seen it?

Some elaboration and ramblings:

A hypothetical advantage to this would be a need to store VERY little data on the server itself while still being able to handle a HUGE bookkeeping for the character, recording amounts of data you wouldn't dream of while storing the data on your server (think looking back on the exact date of your first attack in a game... sweet, useless, nostalgia :) ).

(Of course, there's a limit to how much you would do this way as well - your user isn't likely to condone a 1GB game save file... or they would... who knows. Maybe an option for what data to keep could give users the choice between conservative and extensive logging of their adventures?)

Take the following example: I think that an attempt to:

• Store a hash of the user's data on the server.
• On the next run, request the data from the user`s end.
• Hash it.
• Compare the hashes.

is bound to fail.

The user could change the data on his end after the verification. I'm assuming there will always be a 'hole' somewhere even if the programmer utilizes tons of checks throughout the game, verifying every action.

This could very well be a reason for not doing this... just remember I'm asking about feasibility, not practicality.

There are some more considerations, of course:

The user's data being at their hands can be less safe and less available. They could lose it, have it stolen, forget their flash drive containing the file at home etc etc.

But it could also mean that the server has very little data on it to be compromised - say, if all of the user's data will be in their file, and the server will only be able to verify its authenticity via hashing mechanism and whatnot.

It will also be very easy to back up a server containing so little data.

The mechanism for the user should be a simple encryption/signature of the data file... or is that bound to fail as well?

Answer 1

Yes, you can create a hash of the players savegame. But it comes with some drawbacks.

Any online game which is supposed to not allow rampant cheating needs an authoritative server which handles all game mechanics. In order to do that, the server needs the whole savegame data. That means the client needs to upload the whole savegame to the server on login anyway. By calculating a cryptographic hash on the server and saving that hash on the server, the server can make sure that the savegame isn't tampered with.

During the gameplay, the server sends regular incremental updates to the clients save-state so it can save them. Each of these small updates should also include the new cryptographic hash of the savegame calculated on the server.

However, this scheme has two problems:

1. When the player loses their savegame, they lose their whole progress. This can be quite devastating, because online games are often played for a very long time. Maybe you could offer some kind of cloud backup service, but that begs the question why you aren't storing the savegame on your game-server to begin with.
2. Imagine the server sends an update and the client crashes while receiving it. Now the save-state on the client is still the old, but the server already expects the new. So the server will not allow the client to login anymore. A possible solution might be to also allow older savegames by having the server keep the past n signatures, but then a cheater could just crash their client whenever a bad event in the game happens to undo it.

But the actual question is why you would do this at all. Storage space isn't that expensive and I could hardly think of an online game where you would save more than a few kByte of data per player. Single player games with a large open world can create quite large savegames, but in an online game the world-state is shared between all players, so you only need to save it once, not once per player.

Answer 2

There are two different scenario's for keeping data on the client safe from the client

The client is not allowed to see the data

I'm assuming that you mean encrypted to prevent unauthorized inspection by the end user? If so then the answer is no. This cannot technically be done. It's the reason those DRM systems all get 'cracked'... They were broken to begin with. You cannot share a secret with someone and then order them to forget it.

The reason is that the game (which is running in an environment under the user's control) needs access to that information. So you would need to supply the encryption key to the user (or at least to the game running on the user's machine) so there is no way to keep it secret as advanced users can inspect the memory of the running game, dump it to file, set breakpoints etc. If that key is in there, they will be able to get it out somehow.

Protect data on the client from changes by the client

Now if you only need to protect against changes, you may be able to get away with storing some of the data only on the client. Say you want to allow the user to select a photo, but you want to make sure it is not an offensive or pornographic image or something. You could let the user upload the photo to the server, then approve or reject it and only it it's approved, store a hash of the approved photo on the server, then throw the actual image data away. The server would send the hash + location/id of the photo to the clients, which would then fetch the actual image data from the other peer client. But they would verify that the photo wasn't replaced by some other one by checking whether the hash of the photo matches the hash the server sent and only accepting it (and showing it in the game) if it does.

So in this scenario, the user would be able to change the photo, but could not trick the server or other clients into accepting those changes.

Answer 3

user2962533 this this is an answer, so here it is.

Long story short: Always assume that the client is a lying, cheating bastard.

i.e. assume that local saves are corrupt, invalid, cheated, shared, hacked and otherwise containing wrong, outdated, or cheated values. No matter how it's encrypted, hashed, or verified, the client executable can always itself be hacked to incorrectly report the hash of the data it's sending or do any number of untoward things with the data. If you have to send the save data itself to the server, you haven't saved network bandwidth at all you've simply moved it around.

There's no advantage to using local saves except to provide an offline/single-player experience. Which is a good thing! Players like it when they can play in a completely offline experience, even when they can't use that same data in an online experience.

Some games (such as Borderlands) don't give a crap if the data is cheated, and this is a perfectly valid way to handle a game so long as there is no competitive aspect (high score lists, etc). Dungeon Defenders 1 had this problem where items would get hacked in and then sold in the in-game markets resulting in people who legitimately obtained the items to feel that theirs had been de-valued. This was possible because there was little/no central server authority (host client had authority, server only maintained save data).

Dungeon Defenders Eternity attempted to fix this. Server had authority over not only saves, but game instances, including item drops etc. (although the game was still received quite negatively by the community for several unrelated reasons).

Long story short: Always assume that the client is a lying, cheating bastard.