Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you are trying to achieve the same goal as .NET's SecureString, then your example really doesn't solve the problem. (I could be misunderstanding your goals, in which case I apologize.)</p> <p>The idea of .NET's SecureString is that it stores the string data encrypted in a non-managed chunk of memory, is immutable once created, and can not be read in .NET using a normal string variable. This protects the string from anyone trying to probe your memory space (i.e. malware, worm, Trojan, whatever), and must be explicitly cleaned up by you. The reasons for this involve how .NET treats strings, and the fact that data in memory is only cleaned up at the whim of the GC.</p> <p>Even though your SecureString class encrypts the string into a private variable, the original string that was passed in is still insecure. It can also stick around for a while before the GC collects it, or, if that string was interned, it will live for the duration of the process it resides within. Interned strings are stored in a table, which makes them easier to find, too.</p> <p>On the other side of things...if you Decrypt your SecureString, your getting a new string variable that could run into the same problems as the input string...it is only cleaned up when the GC decides to...and it also may end up interned and live for the duration of the process.</p> <p>To compound problems, every time you Decrypt, you are getting another copy of your encrypted string. This could build up a surplus of decrypted versions of your secure string, increasing the chances that some piece of malware that is probing for, say, credit card numbers...will actually find one.</p> <p>I have tried many times to create a better, more .NET like version of .NET 2.0's SecureString, but have never been able to produce something that is truly secure. You could get a pointer to the string variable that was decrypted, wipe it, set each character to nil, etc. However this could be very problematic in the even that something is still referencing that string, causing disappearing text, corrupted reads, etc. If the string is interned, which generally means it is being used by many things for a long duration of time, wiping it wipes the only version, and affects all use of it. Even if you managed to successfully wipe a copy of your secure string, there is no guarantee that it wasn't copied by other code before you wiped it (i.e. you send your string off to some web service...it now lives in more than one process space, quite possibly in different physical locations around the world.)</p> <p>Its definitely a complicated issue, and only really provides security in the event that your application's memory space has been compromised by malware of some sort.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload