Protecting data in memory

Question

I read several articles on cryptography etc... The cryptography reported by posts was a success in my program, however some data remains in memory being vulnerable to Assembly readers in real time. An example of this is Cheat Engine, which I use to check the security of my application in memory. See the example below for an example of the code I used:

//A string desprotegida
string strCriptografar = "stringParaCriptografar";

//Classe que uso para criptografar
Cript criptClasse = new Cript();
//Aqui criptografo o valor da string...
string textoCriptografado = cript.Criptografar(strCriptografar, "mykey");

Through this I can encrypt the value of string, but when I analyze in Disassembly to string with the text continues in memory at the time of execution. Could you help me?

Answer 1

The only help we can give is not to keep the password anywhere. There is no miracle.

If you need this protection all do not store any password, let the user enter the password of what needs access.

Ah, but still a running application can be intercepted and grab the password at the time of typing.

Yes, and there is nothing that can be done. If the computer is compromised, if there is a possibility of this interception, it will occur. That’s why a computer as a whole needs to be safe.

Security is an extremely complicated thing. In general, when you really need it, the best thing to do is to hire a highly skilled specialist. I don’t even know if this solves it well. Even if I hire one that isn’t misleading. It’s very easy to make a mistake in security. Or do you think these known security breaches occur only by relaxation? Sure, there are cases that are relaxed, and complete ignorance, but in many cases, everything that could be done was done and yet security was circumvented.

In this case the cryptography seems to be being applied even in a naive way. Perhaps because you think the security will happen in another way. Take a read in that question. I have serious doubts that the cryptography was "a success", has definitive proof of this?

A possible palliative solution

The . NET has a class of string sure that helps a little what you want, but it has limits and only helps if it is used right. The question has little context, I do not know if it would help this case. The description is clear that it only keeps the text for as long as necessary. This time is enough for an interception.

Answer 2

As has already been said, a question about security is rarely simple. However, if you need to have the data in memory without it being visible, do not use any temporary/fixed variables for storage before encryption.

On the face of it, it involves a slightly more specific problem, which is how memory management is done in .NET. So, if you use a string variable, it will be stored until GC decides it is no longer useful and you have no control over when it will be moved out.

There are several articles on this, try this: http://www.codeproject.com/Articles/38069/Memory-Management-in-NET

Also, why do you need to start the string in a plain text variable? If you are going to use it, you could at least use it in a Securestring, see this link:

https://msdn.microsoft.com/pt-br/library/system.security.securestring(v=vs.110). aspx

But, there also involves how safe a Securestring is :)

The biggest problem is how you capture the string and how your encryption works. But at some point, it will pass through memory so it can be encrypted.

You could use unmanaged code to better control the time it remains in memory, but unmanaged code has other security issues, many of them linked to memory management or program execution flow.

There is no silver bullet. Even a char, typed on the keyboard, has to go through a buffer, just try to ensure that the location where you place the plain text, exists in the shortest possible time and is never stored in a long duration scope.

See the difference in the link code example for Securestring:

using System;
using System.ComponentModel;
using System.Diagnostics;
using System.Security;

public class Example
{
    public static void Main()
    {
        // Instantiate the secure string.
        SecureString securePwd = new SecureString();
        ConsoleKeyInfo key;

        Console.Write("Enter password: ");
        do {
           key = Console.ReadKey(true);

           // Ignore any key out of range.
           if (((int) key.Key) >= 65 && ((int) key.Key <= 90)) {
              // Append the character to the password.
              securePwd.AppendChar(key.KeyChar);
              Console.Write("*");
           }   
        // Exit if Enter key is pressed.
        } while (key.Key != ConsoleKey.Enter);
        Console.WriteLine();

        try {
            Process.Start("Notepad.exe", "MyUser", securePwd, "MYDOMAIN");
        }
        catch (Win32Exception e) {
            Console.WriteLine(e.Message);
        }
        finally {
           securePwd.Dispose();
        }
    }
}

The main difference is that it does not save a plain text string to then pass to the encryption, it already adds char to char the encrypted string.

Another thing he does, is that he overwrites each char to each new char typed, thus only the Securestring contains in memory the whole sequence, but, the current char continues in memory for as long as the scope and the GC allow.

This particular case of analysis, at first glance, seems only to serve for a char-to-char input by the console, however, you should remember that it can be applied to the read stream of any byte-a-byte, not forgetting of course the hidden buffers in the implementation of most standard Apis.

Also, if the machine is compromised, even this approach falls easily on a Keylogger. :(