Securing strings in .NET....possibility?
-
I have been trying to come up with a way to manage string security in .NET. The whole idea of a SecureString is nice, but the way it works in .NET right now is atrocious...it just doesn't really provide any value given how it is such a pain to work with. I wrote the following extension to System.String...curious what others think:
public static class StringExtensions
{
const string OVERWRITE_CHARS = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890-=~!@#$%^&*()_+";
const int MAX_OVERWRITES = 3;/// <summary> /// Performs a secure wipe of the string in memory, overwriting the /// existing contents with junk, then again with nil. /// </summary> /// <param name="str">The string to wipe.</param> public static unsafe void SecureWipe(this String str) { // If string is null, there is no securing to be done...return gracefully if (str == null) return; // Prepare Random rnd = new Random(); int maxRnd = OVERWRITE\_CHARS.Length; int maxLen = str.Length; // Pin the string in memory so GC doesn't mess with it, and get a pointer fixed (char\* c = str) { // Overwrite with random junk a few times for (int r = 0; r < MAX\_OVERWRITES; r++) { for (int i = 0; i < maxLen; i++) { char rndChar = OVERWRITE\_CHARS\[rnd.Next(maxRnd)\]; c\[i\] = rndChar; } } // Overwrite one last time with nil for (int i=0; i < maxlen; i++) { c\[i\] = '\\0'; } // Set the length to zero int\* len = (int\*)c; len\[-1\] = 0; } }}
I know its possible for the .NET framework to create copies of a string in internal framework methods...nothing I can do about that, and when you need to display a string, SecureString doesn't solve that problem either. But at least with something like this...you can wipe the copy that hackers are most likely to get. Thoughts? Improvements? Reasons why it won't work?
-
I have been trying to come up with a way to manage string security in .NET. The whole idea of a SecureString is nice, but the way it works in .NET right now is atrocious...it just doesn't really provide any value given how it is such a pain to work with. I wrote the following extension to System.String...curious what others think:
public static class StringExtensions
{
const string OVERWRITE_CHARS = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890-=~!@#$%^&*()_+";
const int MAX_OVERWRITES = 3;/// <summary> /// Performs a secure wipe of the string in memory, overwriting the /// existing contents with junk, then again with nil. /// </summary> /// <param name="str">The string to wipe.</param> public static unsafe void SecureWipe(this String str) { // If string is null, there is no securing to be done...return gracefully if (str == null) return; // Prepare Random rnd = new Random(); int maxRnd = OVERWRITE\_CHARS.Length; int maxLen = str.Length; // Pin the string in memory so GC doesn't mess with it, and get a pointer fixed (char\* c = str) { // Overwrite with random junk a few times for (int r = 0; r < MAX\_OVERWRITES; r++) { for (int i = 0; i < maxLen; i++) { char rndChar = OVERWRITE\_CHARS\[rnd.Next(maxRnd)\]; c\[i\] = rndChar; } } // Overwrite one last time with nil for (int i=0; i < maxlen; i++) { c\[i\] = '\\0'; } // Set the length to zero int\* len = (int\*)c; len\[-1\] = 0; } }}
I know its possible for the .NET framework to create copies of a string in internal framework methods...nothing I can do about that, and when you need to display a string, SecureString doesn't solve that problem either. But at least with something like this...you can wipe the copy that hackers are most likely to get. Thoughts? Improvements? Reasons why it won't work?
I'm not able to say if there are scenarios when this wouldn't work (concerning internal memory handling), but as far as I can see, looks very good. Now you've chosen to do this as an extension, which is good since it can be used for any string. However, would there be a point if you also create a wrapper class for this kind of strings. With the wrapper you could possibly have more control over the string usage and behaviour. For example you could have separate mechanisms to show the string or to modify the string etc.
The need to optimize rises from a bad design.My articles[^]
-
I have been trying to come up with a way to manage string security in .NET. The whole idea of a SecureString is nice, but the way it works in .NET right now is atrocious...it just doesn't really provide any value given how it is such a pain to work with. I wrote the following extension to System.String...curious what others think:
public static class StringExtensions
{
const string OVERWRITE_CHARS = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890-=~!@#$%^&*()_+";
const int MAX_OVERWRITES = 3;/// <summary> /// Performs a secure wipe of the string in memory, overwriting the /// existing contents with junk, then again with nil. /// </summary> /// <param name="str">The string to wipe.</param> public static unsafe void SecureWipe(this String str) { // If string is null, there is no securing to be done...return gracefully if (str == null) return; // Prepare Random rnd = new Random(); int maxRnd = OVERWRITE\_CHARS.Length; int maxLen = str.Length; // Pin the string in memory so GC doesn't mess with it, and get a pointer fixed (char\* c = str) { // Overwrite with random junk a few times for (int r = 0; r < MAX\_OVERWRITES; r++) { for (int i = 0; i < maxLen; i++) { char rndChar = OVERWRITE\_CHARS\[rnd.Next(maxRnd)\]; c\[i\] = rndChar; } } // Overwrite one last time with nil for (int i=0; i < maxlen; i++) { c\[i\] = '\\0'; } // Set the length to zero int\* len = (int\*)c; len\[-1\] = 0; } }}
I know its possible for the .NET framework to create copies of a string in internal framework methods...nothing I can do about that, and when you need to display a string, SecureString doesn't solve that problem either. But at least with something like this...you can wipe the copy that hackers are most likely to get. Thoughts? Improvements? Reasons why it won't work?
I think this would be a bit of a nightmare to manage since string operations usually end up creating more strings. A simple concantenation leaves to the initial strings intact and creates a third. Instead of a string automatically wiping itself at the end of its life, you have to manage that for each and every instance of a secured string.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
I have been trying to come up with a way to manage string security in .NET. The whole idea of a SecureString is nice, but the way it works in .NET right now is atrocious...it just doesn't really provide any value given how it is such a pain to work with. I wrote the following extension to System.String...curious what others think:
public static class StringExtensions
{
const string OVERWRITE_CHARS = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890-=~!@#$%^&*()_+";
const int MAX_OVERWRITES = 3;/// <summary> /// Performs a secure wipe of the string in memory, overwriting the /// existing contents with junk, then again with nil. /// </summary> /// <param name="str">The string to wipe.</param> public static unsafe void SecureWipe(this String str) { // If string is null, there is no securing to be done...return gracefully if (str == null) return; // Prepare Random rnd = new Random(); int maxRnd = OVERWRITE\_CHARS.Length; int maxLen = str.Length; // Pin the string in memory so GC doesn't mess with it, and get a pointer fixed (char\* c = str) { // Overwrite with random junk a few times for (int r = 0; r < MAX\_OVERWRITES; r++) { for (int i = 0; i < maxLen; i++) { char rndChar = OVERWRITE\_CHARS\[rnd.Next(maxRnd)\]; c\[i\] = rndChar; } } // Overwrite one last time with nil for (int i=0; i < maxlen; i++) { c\[i\] = '\\0'; } // Set the length to zero int\* len = (int\*)c; len\[-1\] = 0; } }}
I know its possible for the .NET framework to create copies of a string in internal framework methods...nothing I can do about that, and when you need to display a string, SecureString doesn't solve that problem either. But at least with something like this...you can wipe the copy that hackers are most likely to get. Thoughts? Improvements? Reasons why it won't work?
Yeah, what they said. Plus I would make the Random a static member of the class rather than creating a new one on each call. I might also use a cryptographic randomizer instead of Random. However, I expect you may be tryingto fix a non-existant problem.
Jon Rista wrote:
the way it works in .NET right now is atrocious
Please explain.
-
I have been trying to come up with a way to manage string security in .NET. The whole idea of a SecureString is nice, but the way it works in .NET right now is atrocious...it just doesn't really provide any value given how it is such a pain to work with. I wrote the following extension to System.String...curious what others think:
public static class StringExtensions
{
const string OVERWRITE_CHARS = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890-=~!@#$%^&*()_+";
const int MAX_OVERWRITES = 3;/// <summary> /// Performs a secure wipe of the string in memory, overwriting the /// existing contents with junk, then again with nil. /// </summary> /// <param name="str">The string to wipe.</param> public static unsafe void SecureWipe(this String str) { // If string is null, there is no securing to be done...return gracefully if (str == null) return; // Prepare Random rnd = new Random(); int maxRnd = OVERWRITE\_CHARS.Length; int maxLen = str.Length; // Pin the string in memory so GC doesn't mess with it, and get a pointer fixed (char\* c = str) { // Overwrite with random junk a few times for (int r = 0; r < MAX\_OVERWRITES; r++) { for (int i = 0; i < maxLen; i++) { char rndChar = OVERWRITE\_CHARS\[rnd.Next(maxRnd)\]; c\[i\] = rndChar; } } // Overwrite one last time with nil for (int i=0; i < maxlen; i++) { c\[i\] = '\\0'; } // Set the length to zero int\* len = (int\*)c; len\[-1\] = 0; } }}
I know its possible for the .NET framework to create copies of a string in internal framework methods...nothing I can do about that, and when you need to display a string, SecureString doesn't solve that problem either. But at least with something like this...you can wipe the copy that hackers are most likely to get. Thoughts? Improvements? Reasons why it won't work?
I'm still trying to figure out what security scenario you are trying to protect from. Some sort of forensic analysis of memory (like wiping a hard drive)? Sorry if I misunderstand. But the whole concept is fraught with problems. As you said, .NET and Windows is free to move and copy memory at will. Virtually any string operation will make a copy of the original string(s). What about, paging to disk? That would seem to be much more of a vulnerability. Also, what about interning? Someone correct me if I am wrong but, doing something like this:
string firstString = "abc";
string secondString = "abc";
SecureWipe(FirstString);...could potentially destroy the contents of secondString (because of the unsafe code pointing to the intern'ed string). Besides, as Dave said (above), if you did something like this:
string firstString = "abc";
string secondString = "xyz";
secureWipe(firstString);
secureWipe(secondString);firstString and secondString would likely be overwritten with the same "random" character sequence. That's not "secure". Move the instance of Random() outside of SecureWipe() so it is only executed once.
-
I'm still trying to figure out what security scenario you are trying to protect from. Some sort of forensic analysis of memory (like wiping a hard drive)? Sorry if I misunderstand. But the whole concept is fraught with problems. As you said, .NET and Windows is free to move and copy memory at will. Virtually any string operation will make a copy of the original string(s). What about, paging to disk? That would seem to be much more of a vulnerability. Also, what about interning? Someone correct me if I am wrong but, doing something like this:
string firstString = "abc";
string secondString = "abc";
SecureWipe(FirstString);...could potentially destroy the contents of secondString (because of the unsafe code pointing to the intern'ed string). Besides, as Dave said (above), if you did something like this:
string firstString = "abc";
string secondString = "xyz";
secureWipe(firstString);
secureWipe(secondString);firstString and secondString would likely be overwritten with the same "random" character sequence. That's not "secure". Move the instance of Random() outside of SecureWipe() so it is only executed once.
First off, this is really more of a proof of concept than a final roduct. More extensions, or perhapse a new SecureString class, could be created to handle copy, concat, modify, etc. The basic goal is to scramble strings when your done with them so that leftover strings in memory don't contain any sensitive data, and maybe encrypt the string until it needs to be read. It tries to solve the same general problem that the SecureString class in the .NET framework does. It is possible to pin data in memory with .NET, so preventing it from being moved around by the GC is possible. I'm sure it is also possible to make it part of the non-paged pool of memory for the app, so it will never be swapped to disk. Pulling the Random out is easy to do, too...however even if all strings were scrambled with the same random data, that wouldn't matter...the original data is still gone (overwriting with random is probably moot, since its overwritten with nils and the length shrunk to 0 after, anyway...there isn't any kind of magnetic residue like there is with a hard drive, so I will probably take the random overwrites out and just use \0). The biggest problem that you mentioned, I think, is the interned strings problem. I am not sure there is a solution to that.
-
Yeah, what they said. Plus I would make the Random a static member of the class rather than creating a new one on each call. I might also use a cryptographic randomizer instead of Random. However, I expect you may be tryingto fix a non-existant problem.
Jon Rista wrote:
the way it works in .NET right now is atrocious
Please explain.
Its atricuous because once the data is in a SecureSring, there is no real way to use it outside of unmanaged code and BSTR...and I try hard to avoid unmanaged code in my projects. It is entirely possible I am trying to solve a non-existent problem. I was just experimenting. ;P
-
I think this would be a bit of a nightmare to manage since string operations usually end up creating more strings. A simple concantenation leaves to the initial strings intact and creates a third. Instead of a string automatically wiping itself at the end of its life, you have to manage that for each and every instance of a secured string.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
I'm not able to say if there are scenarios when this wouldn't work (concerning internal memory handling), but as far as I can see, looks very good. Now you've chosen to do this as an extension, which is good since it can be used for any string. However, would there be a point if you also create a wrapper class for this kind of strings. With the wrapper you could possibly have more control over the string usage and behaviour. For example you could have separate mechanisms to show the string or to modify the string etc.
The need to optimize rises from a bad design.My articles[^]
-
Its atricuous because once the data is in a SecureSring, there is no real way to use it outside of unmanaged code and BSTR...and I try hard to avoid unmanaged code in my projects. It is entirely possible I am trying to solve a non-existent problem. I was just experimenting. ;P
Its atricuous because once the data is in a SecureSring, there is no real way to use it outside of unmanaged code and BSTR...and I try hard to avoid unmanaged code in my projects. The string object is supposed to be immutable; using funny tricks to alter existing string objects is bad mojo since there's generally no way of guaranteeing what references may exist to any particular string. For example, a display routine might decide to keep a cache of strings that have been displayed and their associated bitmaps. Thus, I call the routine to display the word "FOO" and it keeps a reference to the string along with a copy of its bitmap implementation. If the string is later altered to say "BAR", and the routine is later called to display the word "BAR", it may notice that it has "BAR" in its cache and display the cached bitmap (which happens to look like the word "FOO"). If there were more class methods and properties that could operate with StringBuilder objects, then those could be the basis for a semi-secure-string type. Unfortunately, very few classes can accept a StringBuilder directly; nearly all would require first converting it to a normal String, which would in turn throw security out the window.
-
Its atricuous because once the data is in a SecureSring, there is no real way to use it outside of unmanaged code and BSTR...and I try hard to avoid unmanaged code in my projects. The string object is supposed to be immutable; using funny tricks to alter existing string objects is bad mojo since there's generally no way of guaranteeing what references may exist to any particular string. For example, a display routine might decide to keep a cache of strings that have been displayed and their associated bitmaps. Thus, I call the routine to display the word "FOO" and it keeps a reference to the string along with a copy of its bitmap implementation. If the string is later altered to say "BAR", and the routine is later called to display the word "BAR", it may notice that it has "BAR" in its cache and display the cached bitmap (which happens to look like the word "FOO"). If there were more class methods and properties that could operate with StringBuilder objects, then those could be the basis for a semi-secure-string type. Unfortunately, very few classes can accept a StringBuilder directly; nearly all would require first converting it to a normal String, which would in turn throw security out the window.
supercat9 wrote:
nearly all would require first converting it to a normal String, which would in turn throw security out the window.
Correct, which is why I was messing with the idea of wiping the string itself. I basically decided the idea was pointless once someone mentioned interned strings. If a string is interned, there is no real way to know how many references it has, and since an interned string will live for the duration of an applications execution, you'll definitely end up with problems.