This is the eighth (and hopefully final) installment in a series about creating a C# password utilities library.

But first, we interrupt our scheduled programming to bring you the latest offender in end-user personal data storage. Sony's Playstation Network and Qriocity services have recently suffered a major intrusion that exposed personal data for its 77 million users. It's not completely clear from their FAQs, but it appears that the user passwords weren't hashed or encrypted, but instead stored in plain text. This makes the Sony rootkit fiasco positively tame in comparison.

Back on topic: all that remains is to write a console program that demonstrates some of the functionality implemented in the password utilities library. The Main method is hopefully self-explanatory. 

We start by setting the console so that it can display UTF-8 symbols, a necessity given that this library can generate Unicode passwords. Note that you need to set the console to use a font that can display Unicode characters - I use Lucida Console.

Check the die for modulo bias.

Generate some random passwords and hash them, then display the combined password/hash information entropy.

Generate some passwords, hash them, then verify the password hashes.

You can download a Visual Studio 2005 solution containing the password utilities library and the console test program. I chose VS2005 as the lowest common denominator - you should upgrade as appropriate to your environment. Edit: I've cleaned-up the source a little and upgraded it to a Visual Studio 2010 solution using .NET Framework 4.0.

The final step is to measure the information entropy of specific passwords and their hashes. In this context, entropy is a measure of unpredictability. For randomly-generated passwords, the information entropy (measured in bits) is a reasonable proxy for password strength.

For example, a password with 42 bits of entropy is as strong as a string of 42 bits chosen randomly. An attacker would need 2⁴² attempts to exhaust every possibility of finding this password by brute force. Adding an extra bit of entropy doubles the number of guesses required, making the attacker's task twice as difficult.

The standard formula for calculating the information entropy of a random password is L * ( logarithm N / logarithm 2), where L is the number of symbols in the password and N is the number of possible symbols. The result is expressed in bits. The entropy of a password hash is calculated using a similar formula, logarithm N / logarithm 2, where N is the number of hash iterations. 

The EntropyChecker.cs class can measure the entropy of:

• A machine-generated password where the password policy is known.
• A machine-generated password where the policy is not known.
• A password generated by a human.
• A password hash, based on the number of hash iterations.

The following code measures the entropy of a machine-generated random password where the password policy is known. In this case, the password itself isn't required. The password policy knows the allowed password symbols, and that list combined with the password length is enough to calculate the password strength.

The following code measures the entropy of a machine-generated random password where the password policy is not known. In this case, the password is analysed to discover which symbols it contains. Based on that, the list of allowed symbols is estimated, and then the entropy can be measured as before. One caveat is that if the code detects a non-ASCII symbol in the password, it has no way of knowing what range of non-ASCII symbols was used to construct the password. So it assigns an arbitrary number of non-ASCII symbols, in this case 100.

The following code measures the entropy of a human-generated password. A password generated by a human is always weaker than a random password. Users rarely make full use of the larger symbol sets when creating passwords. For example, hacking results obtained from a MySpace phishing scheme in 2006 revealed 34,000 passwords. Only 8.3% used non-alphanumeric symbols. The most common passwords (in descending order) were password1, abc123, myspace1, password, blink182, qwerty1, fuckyou, and 123abc. The Password Recovery Toolkit would have been able to crack 23% of those 34,000 MySpace passwords in 30 minutes, and 55% in 8 hours.

To deal with this, the code uses a NIST formula contained in a Wikipedia article on password strength. The result is that human passwords always show as much weaker than machine-generated random passwords.

The following code measures the entropy of a password hash, based on the number of hash iterations. As an example, the default hash policy uses 2¹⁴ hash iterations, which increases the password's entropy by 14 bits. According to Moore's Law, each extra bit of entropy provided by the hash means an extra 18 months to crack the password in the same time as today. So it will be 21 years (14 x 18 months) before the iterated hash can be cracked in the same time as the raw password can be cracked today.

Finally the information entropy in bits is converted to an estimated password strength in 2011 terms. This conversion is really a guesstimate, and will be increasingly inaccurate as hardware scales up (CPU/GPU speed, memory speed/size) and out (grids, etc).

• In 1998, the EFF cracked a 56-bit key in 56 hours using specialised FPGA hardware.
• In 2002, distributed.net cracked a 64-bit key in 4 years, 9 months, and 23 days.
• In 2010, distributed.net estimated that cracking a 72-bit key using current hardware would take about 48,712 days or 133.5 years.
• NIST recommends 80 bits for the most secure passwords.

You can view and download EntropyChecker.cs. The complete password utilities library, including this class, will be posted at the end of this series. This completes our analysis of the library itself. In the next installment, we'll look at a console program that tests all of the functions of this library.

The next step is to implement the password salting, hashing, and stretching.

The constructors of the HashGenerator.cs class let you specify the default hash policy or your own policy. As discussed last time, a policy consists of the salt length in bytes, the hash length in bytes, and how much the password should be stretched (number of hash iterations).

Once you've specified the password, the code creates a random salt and passes the password, salt, and number of hash iterations into a method that creates and returns the salted hash.

To create the random salt, we go back to our old friend RNGCryptoServiceProvider, the basis of the dice implementation that we discussed earlier. The GetBytes function returns a set of cryptographically-secure random bytes. It's actually overkill for this purpose, because the salt randomness doesn't need to be that secure.

To create the salted hash, we're going to use the .NET Framework's implementation of a key derivation function called PBKDF2, also published as RFC 2898. PBKDF2 has some useful properties: you can use a salt, you can define the hash output size, and you can configure the slowdown factor by specifying the number of iterations over the hash function.

At this point, we're done with the salting, hashing, and stretching. It would be nice to return the salt, the hash, and the number of hash iterations in a single package. This package can then be stored, and used later to verify whether a password and stored salt matches the stored hash. To do this, we return a string containing an ASCII string in the format XXXX.9999.YYYY. XXXX is the salt encoded as a base-64 string, 9999 is the number of iterations of the hashing function, and YYYY is the hash encoded as a base-64 string.

The final step is to verify a password against a stored salt and hash. To do this, you specify the password along with the stored salt, hash, and number of iterations. The latter can be passed as a single package in the format XXXX.9999.YYYY as discussed above. Or you can pass everything as separate parameters. The salted password is iteratively hashed before being compared to the supplied hash. If the two hashes match, the password is correct.

You can view and download HashGenerator.cs. The complete library, including this class, will be posted at the end of this series. In the next installment, we'll look at the EntropyChecker.cs class, which attempts to measure the information entropy of randomly-generated and human-generated passwords. The information entropy is a reasonable proxy for the password strength.

The next step is implementation of a password hash policy. Specifically, a policy that covers salting, hashing, and stretching.

A password salt is a set of (usually random) bits that are the secondary input to a one-way hash function - the first input being the password itself. Salting protect you against pre-computed dictionary attacks, otherwise known as rainbow tables. Because a rainbow table is made by straightforward hashing of a large dictionary of words, passwords, and passphrases, it can't be used where every password has been hashed with a different salt.

There's a common misconception that password salts need to be kept secret. This isn't true - the only protection that salting provides is against rainbow tables. Even if every salt is known, it would take far too much space to create a rainbow table covering every combination of password and salt.

Hashing a password involves a one-way function that converts an (optionally salted) password into a fixed-size set of bits. The idea is that you always store the password hashes rather than the passwords themselves. After storing a password hash, you can then verify the associated password, by hashing it and then comparing with the stored hash. The benefit of using password hashes is that because the hashing function is one-way, it's not possible for an attacker to reverse-engineer a password from its hashed value.

One issue with using a cryptographic hashing function such as SHA-1 for password storage is that it's designed to run very fast. Speed is exactly what you don't want in a password hash function, because it means that offline attacks can be executed very fast. Ideally you want to slow down the hashing process from microseconds to as long as 1 second or more. Somebody using a password won't notice a 1-second delay in the login process, but an attacker has no hope of brute-force password cracking if restricted to 1 attempt per second. To slow down the hashing process, we want to use some form of key stretching.

We could stretch the key by simply repeating the hash function multiple times in a loop. Alternatively we could use a hash function that has a slow setup time, for example Blowfish. As we'll see in the next installment, the method I'm going to use involves a key derivation function called PBKDF2, also published as RFC 2898. PBKDF2 has some useful properties: you can use a salt, you can define the hash output size, and you can configure the slowdown factor by specifying the number of iterations over the hash function.

To create the password hash policy, you need to supply the number of required hash bytes, the number of required salt bytes, and the number of times that the hash function should be applied. The minimum hash size allowed in this implementation is 20 bytes (160 bits), because that's the output size of the hash function I'm going to use (HMAC-SHA1). The minimum salt size allowed is 8 bytes (64 bits), as that's the lowest size currently considered to give good protection against attacks using rainbow tables. The minimum number of iterations over the hash function is just 2, but the default policy uses 2^14, which is 16,384 iterations. Note that 2^X iterations increases protection (information entropy) against a brute-force attack by X bits. So the default iteration count of 2^14 is the equivalent of adding two extra characters to the original password.  

You can view and download HashPolicy.cs. The complete library, including this class, will be posted at the end of this series. In the next installment, we'll look at the hash generator class.

• Specifying password policies that can match most application requirements.
• Generating cryptographically-secure random passwords that satisfy a specified password policy.
• Measuring the strength (or more precisely, information entropy) of human-generated and machine-generated passwords.
• Using random salts and key stretching to make password hashes more secure than the original passwords.
• Measuring the additional strength added by iterative salted hashes. 
• Timing the password generation and password hashing processes.

