|
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.
|
|
|
|
|
Indeed, to make it truely viable it would probably need to be a wrapper class, or perhapse have both the SecureWipe extension and a SecureString that handles copy, concat, etc.
|
|
|
|
|
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.
|
|
|
|
|
It is easy enough to add more extensions, such as SecureCopy, SecureCat, SecureModify, etc. that automatically wipe the old versions after the new is created. It might be better to have a whole SecureString class for it rather than extensions, though.
|
|
|
|
|
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. 
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Does anyone know how to set TabStop in vb.net 2003. I want to set vbTab(0) = 28 and then vbTab(1) = 3 and so on.
|
|
|
|
|
Never used it but list box has CustomTabOffsets property which returns a collection of offsets. Perhaps it would help.
|
|
|
|
|
Mika - Thanks for the interest to resolve this issue.
I used this method below. (Item # from the String format,tab# to stop on the listbox) If (#,-#) that means to list the text on left align and if (#,#) is to list the text on right align.
Dim strfmt As String = "{0,-28}{1,-6}{2,-17}{3,-4}{4,-24}{5,-24}{6,-35}{7,-35}{8,-35}{9,10}{10,-8}{11,-10}{12,-6}{13,-3}{14,-35}{15,-7}{16,-3}{17,-35}{18,-6}{19,-5}{20,-67}{21,-35}{22,-216}{23,-6}{24,-6}{25,-6}{26,-6}{27,-6}{28,-6}{29,-6}"
For Each dr In dt.Rows()
Me.ListBox2.Items.Add(String.Format(strfmt, "", (dr("CB12")), "", (dr("CB13")), "", (dr("CB14")), (dr("CB15")), (dr("CB16")), "", (dr("CB17")), "", (dr("CB18")), "", (dr("CB19")), (dr("CB20")), (dr("cb21")), (dr("CB22")), (dr("Cb23")), "", (dr("cb24")), "", (dr("cb25")), "", (dr("cb26")), (dr("cb27")), (dr("cb28")), (dr("cb29")), (dr("cb30")), (dr("cb31")), (dr("cb32"))))
Next
|
|
|
|
|
Did you try the CustomTabOffsets and add those tab positions to the collection?
I'm just wondering that you have quite a lot of 'columns' you define and use. Could it be possible to use listview instead. I think it would be a lot easier to handle the visualization with that since you can define actual columns in listview and use them.
|
|
|
|
|
If you can show me to set the tabbing in the listbox I would appreciate it. Yes I do have a lot of tab stops.
|
|
|
|
|
I would just like to say how much I loathe and detest ClickOnce - does it actually work?
|
|
|
|
|
Yup, works great if you only need to deploy (and regularly update) a single executable. It's a cool feature if you only use it to distribute prototypes across your LAN.
I haven't used it for anything complex though - InstallShield does it's job so well that I'm not going to frustrate myself with complex ClickOnce-setups 
I are troll
|
|
|
|
|
I have some different requirements for my application. My application generates a well formatted XML which needs to be stored in database as string data or as file in some version controlled system. I am planning to create provider factory that will generate an object to interact either database or version control system. I like to control this thru my web.config file. How can I achieve this?
M.Sendilkumar
|
|
|
|
|
One way to do this would be through a pattern called Dependency Injection. Microsoft have released an application block called the Unity Application Block[^] which you can use to this end.
|
|
|
|
|
As Pete said, The Unity Application Block should help.
Just to save your fingers this CP article[^] might help get a handle on it.
Henry Minute
If you open a can of worms, any viable solution *MUST* involve a larger can.
|
|
|
|
|
Dear all :
I create a simple code (window application) like following
Private Sub Button1_Click()
Dim Obj As Object
Dim asm As Assembly = Assembly.LoadFrom("TestApp.dll")
Dim ty As Type = asm.GetType("TestApp.appServ")
Obj = Activator.CreateInstance(ty)
Dim Istring As String = Obj.funct()
MessageBox.Show(Istring)
Obj.Dispose()
GC.SuppressFinalize(Obj)
Obj = Nothing
end sub
while TestApp.dll code follow that
using System;
using System.Collections.Generic;
using System.Text;
namespace TestApp
{
public class appServ : IDisposable
{
private bool disposed = false;
public string funct()
{
return "aad";
}
~appServ()
{
// call Dispose with false. Since we're in the
// destructor call, the managed resources will be
// disposed of anyways.
Dispose(false);
}
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// dispose-only, i.e. non-finalizable logic
}
// shared cleanup logic
disposed = true;
}
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
GC.Collect();
}
}
}
Before the button click the "TestApp.dll" allow be overwrite
but after button click , the file is locked until the main program exit.
Can anyone tell me how to solve it ?
Thanks
Michael 
|
|
|
|
|
Michael Yip wrote: Can anyone tell me how to solve it ?
AFAIK, you can't. Once a process loads a .DLL, the file stays locked for the lifetime of the process that loaded it, even if you dispose of all objects created from it and even if you load the .DLL into another AppDomain.
|
|
|
|
|
You can't. A dll remains locked until the process that created it ends. If you must have it terminate, you need to load the DLL into a separate AppDomain (which fires off a separate session), and then unload that AppDomain once it's finished with.
|
|
|
|
|
Dear Pete O'Hanlon
Do you mean load all dll in another sub domain , and then terminal main domain ?
If this main domain have reference serval. that mean I need clone all dll into new domain and then kill my current domain
Thanks
|
|
|
|
|
You only kill the other domain, not the primary domain. If you need to have dynamic load/unload capability for "plugin" assemblies, the only way to do that is to have your primary domain spawn another AppDomain, load the pluggable assemblies into that second domain, and unload the second AppDomain after your done using the dynamic assemblies. You can't kill your primary domain, because that would kill your whole app.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
