At the PDC '03, and the time after it, it seemed like Microsoft was really liking ATI. I remember using their cards a long time ago, and it was a very bad experience. So, I've been quite loyal to nVidia for the past while, since they hadn't disappointed majorly... until a few days ago. I just left for a trip, and was counting on using Remote Desktop to get access to VS, Outlook, etc. while on the road.

I connect to my machine from my laptop. User... pass.. applying settings -- window closes. Try again. On another machine. Try with a different user (perhaps the profile was messed up...). All the same. After login, the window closes.

Google group search for “remote desktop closes”... and tada! Are you using nVidia's drivers? Guess what? Their drivers install a service and yep, that service kills remote desktop. Stop the service, and you're set. Well, I'm 3000 miles away from my computer, so that's pretty hard (two firewalls, so I can't connect to SQL Server and run a extended procedure or likewise).

Apparently, this is nothing that new (judging from Google groups), but I don't remember nVidia mentioning this in their release notes. Why can't hardware vendors just make drivers? That's all I need. Drivers and an optional configuration app. Seems like this trend is only getting worse...

I've been very, very busy lately, and my wrists have been hurting (spend over $100 getting a “keyboard manager”). However, among the things I've been doing, I've been involved in a usability study with the Visual Studio team. Basically, we meet over live meeting with my desktop shared, so they can watch how I use Visual Studio. This helps figure out if I'm using the new features correctly, or if the design could be clearer. I like it cause I can make very direct feedback and hopefully improve the product for others! Speaking of feedback, the new default for strings in Whidbey is maroon (at least on the build I just installed) -- I made this suggestion to someone who works in that area about two months ago -- so they ARE listening! :)

Whidbey has a host of new features. So many aspects have been fixed up so when you use it, you just have to say “Oh sweet, that's nice!”. There's been a lot of coverage of the “big” new features, like generics and in C#, refactorings, and that's well deserved. However, there's been a ton of work on the day-to-day stuff as well. The #1 top thing I miss when using Everett is auto-Intellisense, for lack of a better name. In VS2005, Intellisense activates on a single keystroke (most of the time), and the list is complete: even keywords are listed. I think preprocessor directives are the only things not available (I've put in a wish :)). It might not seem like a big deal, but it is definately the top thing I notice line-by-line when working in VS2003. CodeRush (www.devexpress.com) helps a bit, but still doesn't come close to how great Intellisense is in VS2005.

Ever write a short main method to test something out? You try something, and write the output to the console. Or perhaps you have extra debugging info going to the console while your program runs. I've been annoyed a lot when I run my console app, and VS opens a new console window for 1 second, and then the program closes, and I can't see the result. I also hate having to switch back and forth between VS and the console app while running.

Visual Studio 2005 takes care of this, with the new “Console” debugging window. As far as I can tell, the console streams are mapped to this pane inside Visual Studio, so you can dock it, have it as a document window, or however you want. Afrer your program runs and exits, the data will still be there.

Do note that not all the new Whidbey console features are supported, since it's not a “true” console window (you can't use the Win32 console functions on it). But for basic console work, it does the trick.

Just recently, I had three great things happen. Actually, I think there were some others, but I've since forgotten them (I wanted to write this post a week ago).

1: My wife finally got to Atlanta. After some issues with INS (grrr) and Delta (grrrrr), we finally got her up to Atlanta from Guatemala on a six-month visa. No more sleeping under my desk.

2: Code Center Premium access. I got my smart card and account info, and now I'm in. The complete Windows source code, including the .NET Framework. Now I can browse the source, as well as doing just-in-time source debugging on Windows and .NET. Swweeeeeet. Had I had this years ago, I'd have saved myself so many headaches (as well as written much better code!).

3: Renewal in the Microsoft MVP Program. Lots of goodies (like source licensing), as well as access to a lot of great information and contacts.

On Friday, I had some issues with Visual Studio setup. I was trying to add some features, however VS wasn't liking my MSDN source (I guess I used a different MSI to install before, and the MSDN MSI was different). PSS couldn't resolve it with their cool little MSI tools, so a re-install was in order.

I was hesistant, since I have some add-ons, lots of customizations, and things like VSIP installed. Well, even after the full uninstall-reinstall, all my settings and addons were retained. I'm exceedingly impressed.