Now that we have a PasswordPolicy class and a Die class, the actual password generation process is very straightforward.

We first need to know the password policy, and then roll a die which has the same number of sides as the number of symbols in the policy's acceptable symbols list. The roll result is used as an index into the symbols list, and the symbol at that position becomes the next character in the password. Repeat for as many characters as the password needs - again, this is defined by the password policy.

Most password policies give a wide choice in the password length. In these cases, the die can be used to pick a random actual length between the minimum and maximum password lengths permitted by the policy.

As each password is chosen randomly, it may not match the current password policy. In this case, the password is thrown away and a new one is generated. This continues until a password is found that matches the policy. In the case of a particularly draconian policy, this may take a significant number of attempts. As the current code generates around 20,000 passwords a second, this brute-force approach is not likely to cause a problem.

This method is at the heart of the PasswordGeneration class. It accepts a password policy, starts the timer, chooses the password length at random within the policy limits, then keeps generating passwords until it finds one that satisfies the specified password policy. Then the timer is stopped, the time it took to generate the password and the number of passwords rejected by the policy are both stored, and finally the newly-generated password is returned:

The only other interesting method in this class is the one that calculates the password information entropy. For a password randomly-generated by a machine, entropy is a good proxy for the password's strength. Later in this series, we'll look at the class that calculates the entropy of machine-generated and human-generated passwords:

You can view and download PasswordGenerator.cs. The complete library, including this class, will be posted at the end of this series. In the next installment, we'll look at the hash policy class.

• Specifying password policies that can match most application requirements.
• Generating cryptographically-secure random passwords that satisfy a specified password policy.
• Measuring the strength (or more precisely, information entropy) of human-generated and machine-generated passwords.
• Using random salts and key stretching to make password hashes more secure than the original passwords.
• Measuring the additional strength added by iterative salted hashes. 
• Timing the password generation and password hashing processes.

To generate random passwords, you obviously need a good source of random numbers. To generate genuinely random numbers, you need access to special hardware or a subscription to a site like random.org. Failing that, you're restricted to using a pseudo-random number generator (PRNG for short). This works just fine for password generation as long as you have a suitable source of information entropy. Enter a .NET Framework class called RNGCryptoServiceProvider, which is a cryptographically-secure pseudo-random number generator (CSPRNG for short).

Unlike normal PRNGs, CSPRNGs are designed to pass rigorous statistical randomness tests. They're also designed to hold up well under serious attack, even when their initial or running state becomes available to an attacker.

The term "pseudo-random", as used by cryptographers, may be misleading to a non-technical reader. A CSPRNG expands a collection of random values, known as a seed, into a longer sequence of numbers. That sequence is reproducible given the seed, but for any good CSPRNG, a minor change in the seed yields a very different sequence. Therefore, as long as at least some portion of the seed is chosen via an adequately random process, an attacker is unable to predict the resulting sequence - even if the attacker can influence the remainder of the seed. Numerous important systems, ranging from military communications to the encryption that protects virtually all online transactions, rely on the functionally-equivalent security between "cryptographically-secure pseudo-random" and "random".

To create its seed, the RNGCryptoServiceProvider class draws its entropy from the same pool as the CryptGenRandom function, a FIPS-validated CSPRNG. These entropy sources include the current process ID, the current thread ID, the current tick count, the current local time, the global memory status, the amount of free disk space, the local computer name, the local user name, the cursor position, and so on.

A naive implementation of rolling a die with up to 255 sides using RNGCryptoServiceProvider might look something like this:

Then we roll a 6-sided die 1.2 million times and look at the results:

Ooops! That doesn't look right at all - the distribution is clearly favouring the lower numbers. This is a problem called modulo bias. There are several ways to overcome this. One of the quickest in terms of run-time involves specifically checking for modulo bias every time, and looks something like this:

Again we roll a 6-sided die 1.2 million times and look at the results:

That looks like a much better distribution. Although you could go overboard and run some serious tests.

Another complaint about using CSPRNGs is that they can be "slow". So let's generate some passwords with this die-rolling class and look at the performance:

Setup does take around 1/50th of a second, as reflected in the time taken to generate the first password. But after that, it's fairly fast - generating something in the region of 20,000 passwords a second. This is a clear example of the principle that slow is irrelevant to your customers, your management, and your stakeholders. Not fast enough is what's really relevant.

You can view and download Die.cs. The complete library, including this class, will be posted at the end of this series. In the next installment, we'll look at the password generator class.

• Specifying password policies that can match most application requirements.
• Generating cryptographically-secure random passwords that satisfy a specified password policy.
• Measuring the strength (or more precisely, entropy) of human-generated and machine-generated passwords.
• Using random salts and key stretching to make password hashes more secure than the original passwords.
• Measuring the additional strength added by iterative salted hashes. 
• Timing the password generation and password hashing processes.

