A collection of projects I’ve developed over the years that have proved valuable at one time or another. All projects posted here are tested and currently used in production software. The source code is all available under the Appache 2.0 License and can be obtained either directly here or from code.google.com. Defects, bugs, and wish lists can be posted at the same location. Feel free to browse around the various project links above or cruise through the various postings below.
Most people I’ve seen online compute a simple hash of password + salt for persistence and authentication. This is the accepted standard in a straight-forward solution:
byte[] Hash(string password)
{
byte[] pass = System.Text.Encoding.UTF8.GetBytes(password);
//Create the salt to use
byte[] salt = new byte[32];
new RNGCryptoServiceProvider().GetBytes(salt);
//Create the hash of password and salt
HashAlgorithm hashAlgo = new SHA256Managed();
hashAlgo.TransformBlock(salt, 0, salt.Length, salt, 0);
hashAlgo.TransformFinalBlock(pass, 0, pass.Length);
byte[] hash = _hashAlgo.Hash;
hashAlgo.Initialize();
//Copy the combined salt + hash to a single array
byte[] result = new byte[salt.Length + hash.Length];
Array.Copy(salt, result, salt.Length);
Array.Copy(hash, 0, result, salt.Length, hash.Length);
return result;
}
The only deviation i’ve seen from this is to either use existing data (say a primary key in the database) for the salt, or to ‘hide’ the salt at some offset in the result. Both of these ideas are valid yet amount to not much more than a little obfuscation. I don’t recommend it.
Now if you REALLY want to secure your passwords and/or protect against brute force attacks there is another approach. The approach is quite common in generating crypto keys from passwords but can just as easily be used for hashing the password. The idea/concept is expressed in RFC2898 by the introduction of the iteration count. By introducing this into the password hash we increase the computational complexity required to test a password by several orders of magnitude. The straight-forward way of achieving this in the BCL is as follows:
byte[] Hash(string password)
{
//Create the salt to use
byte[] salt = new byte[20];
new RNGCryptoServiceProvider().GetBytes(salt);
//Combine the salt with the iteration-count
byte[] iterationBytes = BitConverter.GetBytes(1010);
byte[] iterationSalt = (byte[])salt.Clone();
for (int i = 0; i < iterationSalt.Length; i++)
iterationSalt[i] ^= iterationBytes[i % iterationBytes.Length];
//Create the hash of password and salt
DeriveBytes deriveBytes = new Rfc2898DeriveBytes(password, iterationSalt, 1010);
byte[] hash = deriveBytes.GetBytes(20);
//Copy the combined salt + hash to a single array
byte[] result = new byte[salt.Length + hash.Length];
Array.Copy(salt, result, salt.Length);
Array.Copy(hash, 0, result, salt.Length, hash.Length);
return result;
}
This will work very well but will be more costly to calculate than the first algorithm. I would not want to use this in a system that verifies passwords on every request (i.e. Basic Auth over SSL); however, for token-auth systems this will prove much more durable to brute force attacks. By combining the iteration count to the salt (or key) you make the attacker repeat the entire iteration sequence for each iteration count attempted. This makes it significantly more difficult for them to steal the password hashs and crack the passwords without also stealing the software or otherwise knowing the iteration count. Even knowing the iteration count it’s now much more expensive to compute each attempt at matching an entry in their password dictionary.
Recently I’ve added the PasswordHash class to wrap up some of this behavior. Note that this class does not combine the iteration count with the salt, yet still provides significant security benefits over a simple hash.
So recently I’ve been working heavily with some of the cryptography stuff in .Net and adding a large amount of it to my open source library. One of the many things I needed to perform was simply encrypting and decrypting a piece of data with a password.
It seems everyone out there is using Rfc2898DeriveBytes by now and not using the older PasswordDeriveBytes. So it’s use is simple enough, construct it with a password, ask it for a number of bytes, and off you go. When things get interesting is correctly providing salt to the derived bytes algorithm. I didn’t want to deal with this all over my code and thus built the PasswordKey class. It auto-magically prepends the salt to the stream when encrypting data. When decrypting data it reads the salt, generates the key, and then decrypts the data.
At first everything went well, it seemed to work and, as per my norm, I quickly got my unit tests pounding on the implementation. Somewhere along the way though I must have used the Rfc2898DeriveBytes class in a way that was not expected as when I began running in release (optimized) mode I started seeing strange results. The tests were generating 32-bit keys with the same password, iteration, and salt combinations and were generating different keys? The funnest part was they only differed after the first 20 bytes. How could this be? If the input was wrong there is almost no likelihood the first 20 bytes would be the same, so how did I fail? I looked and looked, googled and googled some more. Read nearly every line of code in the class using Reflector.Net, nothing. Still to this day I don’t know why it’s breaking, I do know I can get two identical 20-byte keys, or two identical 40-byte keys, but I still get two different 32-byte keys… What should I do? Well I came up with two possible solutions:
1. The first ‘fix’ for this issue resulted in the PBKDF2 class that derives from Rfc2898DeriveBytes. Then by overriding the GetBytes() method I can always pass a value of 20 to the actual GetBytes() base method:
public override byte[] GetBytes(int cb)
{
byte[] buffer = new byte[cb];
for (int i = 0; i < cb; i += 20)
{
int step = Math.Min(20, cb - i);
Array.Copy(base.GetBytes(20), 0, buffer, i, step);
}
return buffer;
}
2. Then I started debating the value of using a 20-byte hash to generate 32 bytes of data. Seemed like this algorithm was just as applicable with any size hash right? Sure enough… So the second, and finally preferred solution was to recreate the algorithm with a variable hash algorithm. This gave birth to the HashDerivedBytes<THash> implementation which accepts THash to be any HMAC (Keyed hash) derived implementation. With this I’m able to force the use of the managed SHA256 hash routine and elevate the iterations by nearly an order of magnitude without substantial performance loss. In the end I’m pleased with the implementation and can verify it’s compliance with the original algorithm by comparing it’s output using SHA1 with that of the original Rfc2898 and produce compatible results.
Anyway if you have problems with the Rfc2898DeriveBytes class I’d like to hear from you just to make sure I’m not crazy. And now you know of two possible solutions if you do have problems ;)
Changes in this version:
This plugin should now be functional on 64-bit installations of TortoiseSVN, use the following installation:
http://code.google.com/p/csharptest-net/downloads/detail?name=SvnPluginInstall-x64.msi
Let me know if you have any difficulties.
As promised in the previous post “How to implement a generic Shallow-Clone for an object in C#” this will demonstrate deep-cloning objects that don’t explicitly support the behavior.
Before I continue I will again state that I don’t recommend this approach. It will be many times slower than a properly implemented Clone() and can cause rather strange side-effects. For instance, deep-cloning a tree of objects that hold reference to a singleton service class would result in cloning that singleton. This problem simply stems from the fact that no generic code can have enough knowledge about the internal structure of classes to be able to accurately guess when and when not to clone a member reference. Thus if you going to code the logic of which members to clone or not, it’s best done in the objects themselves and is the primary reason I say a generic deep clone is a bad idea. Even if you don’t currently have a reference to a singleton now, what happens when someone adds one to the object graph? How will your application behave?
So with this established as a bad idea it is with great trepidation that I demonstrate how to achieve this. To start with let’s demonstrate usage in the Library:
using CSharpTest.Net.Cloning;
//Uses serialization API if available or member-wise if non-serializable
using (ObjectCloner cloner = new SerializerClone())
fooCopy = cloner.Clone(foo);
// 3.5 can use extension method instead of the code above:
fooCopy = foo.DeepClone();
//To ignore serialization routines, use the following:
using (ObjectCloner cloner = new MemberwiseClone())
fooCopy = cloner.Clone(foo);
Implementation details, there are not a lot to share, you can see the source easily enough at:
http://code.google.com/p/csharptest-net/source/browse/#svn/trunk/src/Library/Cloning
There are a few things worth pointing out. The ObjectCloner provides a base-class that handles the object graph and a few well-known types (delegates, arrays, primitives, etc). Derived from this is the MemberwiseClone class which provides a basic ‘memory copy’ type of copy operation. Again deriving from this is the SerializerClone which implements a pseudo serialization routine by attempting to mimic the .Net serializer’s default implementation. This results in three possible types of copy operations:
1. If ISerializable is implemented it will be used, allowing customization of the copy.
2. If [Serializable] decoration is present the FormatterServices.GetSerializableMembers is used to allow respecting the [NonSerialized] attribute.
3. Lastly if the object doesn’t support serialization a straight member-by-member copy is made.
This continues throughout the object graph until all object members have been copied into the new tree. Finally if appropriate calls to IDeserializationCallback will be made just prior to the top-level instance being returned.
One thing of note is that the object graph is made public to allow preventing some instances from being copied. For instance if you want to copy foo’s complete object graph except for any instances of ‘bar’ then you would do this:
using CSharpTest.Net.Cloning;
using (ObjectCloner cloner = new SerializerClone())
{
// maps instances of bar to itself:
cloner.Graph.Add(bar, bar);
fooCopy = cloner.Clone(foo);
}
Changes in this version:
My last post reguarding “Deadlocks and other issues with Invoke / BeginInvoke” was something of a rant on the subject of WinForms and multi-threading. I thought I’d post on the useage of the solution that was presented originally on the stackoverflow article. The following defines the interface portion of the class:
public class EventHandlerForControl<TEventArgs> where TEventArgs : EventArgs
{
public EventHandlerForControl(Control control, EventHandler<TEventArgs> handler);
public EventHandlerForControl(Control control, Delegate handler);
public void EventHandler(object sender, TEventArgs args);
}
Using this class is incredibly easy. Let’s assume our form is creating a ‘worker’ object and wants to know when some value has changes via an event. We simply need to modify the subscription to the event.
The wrong way:
class MyForm : Form
{
public MyForm()
{
_worker = new Worker();
_worker.OnUpdate += this.Worker_OnUpdate;
}
private void Worker_OnUpdate(object sender, EventArgs e)
{
if (this.InvokeRequired)
this.Invoke(new EventHandler(Worker_OnUpdate), sender, e);
else
;//whatever
}
}
Now we just do the following with the help of EventHandlerForControl:
The right way:
class MyForm : Form
{
public MyForm()
{
_worker = new Worker();
_worker.OnUpdate += new EventHandlerForControl<eventargs>(this, this.Worker_OnUpdate).EventHandler;
}
private void Worker_OnUpdate(object sender, EventArgs e)
{
;//whatever
}
}
Now whenever the event OnUpdate is fired it is automatically marshaled to the correct thread no special handling is needed. You can also be certain that either the call is successfully made or an exception will be thrown to the caller.
EventHandlerForActiveControl<T> - Use this class if you do not want an exception thrown when when the target control is not available. The method will not be called when the control is not active.
ForcedEventHandlerForControl<T> - Use this class if you do not want an exception thrown when when the target control is not available and you still want the method to execute.
All of these are defined here if you just want the source code.
Let’s face it, using the System.Diagnostics.Process to run a process and capture the output is not as easy as it should be. People often get it wrong without realizing it. Adding to the complexities can be reading both the standard output as well as the standard error stream. To put this to bed once and for all here is the ‘right’ way all wrapped up in a helper class ProcessRunner.
Usage Example:
using CSharpTest.Net.Processes;
partial class Program
{
static int Main(string[] args)
{
string path = "C:\\MyProject";
ProcessRunner run = new ProcessRunner("svn.exe", "update", "{0}");
run.OutputReceived += new ProcessOutputEventHandler(run_OutputReceived);
return run.RunFormatArgs(path);
}
static void run_OutputReceived(object sender, ProcessOutputEventArgs args)
{
Console.WriteLine("{0}: {1}", args.Error ? "Error" : "Output", args.Data);
}
}
For many years (more than I care to remember) I have continually written code to provide command-line behavior over and over again. On occasion I would get fancy in one project or another and build something sorta-generic; however, every time it came to creating the next command-line tool I started from scratch. Finally I said “NO MORE!”
The result of that was the CommandInterpreter class. What does it do? Well you give it a System.Type and it will create ‘commands’ from all public static methods, or give it an object instance and it will create ‘commands’ from all the public instance methods. With these commands you can have a fully operational command-line application complete with help in one line of code:
using CSharpTest.Net.Commands;
static class Program
{
static void Main(string[] args)
{
new CommandInterpreter(typeof(Commands)).Run(args);
}
}
For this example let’s pretend we have the following ‘Commands’ class:
static class Commands
{
public static void DoSomething(string whoAreYou, int repeatMessage)
{
for (int i = 0; i < repeatMessage; i++)
Console.WriteLine("Hello {0}, how are you today?", whoAreYou);
}
}
Now let’s see what we can do:
C:\Test>Sample.exe help
Commands:
DOSOMETHING: Some descriptive text
HELP: Gets the help for a specific command or lists available commands.
C:\Test>Sample.exe help dosomething
DOSOMETHING [/whoAreYou=]String [/repeatMessage=]Int32
descriptive text
Arguments:
[/whoAreYou=]String argument description
[/repeatMessage=]String argument description
C:\Test>Sample.exe dosomething roger 2
Hello roger, how are you today?
Hello roger, how are you today?
So this is where your jorney begins and mine ends, there is so much more you can do with this class I can’t put it all here … even though I will still try:
A brief how-to on providing user settings in your application.
First, if you want to provide defaults, you want to add the following to the application’s configuration:
Notice there are two levels of the <add> tag, one is ‘global’ settings, the other is segregated off in a named section.
Reading this information is along the following lines:
//reads the current user's settings UserSettingsSection settings = UserSettingsSection.UserSettings; //access a global setting: Assert.IsTrue(settings["a"] == "b"); //access a setting from within the section "c" if(settings.Sections["c"] != null) Assert.IsTrue(settings.Sections["c"]["x"] == "y");
To update the information you need to perform the following:
//Open the configuration Configuration cfg = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal); UserSettingsSection settings = UserSettingsSection.UserSettingsFrom(cfg); //Push the settings in settings["a"] = "b"; settings.Sections["c"] = new UserSettingsSubSection(); settings.Sections["c"]["x"] = "y"; //save the configuration cfg.Save();
Get the source code or download binaries.
