How safe is the data inside private field values in a class, and how to make it safer?

I have a class that preloads some values inside its private fields and those fields are used in further calculations.

I'm interested from that point on, how safe is that data-- how easily can it be accessed by a hacker sifting through memory, etc. The perfect开发者_如何学运维 scenario here would be that only its public method called Class.CalculateSomething() would be able to access those fields and return the results.

Knowing that's probably impossible, is there any way to increase how safe those fields are, which are mostly numbers and strings?

You do not include the most important fact about the attacker: who is the attacker? The analysis depends heavily on the answer to this question.

If the attacker is the user then you are done. There's nothing whatsoever you can do if the attacker owns the machine. They own the machine. You don't even know if they're running Windows or not for heaven's sake. They could have written their own operating system and their own CLR. Even if there was a security system in the CLR, you can't rely on it because the attacker might be attacking your code from a custom environment. It is impossible for code to keep secrets from a determined user.

In that case all you can do is (1) lower the benefit of the attacker deriving the secret and (2) raise the cost. Once the cost of the attack exceeds the benefit of a successful attack, a rational attacker will give up.

Better though in this case to do neither. Do not put secrets on a user machine if you don't trust the user. Keep the secrets on a machine that you own.

If the attacker is writing hostile code and then tricking the user into running the code, then you have a shot at it. If the user grants full trust to the hostile code then the hostile code is fully trusted and we're in the same situation as before; the hostile code is fully trusted and therefore is every bit as powerful as the user; that's what "full trust" means.

If the hostile code is partially trusted then in order for it to be allowed to read private members via Reflection, it's got to be granted Skip Visibility Checks permission.

Alternatively, it could be granted Restricted Skip Visibility Checks; an assembly which is granted RSV is allowed to look at the private data of any assembly that was granted equal or less rights.

There is no way to stop code running in your process (and to some extent, depending on the processor and OS, code from other processes) from looking around at the memory in your process and reading it, or worse, modifying it.

Also, private doesn't always limit the scope of access; Reflection can be used to easily examine and modify private fields.

However, there are steps that you can take to help secure your data. When it comes to strings, you can use the SecureString class which will encrypt the contents of the strings in memory and make sure to clear the memory when done.

With integers, I'd recommend converting them to strings, storing them in SecureString, and then pulling them out/parsing them when needed.

Note, in doing this, you will see a performance impact (how much is something you will have to see based on your code and use), as the encryption, etc will always take up processing cycles.

They are easily accessible through reflection. No hacking needed. Are you trying to implement a serial key checker? This is best done in a native code DLL which is harder to crack, because you need more knowledge... But still, it isn't safe, as you can see with every cracked software out there...

I don't think private is used the way you are intending it. It's for performing Object Oriented development and not to do with security against data theft.

If you want to prevent others from sniffing at your private data, Encryption is the best way to go.

I think you've got the wrong end of the stick with regard to private member properties/variables. It by no means secures the values within the classes and is only relevant within the scope of OO programming. If you need to secure information within your application then you'd need to consider encrypting the data but bear in mind that the technology for decrypting the data will also exist within your code (probably with encryption keys available).

You'd need to harden the OS as well as your app, restricting access to the system is always the best approach. Once the cracker gains access, at a high level, to the system itself then you are fighting a losing battle.

For strings security you can use SecureString class. Also you can obfuscate your code but this is a solution which will help only if hackers are lazy enough.

It is not safe at all. Sifting through memory will show your data. That is not what private is for.

Not safe at all. Crack.net will allow everyone to inspect processes, as long as they have permission on the machine.