Most applications that use a password or passphrase for user authentication also have a policy that dictates the password complexity requirements. These requirements range from a simple minimum length to some very complex rules. There's a decent case for arguing that the more complex policies might actually reduce security in some circumstances. This is because these policies encourage users to invent easier-to-remember (i.e. weaker) passwords or to write down passwords in order to remember them.

Another problem with password policies is that they're mainly aimed at reducing the threat of direct attacks on the application (the online attack) or on the application's login database (the offline attack). They ignore other attacks such as keylogging and botnets, which could be considered as more common threats than the direct attacks.

Finally, you might want to explain to your over-eager security team that the vast majority of end-users quite rationally believe that:

• The chance of their account being compromised by a direct online attack is almost zero.
• The chance of their account being compromised by a direct offline attack is very low.
• Their bank will likely make good any financial losses resulting from a direct offline/online compromise.
• Given the above three facts, it doesn't make sense to spend any time choosing strong passwords and never re-using passwords on other websites.

Moving swiftly on...let's look at the source code of PasswordPolicy.cs, a class that implements policies used to control the generation and validation of passwords. The constants in the following screenshot define all of the possible symbol groups, and individual symbols within those groups, that can be used to create passwords controlled by this policy generator. Note that symbols normally considered to be confusing, such as 0, O, I, 1, etc, have already been removed. I've split punctuation symbols into their own group as applications such as Gmail allow their use whilst prohibiting other non-alphanumeric ASCII symbols. I've also included some non-ASCII symbols, as an increasing number of applications are now Unicode-aware. Feel free to tune these constants to suit your applications. Be aware that if you add or remove any symbol groups, you will need to change the SymbolType enumeration and also any code that uses that enumeration.

The class constructor allows either the default password policy or a custom one. For a custom policy, the full list of parameters is shown in the screenshot. The use of symbols from each symbol group can be prohibited by passing null for that symbol group, made optional by passing zero, or made mandatory by passing the minimum number of password characters that must be drawn from that symbol group.

The default policy doesn't try to do anything clever. It works on the principle that password length is the best security, hence the minimum length of 14. Non-ASCII symbols are prohibited, all other symbol groups are allowed but optional. Again, you can change this default policy as required.

These two properties return a byte array or Unicode string containing the full list of symbols allowed in any password matching the current policy.

For any password matching the current policy, this method provides the major input to a formula for measuring the entropy of randomly-generated passwords matching this policy. We'll take a detailed look at this formula in a later installment.

Not shown is the method that calculates whether a given password matches the current policy. But you can view and download PasswordPolicy.cs. The complete library, including this class, will be posted at the end of this series. In the next installment, we'll look at the die-rolling class.

Unlike the earlier RockYou hack, where all the customer passwords were stored in plain text, Gawker used a relatively primitive password hashing scheme. Unfortunately, their scheme wasn't even close to adequate because of a combination of the primitive hashing, weak user passwords, and the enormous amount of firepower that modern hardware and software gives to attackers.

In today's world, where cryptographically-strong pseudo-random number generators and iterative hashing schemes such as PBKDF2 or scrypt combine to give an equal amount of firepower to defenders, this state of affairs is inexcusable. I thought it would be useful to package some C# code into a utilities library covering the following areas:

• Specifying password policies that can match most application requirements.
• Generating cryptographically-secure random passwords that satisfy a specified password policy.
• Measuring the strength (or more precisely, entropy) of human-generated and machine-generated passwords.
• Using random salts and key stretching to make password hashes more secure than the original passwords.
• Measuring the additional strength added by iterative salted hashes. 
• Timing the password generation and password hashing processes.

Before diving into the detailed code, let's look at the major threat. Imagine that your website's security has been breached and its password database is now in the hands of the attacker. He can launch an offline attack on the database, and dump your users' account names and cracked passwords publicly on the Internet. When this happens, at the very least you have problems 1 and 2 in the list below, whilst your users have problems 3 and 4:

1. Your organisation will have some rather unpleasant publicity.
2. Many of your users will likely lose trust in your organisation.
3. The dump will be harvested by people looking to compromise your application's user accounts.
4. The dump will be harvested by people looking for passwords that might have been reused on other web sites.

So you're now in a race against time. 

If your application stores the passwords in plain text like RockYou, it's "game over". Your best bet is first to warn your users about what happened and the implications. Then force them to change all of their user passwords, or change their passwords yourself.

If your application hashes the passwords using the same scheme as Gawker (DES crypt(3)), the situation may be a little better. It depends on the strength of your users' passwords and passphrases. Because DES can be executed extremely fast with modern hardware, weak passwords will be broken within a few minutes to a few hours. For these users, problems 3 and 4 in the bulleted list above will rapidly apply.

