Jeff Atwood shows us why we should consider better password policies when developing applications or setting company policy.
As we know, the biggest threat to security is not hackers, but the users themselves making it easy for someone to gain access to protected resources by having ridiculously easy to guess passwords. As developers we are as much at fault for building applications that allow this behavior. Jeff recommends using pass phrases instead of passwords. A phrase is longer (and thus more resistant to brute force) and easier to remember than a mixed up jumble of nonsensical characters. By adding an unusual word or character pass phrases are very difficult to break with dictionary attacks as well. Pass phrases are controversial as well, see:
The Great Debates: Pass Phrases vs. Passwords. Part 1 of 3
The Great Debates: Pass Phrases vs. Passwords. Part 2 of 3
The Great Debates: Pass Phrases vs. Passwords. Part 3 of 3
Personally, I think the hard part is convincing users and business owners of an application that longer or more complicated is better. From my own experience I understand users want the simplest password policy possible. Often the business owners of an app don’t feel the information being protected is all that important to justify such an imposition for the users, or feel that it becomes a support expense because users can’t manage their own data or password very well (a great argument for using something like Windows CardSpace). I think they forget that users re-use the same password everywhere possible: a free e-mail account, network access at work, bank web sites, a blog, a MySpace account, etc. I would not want to be responsible for a malicious person to gain a password from my system and then use that password to systematically destroy someone else’s life. Be strong, insist on good password policy.
I thoroughly enjoyed my presentation and the time at Day of .Net this past Saturday. Special thanks to those folks who attended my presentation.
Here is my slide deck.
This is a zip file of the code from the presentation. Remember you need the .Net 3.0 framework and the SDK for Open XML Formats CTP in order to run the code.
I have a web project (the original 2005 web project type, not a web application project) and had a problem getting files copied to the bin directory. Essentially, one of the library projects referenced by the web project has an XML file in the project output, but when the solution is built, the XML file in the bin directory of the library project is not pulled into to the bin directory of the web project. Of course, a post-build event seemed like the thing to do, but web projects don’t have support for that.
A little digging and I found this post by Scott Guthrie that describes a “Build Helper Project”. You simply add an empty class library project to your solution. You then use the build events in the empty project use to add build events to your web project. You just make sure the project build order is correct so the events get called when you need them.
I will be speaking at Day of .Net in Ann Arbor, MI on October 20th. It’s a Saturday, and it’s a completely free event. I will be presenting Creating Office Documents with Open XML. I will be going over the Packaging API and how to programmatically create and manipulate Office docs.
There are four concurrent sessions all day long covering many aspects of .Net.
See you there!

Got my new November Dr. Dobbs issue today. The back column “Swaine’s Flames” has reminded me of some programming “laws” that I have seen before. I have added my own corollaries for each:
Kernighan’s Law: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
My corollary: “The developer who’s code that you inherit believed they were twice as smart as they really are.”
Eagleson’s Law: “Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”
My corollary: “You can recognize that you have written code to solve a particular problem but will be unable to locate the specific instance you recall.”