Crypt-compatible Passwords in C#

For hashing passwords I usually use SHA-256 PBKDF2. No project I ever made needed anything better than this. There is only one problem with this hashing function - it is not really compatible with anything.

Kinda unofficial standard for password hashing is an Unix crypt function. You can recognize its passwords by following format: $id$salt$hash. It was originally used for hashing user password on *nix systems but with time it became common format for other usages also.

After scouring Internet to find C# implementation I decided to code it myself. It seems that C# porting stopped for everybody with MD-5 variant of crypt. While that lowest common format supported quite a few use cases, I wanted to use a bit newer SHA-512 based hashing. It should have been just an hour of coding. Eventually it took me almost eight to get it working.

Few things took me by surprise during development. I was surprised how many pointless steps were in SHA-256/512 hash creation. Best example would be base-64 implementation that not only uses incompatible character set but it also shuffles bytes around before encoding. These steps don’t add any security nor they serve to slow attacker.

Lack of proper specification for MD-5 hash was annoying more than anything else. For most of part I used just specification for SHA-256/512 combined with reference implementation in C. Yes, it wasn’t mission impossible, but lack of description for something that is part of every Unix/Linux system for more than decade is an annoyance at best.

Sample supporting MD-5 ($1$), Apache MD-5 ($apr1$), SHA-256 ($5$) and SHA-512 ($6$) password generation is available for download.

PS: If you are interested in test cases for it, you can check Medo.dll repository.

Naughty ArgumentException

Writing a function you probably write following checks as a reflex:

void DoSomething(string argument) {
    if (argument == null) {
        throw new ArgumentNullException("argument", "No nulls allowed!");
    }
    if (argument == string.Empty) {
        throw new ArgumentOutOfRangeException("argument", "No empty strings!");
    }
    if (Environment.Foo && (argument == "bar")) {
        throw new ArgumentException("argument", "Something else!");
    }
    ...
}

Yep, there is an error in third “throwing”. For some unknown reason ArgumentException needs parameters in a different order. Correct statement would be:

    ...
        throw new ArgumentException("Something else!", "argument");
    ...
}

What will happen if you mess it up?

Well, nothing much. Exception will still be thrown and your code should be fine. You will see wrong exception text but any stacktrace will probably lead you to correct spot in code.

But it looks ugly.

Reader Is Gone

Few days ago Google made announcement that Google Reader is going the way of dodo. Personally I was quite annoyed with this because it was my RSS reader of choice, but there is enough time to search for alternative.

There were few reactions to this decision but most of them stayed in realm of realism. And then came Dvorak with his suggestion of Google releasing source code to public domain. Regardless of wishful thinking, this is never going to happen.

Google Reader is an old product and I can guess that its backend it very much reliant on Google’s infrastructure. Releasing it into wild would require quite a lot of work to make internal dependencies go away. Company that is closing down a product will not spend their engineers time to prepare product for future competitor.

Nor should it. Nobody expected WordPerfect to become open source as it was dying. And that was an excellent program that had a lot of users. Why would expectation be different for any other program just because it is on web? And don’t give me that crap about being able to use last version indefinitely. When program dies everybody switches to something else regardless of how good the last version was.

Even if it went open source I don’t think it would stay the Reader we know. First it would lose its simplicity. Everybody would add a feature or two to solve their particular problem. Lean Reader would soon start to get some fat and it would go the way of Firefox - nice browser that got way too much configuration options with time.

Google Reader is dead. Face it.

PS: Yes, I think that Google is being a bit evil. But it is not their first time nor it will be the last.

Changing Network Name (Etc.)

As I was playing with my wireless router, I noticed that Windows started referring to my text network with number two (2) in suffix. Each visit to Network and Sharing center resulted in annoyance since my good old MedvedAlt network was now named MedvedAlt 2 without any obvious way to change it.

We start adventure by entering gpedit.msc to Windows start menu. This will open Local Group Policy Editor in which we have to navigate to Computer Configuration, Windows Settings, Security Settings, Network List Manager Policies. There we can see our network in all its glory. All that is left at this point is to go into Properties and change Name setting from Not configured to whatever name we prefer.

TextBox With a Cue

On web it became very popular to have gray, watermarked, text that offers a cue for filling out a field. As you start writing, cue disappears.

For a while now, Windows have full support of this feature. However, Windows Forms in .NET framework are bit behind. Fortunately implementing this feature is not really hard. All we need is property (e.g. CueText) in a class inherited from TextBox.

Setting value is done by sending a EM_SETCUEBANNER message to TextBox:

NativeMethods.SendMessage(this.Handle,
                          EM_SETCUEBANNER,
                          new IntPtr(1),
                          new StringBuilder(value));

There is no need to check this function for success. If visual styles are turned on, it will not fail. And even if it fails, there is not a thing we can do to fix it. Ignoring result code is as good solution as any.

Retrieving value via EM_GETCUEBANNER is a bit more involved:

var text = new StringBuilder(256);
var res = NativeMethods.SendMessage(this.Handle,
                                    EM_GETCUEBANNER,
                                    text,
                                    new IntPtr(text.Capacity));
if (res.ToInt64() != 0) {
    return text.ToString();
} else {
    return null;
}

This time check for valid result is warranted. If result is good, string will be returned. Otherwise, null gets to mess things up.

These few lines (along with Interop definitions) are all that is needed for this useful functionality.

Sample project is available for download.