But for those users who used a much longer password, or hopefully a passphrase, the situation isn't quite as bad. DES crypt(3) compresses the password hash to fit the size of a DES key, so many passphrases will hash to the same value. Your users will still have problem 3 in the bulleted list above. But as the passphrase itself can't be disclosed by a successful match, your users won't have to worry about problem 4.

What's clear is that the stronger your password hashing scheme and your user passwords are, the more time you and your users have to deal with problems 3 and 4 above. The next installment in this series will look at password policies and how they can be implemented in software to increase the strength of user passwords. 

Of course, every software developer is basically a machine in search of curious problems to solve, and I'm no different. Just how outrageous an answer to FizzBuzz would persuade an interviewer to hire me on the spot? Inspired by this Ruby gem, I played a variation in the key of C#. It took about 9 minutes of CPU time to compute a pseudo-random number generator seed that produces the correct answers for the FizzBuzz quiz in an entirely random fashion:

But we all know that coding magic numbers into your code is a no-no, especially in an interview situation. So I turned to a suitable source to see if I could compute 126782503 rather than just hard-coding it. The 28-bit binary equivalent of 126782503 is 0111100011101000110000100111. And sure enough, you can find that binary number hiding sneakily in pi at binary index 3,422,140,640. Unfortunately, it would take quite some time to compute pi to that length, even with the help of the amazing BBP formula.

Then I showed this to my colourful colleague Pascal Honore, and he started playing with it in PHP. More on this in the next installment.

Techie

• The Skeptical Software Development Manifesto: Excellent thought-provoking parody of the Manifesto for Agile Software Development.
• Agile bridge building: More satirising of the Agile approach to software development.
• Delegates and events: Good and detailed explanation of events and delegates in .NET.
• Essential floating-point arithmetic: Important information about floating-point arithmetic for the software developer.
• Heavyweight spam filtering: How to block a few million spams per day without breaking sweat.
• Why accurate estimates aren't possible: This one really hits home hard.  
• Parable of Two Programmers: And so does this, even though it was written in 1985.  
• Amdahl's Law: Wisdom from a .NET performance guru.

Non-Techie

• Patrick Tam: My boss where I work currently (Flash). 
• 404 Research Lab: Some interesting "Page Missing" error messages - this one is kinda funny.
• The Vista saga: An insider's view on what might have happened with Vista.
• Change or Die: Could you change your behaviour if your life really depended on it? 
• North Korean gulag: Almost too painful to read - Camp 22 is apparently now closed, but the nightmare continues.

As I said in my previous entry, Hydra recently terminated English GM Michael Adams with 5 wins and just 1 draw against the world's number 7. I also made the bold prediction that human world chess champion Vladimir Kramnik was going to suffer in his November 2006 match against Deep Fritz. At the time, many knowledgeable and strong players disagreed with me. For example, Susan Polgar, the second strongest female player ever, predicted a 3-3 draw. Many other strong grandmasters thought that Kramnik had good chances based on his recent tournament results. And back in 2002, Kramnik managed a 4-4 draw against an older version of Deep Fritz.

So what happened?

Kramnik did indeed suffer, and eventually succumbed - Deep Fritz won 4-2, with 2 wins and 4 draws. The intense pressure obviously made for some interesting chess - Kramnik's first loss was caused by missing a mate in one, almost unprecedented at this level. But in the final game, Fritz played some deep and brilliant lines, fooling most of the GMs present who thought the monster was finally going down.

Hydra is significantly stronger than Deep Fritz, and I think the result of a match between Hydra and Kramnik would be almost a foregone conclusion. I for one welcome our new chess overlords.

My 3.5 year-old daughter sits on my lap transfixed, almost hypnotised, by the rich tapestry of gorgeous colours and patterns that G-Force produces. Now I just need to hook it up to the 50-inch HD plasma screen, turn off the lights, sit back on the sofa with a pint of vintage Special Reserve Westons cider, and truly chill-out in style.

Disclaimer: I have absolutely no connection with the company or people that produce G-Force, apart from being a happy customer.

On the left is my space, on the right is my wife's space. We have 2 networked computers each (using KVM switches), and share an ADSL connection and a printer/scanner/copier - the latter is the ugly lump on the far right of my wife's desk. This is all on the top floor of a converted warehouse in north London.

Techie

• Cunning creatures, those bugs: Be careful, especially when writing "easy" code.
• Obfuscated C# 2.0: Next time you're faced with an interviewee who thinks he's God's gift to .NET development, give him this test.
• Normalisation as obfuscation in C#: And if he gets the previous one right, this one's really going to nail him!
• Case-sensitive VB .NET: And when he claims that VB. NET is case-insensitive, this one ought to shut him up.     
• Attack of the bots: Interesting Wired essay about crashing a significant portion of the Internet.
• Nice error message: When something goes wrong, a good sense of humour goes a long way.
• How to sell your boss: If you can't get your boss' approval at the right time, then you're not going to go far.