I also spent this weekend coding on my wife's laptop. She only has the framework, no SDK, so it was quite an interesting experience. I couldn't use ILDASM (*gasp*), and had no docs. I was also using CSC and Notepad. Getting back into VS2005 feels *really* good now :).

So I've been worried that the NT password hashing calcuation is: MD4(passwordInUnicode). Yes, that's right. No salt or anything. As you might be imagining, this is bad. I was wondering how this can be mitigated, short of extra physical security (smart cards, for instance). I found that there is a way to cipher the passwords on disk: SYSKEY.

SYSKEY is running by default on Windows 2000+ machines. Basically it encrypts the password hashes with RC4, meaning the attacker must break the RC4 encryption. However, by default, SYSKEY runs in Mode 1, which stores the RC4 as an LSA secret, so it's trivial to get it out. So, if someone has physical access to your machine, SYSKEY doesn't do much.

However, there are additional modes. These allow you to use a password to derive the RC4 key. The password must be entered when the machine starts up. The other mode generates a random RC4 key, and stores it on a floppy disk. The floppy must be present when booting.

To enable these, just run SYSKEY (Start -> Run: Syskey). Select the mode [and password]. Enjoy a more secure computer.

I was just opening up some of the BCL code in VS2005. Wow, do I love this product. I just noticed some new things on the document tabs:
  “Close all but this”
  “Show File In Explorer”

When I've got a lot of files open that aren't part of a solution (like the framework sources), that last item is really nice. As is the former item, as you can imagine. Now if I could just get the tabs to open in the right order -- the tabs are organized by some kinda MRU system, which I find rather annoying.

Just 3 out of 10 million new things in the new IDE. Got a cool tip/trick (or a change you dislike) for the Community Technical Preview? Leave a comment.

So, why do we care about multiple iterations, good salting, etc.? Isn't a simple MD5 hash enough?

http://www.whitehat.co.il/forum_viewtopic.php?14.149

Yes, that's right. Rainbow tables (almost 120GB in total), so that passwords like “!BinM,$YuSt.b7“ can be easily cracked -- If you are using LM hashes. The newer NT hashes don't have this problem yet.

That's another thing to consider when determining password strength requirements. Normally we can say “Oh, doing n steps will take at least x time, and passwords expire in x/16 time, so we're safe.“ However, if our apps are designed in a way that allows someone to precompute an attack and make a time tradeoff, our password strength versus time no longer means anything.

Update: Edited article because as far as I can tell (they won't answer my inquiries) these tables do not attack NT hashes, only the weaker LM hashes (no surprise).

I see a lot of articles on hashing passwords, however many of them skip over an important part of setting up this kind of system: iterations. But first, a quick primer on hashing in general.

Hashing is a cryptographic function that takes variable-length input, and creates a constant-length output. The output is commonly called a hash, or a digest. The most common algorithms are MD5 and SHA1. MD5 creates a 128-bit hash, and SHA1 creates a 160-bit hash. There are also SHA256, SHA384, and SHA512, although 384 is pointless, since it's just the SHA512 with some data discarded. It's computationally unfeasible to find two plaintexts that have the same hash output. Hash functions are used in some common scenarios:

1: Creating a digest of a message to ensure the message was not modified (intentionally or unintentionally). Sometimes this is referred to as a checksum. eDonkey is an example that uses MD4 hashes to identify files (and as files are downloaded, they can be checked to be good by computing the hash).

2: Digital signatures, where the hash is encrypted with a the private key of an asymmetric algorithm (like RSA). This can then be decrypted by anyone with the public key, and checked against the computed digest to ensure that something with the private key did “sign” the message, and that the message contents have not changed.

3: Securely storing passwords. Since a hash is a one-way function, it's impossible to *decrypt* the hash and retain the password. Well designed systems will not store plaintext passwords (otherwise someone who reads the database could get your password and do nasty things as “you”). If you ever use a site that sends your current password back to you if you forgot it, then they most likely have a badly designed system (and you should question the rest of their security).

We're going to focus on the password issue. Attackers can figure out a password by computing the hash themselves for a suspected password, then comparing to the actual value. So, while the hash value might be 160-bits, it certainly doesn't take 2^160 steps to find the right password, since many users use weak passwords.

When hashing a password, it's common to add some random bytes to the password that are unique for the user. This is called a salt, and it ensures that for each user has a different hash, even if the password is the same -- since hash(”password”) will always return the same, but hash(”password” + “randomData”) is going to be different. This means that an attacker must compute a separate hash for each possible password, *per user*. This helps stop an attacker from trying to attack all the users at once, since each additional user requires a complete attack (since there's a salt).

