-1

I don't know if I should ask this question on security.SE or stackoverflow, so please move my post if necessary.

I want to store my (C#) application data in a way that the user cannot read or modify it. If I encrypt the files, I will need a password to be able to decrypt them when my program has to read them.

Where would I store this password (because the sourcecode can be read with disassemblers, so storing the passwords in the code is not an option)?

Is there another option for storing the data than using a password? If not, what would be the best place to store the password without the user being able to access it?

pascalhein
  • 101
  • 2
  • @DeerHunter - Good find there! I agree, we get this type of questions each week and they all have same answers. Probably another in a long line of questions that we need a canonical thread for. I'll suggest it in the chat and see what others think of it. Cheers! ;) – TildalWave Jun 27 '13 at 18:00
  • @DeerHunter I did not ask about piracy and DRM, but more about storing application data (such as user configuration, game progress, custom elements etc) – pascalhein Jun 27 '13 at 18:13
  • 2
    If you want to deny the user some right, **it is DRM**. – Deer Hunter Jun 27 '13 at 18:15
  • @DeerHunter then what would be the best way to make this as difficult as possible (for the content I mentioned above)? – pascalhein Jun 27 '13 at 18:28
  • The [cat](http://security.stackexchange.com/users/12578/aj-henderson) knows the [answer](http://security.stackexchange.com/a/38107/13820). – Deer Hunter Jun 27 '13 at 18:36
  • @DeerHunter The reason I dislike "Duplicates" is because if you look at tags we have synonyms. When people use google to find answers like these they don't always know the exact words they are looking for so these questions become useful for those people. I really don't mean to bash on you and honestly I don't know why I'm telling you this considering you're just doing your job but I'd like to let this be known. Unless it is nearly word for word duplication I don't feel these should be closed. Also situations while slightly different can effect answers greatly. – Griffin Nowak Jun 27 '13 at 19:39
  • @Griffin - no probs. Statistically speaking, the chances for an exact **verbatim** duplicate are very slight. Not so for the **semantic** ones. If the question is closed as a duplicate, I suppose it still comes up in a search, and leads the person to the right answer, just a click away. If you have more questions on the problem of dupes, please ask them in meta. – Deer Hunter Jun 27 '13 at 20:21
  • @DeerHunter I dislike the meta due to an almost overflow of opinions. Talking 1 on 1 is less confusing. And it's little things like the difference between a Linux distro or windows XP / 7. The duplicates I see as being a problem are when (I've seen this a couple times) question is posted by the same user twice. – Griffin Nowak Jun 27 '13 at 20:40

1 Answers1

4

What you are talking about is the infamous problem of DRM. There is unfortunately no way to do this. The fundamental problem is one of trust. In current modern systems, the user is god. They have control of the hardware and can therefore abuse the system anyway they want. Your program has to run in their domain. As such, anything your program can do, the user can reverse engineer and do. You can make it harder for them to figure out what they need to do, but ultimately, if it is on their hardware, it is their system, not yours.

This is DRM because ultimately, DRM is about having a secret safe from the user that the software knows. How does DRM on music work? It tries to hide the encryption key for the music such that the software can play it, but the user can't decrypt it. Your case is no different. The answer is either to have a system where the user is not god (ie, the user doesn't have root access to the box and the hardware is trusted as secure) or similarly, run the software on a server you control and limit their access such that they can't do what you don't want them to do.

If you want to attempt it, you can't get much more secure than simply including the key in source code. You can try one of the various commercial systems for obfuscating keys, but they can all be broken. Discussion of detailed techniques for trying to hide it here would be a) too broad and b) useless as anyone could look up this post and see what kinds of things you might be doing.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • thank you for the reply, I will have to choose something else to do this. how would you, for example, store the progress of the user in a game so he can't "cheat" by modifying the file? – pascalhein Jun 27 '13 at 18:45
  • 1
    @csharpler - for a single-player game, it probably doesn't matter (they're cheating themselves - usually). If it's an MMO, you better be storing it/trusting it from the server, period; if you don't run the game on hardware you control (completely - even consoles can be hacked), the end user can do whatever he wants, including sending false 'advancement' events to update the save-game state on a server. – Clockwork-Muse Jun 27 '13 at 18:53
  • 2
    @csharpler - still the same problem. In fact, in gaming, it is pretty much universally true that every attempt to protect a save game of even moderate popularity results in it being cracked and a save game altering tool is released by a third party. Server storage and limited access (and verification of changes on the server) is the only way to keep such data secure. This is why Diablo 3 and Starcraft 2 both require always on connections to play to ensure that cheating doesn't occur by persisting progress on the server and changing the proof needed so it can't be easily cracked. – AJ Henderson Jun 27 '13 at 19:57