Non-Techie

• Disturbing self-images: An artist records his own descent into dementia. 
• All marketers are liars: Interesting insights from a Seth Godin presentation at Google.
• This place is not a place of honor: Physicists tell me this really isn't necessary, but it's interesting nonetheless.

Techie

• Keygen for WinZip 9: Found using Google's new code search app.
• Xooglers: Reminiscences from ex-Googlers.
• Mars Polar Lander vanished: Interesting analysis of the software bug that lost a spacecraft.
• More software horror stories: Dead bodies everywhere.    
• Alarm bell phrases : When you hear one of these, run.
• Humorous error messages: On the Nixdorf 8870, canceling a print job would sometimes produce the message Spooling is too tough!
• Google hardware circa 1999: They've grown a little since then - 170,000+ servers was the last figure that I heard.
• Naughty, naughty: Beware when stealing somebody's wireless Internet access.

Fun

• Things nobody tells you about the South Pole: Apparently, it's been stolen several times. 
• KEO: Watch the skies in 52,007 AD.
• The radioactive boy scout: Nobody really needs a home-made nuclear reactor .
• The 48 Laws of Power: Many software developers have Machiavellian tendencies.

Brute force versus AI

Jeff correctly points out that the brute-force approach (type A) has historically been much more successful in producing strong chess computers than the AI-type approach (type B). But he then suggests that type B programs are starting to emerge, and uses a quote from an interesting ExtremeTech article on building a personal computer optimised for playing chess:

"Despite its vastly inferior brute force, the Deep Blitz machine could already be a match for Deep Blue because of improvements in chess software. Deep Fritz is able to evaluate lines of play to a similar depth because it successfully narrows its search only to the strongest lines of play."

In fact, what Deep Fritz is doing here (null-move forward pruning) has nothing to do with an AI-type approach. Instead, it's just a sophisticated tree-search technique that allows you to cut-off large parts of the search tree without actually doing a full analysis. So this is really just a clever addition to the brute-force armoury - it owes absolutely nothing to AI. Fritz and its competitors such as Shredder and the chess monster known as Hydra are basically brute-force searchers with only a rudimentary understanding of chess positions when compared to human grandmasters. 

Will chess computers consistently beat all humans?

I think Jeff is correct in his dismissal of Bram Cohen's ultra-simplistic analysis of the current state of computers versus humans in chess. But he counter-attacks with an old article by chess statistician Jeff Sonas stating that the top 200 humans are (or were in 2001-2003) keeping up with the best chess computers. This article has at least 3 problems: 

• It's impossible to draw statistically-valid conclusions from just 65 games.
• 2003 is a long time ago in computer terms.
• History has shown that Sonas was probably wrong. 

The most significant recent match was in mid-2005 between English GM Michael Adams (then rated number 7 in the world) and the aforementioned Hydra - a chess machine rather than a chess program. Once again, it's not feasible to draw a statistically-valid conclusion from a match of just 6 games. But the result was pretty convincing: 5.5 - 0.5. That is to say Hydra won 5 games and drew 1 game. It's arguable that Adams didn't prepare properly for the match, but it's interesting that Hydra never had a bad position in the whole match. If a human GM can't get to a position that his computer opponent doesn't understand properly, then eventually he's going to be curled up in a corner with his paws pointing skywards. This is because the machines are so strong tactically that it's only a matter of time before the human is caught and pureed.

Here's some commentary from Adams himself on the match:

"I didn't play badly throughout the event, but it’s just so difficult to make an impact. It’s not like playing against other humans – for starters against humans you may actually win a point."

And here is GM Nigel Short's interesting analysis:

"I have a great business proposition for you: I give you $10,000, or $20,000 if you are really, really good. You get on a stage in London and allow yourself to be fucked by a machine for six days. How does it sound?"

GM John Nunn has his own opinion:

"The Adams-Hydra match signals the approaching end of man-machine contests. Already, last year's event in Bilbao was a sign that things were looking bleak for the humans. In Bilbao, it was not so much the performance of Hydra that was so impressive, but Fritz's score of 3.5/4 against Ponomariov, Topalov and Karjakin (twice). Hydra, which made the same score, was running on its special-purpose hardware but Fritz was running on a laptop computer from the local department store."

And if all that doesn't convince you, Vladimir Kramnik has recently retained his world chess champion title, and is due to play a match against Deep Fritz in November 2006. Here's his analysis of his chances against a program that isn't as strong as Hydra:

"Vladimir Kramnik said that Deep Fritz was definitely the favourite and rated his chances for beating the machine at about 40-50%.....The Classical Chess World Champion replied that certainly the day would come when computers would play so well that no human being could compete against them, but that he hoped that November 2006 would not be that day. He believed that the contest between man and machine will still be exciting for a couple of more years."