However, lets say that the attacker is going after a specific user. If the user picked an easy password, say 6 alphanumeric chars, the password's strength is ~36 bits (35.7 to be more precise, 5.95 bits per char). This is assuming completely random characters are used, which is hardly ever the case. That's not that much work for a attacker, and we're considering 64-bit security (128-bit keys) to be the “required security” level.

However, suppose instead of calculating one hash per password+salt, we take the hash, and re-hash it n number of times, where n is something between 2^14 and 2^18? Well, now the number of steps required per password goes up that much. The 36-bit password now has an effective strength against brute forcing of 2^50 to 2^54. Essentially, by adding 2^18 steps to the hashing, we've added the equivalent of 3 *random* characters to their password.

So, do you need to iterate? Find out your minimum security level (48-bit? 56-bit?). Figure out how many iterations you can perform on your hardware before performance is unacceptable (probably between 2^14 and 2^18). Subtract that from your required level, and you have the minimum password entropy level.

For instance, let's say that I want to have 64-bit security from my passwords. My hardware can do 2^16 iterations without hurting logon times, thus I need 64-16= 48 bits of entropy in each password. This can be accomplished by requiring passphrases consisting of four common words (say a dictionary of 4000). (12 bits per word = 48 bits in the password + 16 for iterations, and I'm set).

Hashing is even more important when you don't have control of how good the passwords are. For instance, you're saving customer's credit card data, and the key is based off their password (so that they MUST login for your system to access that data). In these cases, requiring a complex password might not work for various reasons such as customer pushback, or risk of customer choosing something like your site name or their name as a password. It's important to determine the level of password complexity that will “push users over the edge” - the point when they stop using something remotely random, and start using things like their last name, their SSN, etc. When that point is reached, the entropy of their password is uselessly low.

Now, assuming a semi-casual attacker with a strength of 40 bits. He's got the power to do 2^40 steps of computational work. If your users use 24-bit passwords, their hashes can be broken by this attacker easily. But, with 2^18 iterations, those weak 24-bit passwords now require 2^42 steps, and the hash is saved.

So, there is really no good reason not to do multiple iterations. Even 1024 will provide some strength (equivalent to 2-3 extra characters in the password). In fact, the .NET framework already has a class that does all of this (hashing with whatever algorith, salting, and iterations) for us: System.Security.Cryptography.PasswordDeriveBytes. Use it!

I just got to Atlanta, and the next morning, UPS showed up with my new Sony SDM-S73/B, a wonderful 17” LCD panel (analog). Wow. I've been using CRTs for 18 years, and my eyes hurt.  This panel is such a welcome relief!

Big benefit: no refresh.  I'm really sensitive to refresh rate, and pretty much any CRT running at less than 85Hz gives me a headache within a few minutes. Even though this panel runs at only 75Hz, the way that LCD works means that you don't notice it. It's a solid display that's just... there. Feels like it's just painted on.

Another big benefit: low output. Every CRT I've used, I feel like there's a lot of energy coming towards my eyes. It's a lot to handle, and it's hard on them, thus my articles on using gray. This Sony display has a great “Eco” button that flips between energy levels (both in consumption and output). Thus I can keep my display as low as possible throughout the day and night, and save energy too.

Another nice thing is that the stand makes it very simple to move up and down, so as I change my sitting (slouching?) position, I can make sure I'm straight-on, which is best for ClearType reading. ClearType really makes text look better. Windows Media Video HD looks spectacular on this display. It has a 160-degree viewing angle, so a few people can sit around and watch too.

TigerDirect has them for $450, which is about $50 cheaper than anywhere else I found them.

I tried out Cyberlink PowerDVD 5.0.  The install program displayed all its text as question marks and garbage text.  This normally happens if a font doesn't support extended characters (you get ?? instead), or if codepages don't match up (they don't use Unicode, and instead use a DBCS, which gives all the wierd looking garbage on my codepage).  Why, oh why, would a program that's supposed to be “multilingual” mess this up?

Turns out, my formatting settings are set to Korean.  Everything else is currently in English (debugging cryptic Javascript errors in Korean was too hard).  So the PowerDVD software decides that if my formatting settings are for a certain region, I must be using that language.  See the jump in logic?  Changing my regional settings to English (United States) makes it all good again.  Who codes this stuff?