Wesner Moise adds his own contribution to the debate. It's true that "draw death" may give humans a chance to hold on to their illusions for an extra year or so. But the end is going to be both brutal and inevitable: the machines will prevail - and the chess Terminators are already among us.  

• Web pages allow people to communicate and collaborate with each other using the Internet or an intranet.
• Web services allow programs to communicate and collaborate with each other using the Internet or an intranet.

Having been a long-time user of E&C in the VB.Classic IDE, I have mixed feelings. There are both benefits and dangers to this feature, and on balance, I feel that the benefits outweigh the drawbacks. The arguments against E&C tend to emphasise the dangers of this feature in the hands of inexperienced developers. Well, almost everything is dangerous in the hands of an inexperienced developer, so that's just not a convincing argument for me. And if you do understand what you're doing, E&C can be a great benefit.

Enough preaching. Like any subject, the devil is in the details. So let's look closer at some typical uses of E&C.

Bad Debugging with E&C

A developer makes several attempts during a single run to fix a problem. He repeats a cycle of altering code and then resetting the current execution point to run through the altered code. For example, a developer believes that a bug is caused by an off-by-one error in a loop. So he firsts puts a +1 in the loop and then checks the result. If that doesn’t work, he puts a –1 in the loop instead, still hoping to get the right result.

Proponents of this debugging approach say that it is more efficient because there is no need to restart the program after every code change. The problem, though, is the indisputable fact that in this case the developer doesn’t actually understand the problem. If he did understand the problem, there would be no need to make multiple attempts at a fix — he could go straight to the problem area and fix it in one attempt.

While E&C makes it very tempting to try many potential solutions until something seems to work, this is akin to poking a jellyfish with a stick to see if it moves; it doesn't actually teach you very much. A quality solution is much more likely to come from some deep thinking about a problem rather than ad-hoc attempts at a fix.

More Bad Debugging with E&C

A developer starts by finding and fixing a single bug, but then attempts to fix more defects that appear. These defects are often related to or hiding behind the first bug. The temptation when using E&C is to find and fix as many bugs as possible during a single run—this can be very satisfying and at first sight seems to be an efficient method of working.

Unfortunately, this approach also has problems. First, the developer once again probably doesn't understand the original defect at a deep level. If she understood the original bug properly, it is unlikely that her original fix would have exposed the multiple new issues. Even if she did understand the bug, it is debatable how well the new issues and subsequent fixes were understood. As before, E&C makes it far too tempting to fix bugs as they arise, rather than taking time to think about the issues away from the heat of the battle.

Another problem with this approach is that if there are multiple issues being exposed within a block of code, it is likely that the code itself is fundamentally flawed. Such code always benefits from taking a step back from the situation rather than fixing the bugs in an ad-hoc manner. Using E&C to push multiple fixes is unlikely to improve the code’s quality.

The next problem is that several programming experiments have been done that collectively show that the average developer introduces one new bug for every two bugs that he or she fixes. Even the best developers produce one new bug for every four that they fix. Making multiple concurrent fixes, some of which might potentially interfere with each other, is not conducive to producing high-quality solutions.

Perhaps the final nail in the coffin of “shotgun debugging” is that many of the E&C fixes made are small ones, often affecting only a few lines of code. These are made because they are the type of changes that look manageable without having to perform desk-checking or proper review.

Unfortunately, the literature shows that the chances of creating a bug significantly increase when making such small changes. Specifically, as the number of lines changed increases from one to five lines, the chance of making a bad change is high and increases. With more than five altered lines, the chance of making a bad change decreases, probably because the developer becomes more careful as the fix becomes larger.

Bad Unit Testing with E&C

A developer edits code several times within a single run in order to run multiple unit tests on a procedure or component. For example, a program that executes an embedded SQL script sees the developer correcting, tuning, and re-executing the SQL script many times until he is happy that everything is working properly. The typical argument for this approach is that it is much faster to run these multiple edit-and-test cycles in one hit rather than having to restart the program every time a change is made.

There are several problems with this type of ad-hoc testing. The first is that any tests done in this manner are not going to be as comprehensive as a manual or automated unit test harness that has been implemented beforehand. It’s hard to invent several good unit tests on the fly, especially when the psychological mindset is aimed at making the code work rather than proving that the code doesn't work.

The temptation is always to fix the code in-flight when each test fails rather than running a test suite, collating the results, and then thinking about the fixes as a single, well-controlled patch to the program. Simultaneous mixing of the unit testing mindset with the quite different mindset of fixing code that fails the unit tests is very dangerous.

A second problem with this approach is that it makes it very difficult to perform unit regression testing on future versions of the code. Even if the developer could manage to remember the entire unit test suite that he had performed, repeating a set of interactive regression tests every time the code changes is very boring and therefore prone to mistakes.

Another trap that many developers fall into with E&C in this context is changing code on both sides of the interface being tested. It is just too easy to make a change to the calling code that makes the interface being tested appear to work. What might actually be happening is that two errors, one on either side of the interface, could compensate for each other and result in the interface appearing to work.

Once again, the psychological need to get the code working can interfere with the unit tests being performed. In effect, this makes it easier for the developer to fool himself into believing that everything is working correctly through an artificial test case created by manipulating two sets of code.

Good Debugging with E&C

One appropriate way of debugging with E&C is when you find an obvious coding error, often while looking at something completely different, and change the code for an obvious fix. While it is a fine line between an “obviously correct” fix and a “subtly wrong” fix, most developers know when they've found a glaringly obvious problem. In this case, it can be good practice to fix the problem, test the fix immediately, and then proceed on your way with your original mission.

Another reasonable way of using E&C is when you've found an error and managed to reproduce it successfully. The next step is often to reproduce the error in several different ways in order to learn more about it. E&C can be very useful in allowing multiple code changes and tests during a single run in order to triangulate the bug and learn more about it. The proviso, of course, is that you must put the code back into its original state once you have completed your investigation.

Good Unit Testing with E&C

E&C can prove very useful when you're unit-testing a GUI. Although it’s still better to create a proper test harness if possible, this can be difficult to automate because you have to simulate a very unpredictable component (the end user), and also it’s difficult to validate the unit test results. For this reason, many developers prefer to test interactively, so I'll grant that this can be a reasonable use of E&C.

Good Prototyping with E&C

In this scenario, a developer makes multiple code changes during a single run in order to prototype, typically when investigating the behaviour of a class, a control, or some other component. With E&C, it is much faster to perform this type of testing, and because it is only prototyping, there is much less danger of bugs running rampant. This scenario is one of the genuinely useful ways of using E&C.

Having been in the software industry for *cough* years, I've seen my fair share of language wars. If you dig a little deeper, there are 2 types of "religious war" commonly on show:

• The developer who promotes a specific language as superior to the alternatives.
• The developer who denigrates a specific language as inferior to the alternatives.

The first type is usually the result of something akin to falling in love. The developer tumbles head-over-heels for, say, French rather than English, and wants to share the wonders of French at every other developer within range. There's sometimes a full 6-pack in evidence, but always a completely lack of the plastic thingy to hold it all together. 

A good example of the second type is the often savage attacks aimed at any random dialect of the Basic language. The real target is rarely the language actually under attack, but rather the culture and abilities of the developers who use that language. It's a classic tribal attitude, "them" versus "us", and often a fundamental culture clash. And it's usually the result of a profoundly immature view of the world, one that fails to recognise that software development is actually multiple disciplines and really benefits from having multiple cultures.

You know that a specific discussion is turning towards a religious war rather than genuine technical debate when you start to learn more about the mindset of the developer doing the debating than you learn about the languages under debate. People start to confuse the strength of their feeling for the strength of their argument, and often try to pass off personal value choices and cultural attachments as objective technical evaluations.

Look, folks, just grow up!

• Don't put too much value on any one specific language.
• Don't be elitist or dogmatic when it comes to programming languages.
• Do learn how to step back and be more objective.
• Do realise that you aren't as intelligent as you think you are.
• Do understand that every language will teach you new stuff about software development.
• Do find out what you can learn from other software development cultures.

Perhaps one of the real and lasting benefits of .NET is that it puts developers from several different cultures and backgrounds onto the same development platform, where hopefully we can all learn from each other.

UPDATED: As I don't have blog comments, Nick Schweitzer emailed me to point out that he has an older blog entry which shows a more well-rounded view of the world than indicated by his entry mentioned above:

When you get down to brass tacks however, being a religious software advocate is a really poor thing to do. I much prefer to be agnostic over my software choices. The simple fact is that the software you use to create something is not the goal. Software is just a medium to get somewhere else. People who get deeply religious about their software tend to be more excited about how they're going to do something, and not about what they're trying to accomplish.

And it's Xmas, so I've toned-down my language slightly :-)

To do this, you need to emulate what the Service Control Manager (SCM) does when it starts your service — in other words, invoke your service’s OnStart method. In C#, this looks like:

And in VB, this looks like:

This approach also allows you to debug your Main procedure and the code in your OnStart method. This is otherwise rather tricky because these two procedures have already been executed (during service startup) before you get a chance to attach to the service process for debugging. This debugging trick has the additional benefit that if you want to debug other service commands such as Stop or Pause, you can just invoke the appropriate method directly from the IDE's Immediate window.

UPDATED: Len Holgate has a more sophisticated version of this idea, where he completely decouples the service from the SCM.