One thing is a constant in web development: user accounts. Every site with any dynamic aspect needs at least one login, that of the administrator. Choosing good passwords and keeping them safe is a vital skill for any web master. Keeping your users passwords safe is a vital skill for any web master. We’ll split this into two parts; Choosing Passwords and Storing Account Passwords.

Choosing Passwords

Many, many users will set their password to password given half a chance. There are various standards that relate to passwords and how systems should enforce them to address this issue. Rules like “Must contain at least one upper-case character”, “Must contain at least one digit”, “Password must be changed every 90 days”, “Password must not be the same as the previous three passwords” etc. Personally, I’d like to consider this common knowledge and well-trodden ground, but it seems users just don’t get this message and still use insecure passwords all the time.

A web master must be above this, and must secure their administrator accounts with strong passwords. So it was with some dismay that I stumbled into Microsoft’s little online tool to test the strength of your password. The tool goes from Weak to Medium to Strong to Best. There are three distinct rules. Meeting the requirements of each rule moves you one point up the scale. The rules are:

1. Use at least one upper-case character.
2. Use at least one non-alphanumeric character (i.e. not a-Z).
3. Have a length of at least 14 characters.

This means that the password “Password1″ is considered Strong whilst “qsd43ghp” is only Medium. And “Password1aaaaa” is the best of the best. Which worried me a lot, as recently I read an article by Bruce Schneier in which he explains how brute force password crackers rip through passwords, and things like Password1 are right at the top of their cracking attack pattern. Password1 is even the most popular password on MySpace (ref).

Make sure you read that first article, it’s important. I know a lot of geeks, myself included who use some patterns to secure their password that tools such as the Password Recovery Tool Kit fully understand and prioritise their breaking towards. We’re not as safe as we thought.

Bruce advocates two types of password as harder to beat, one will make passwords you can never remember. However, his 2nd type:

a password made up of the first letters of a sentence [is not going to be guessed], especially if you throw numbers and symbols in the mix.

This gives us an “in” to coming up with truly secure passwords that we can remember. We pick a sentence that we can remember, isn’t obvious to people who know us (i.e. spend some time picking a good one) and we work from there. I’m going to use “Mike is the most awesome person in all the world”. First thing we do is just use the initials giving mitmapiatw, which is almost pronounceable. Next, we want to add capital letters. Choosing a rule at random, I’m going to capitalise the small insignificant words mITmapIATw. We now have a Microsoft Approved Medium Strength password. So we need to add numbers and symbols to make it Strong. I’m just going to go ahead and use an arbitrary dialect of Leet to change letters into numbers and characters. I’m not just going to replace, I’m going to follow Leetable characters with the Leet representation. This makes my password longer. mI!Tma4pI!A4Tw. You could change your dialect of Leet for repeated characters, then I wouldn’t have two 4’s and two ! characters. But I won’t bother. That gives me a Strong password. It also hits the magic 14, making this a Best strength password.

Not only do Microsoft think it’s as good as it can possibly get, according to Bruce, the password recovery tool kit is really, really going to struggle on it. It’s not based on words. It won’t be in the dictionary attacks. It won’t be in the Leet variations on dictionary attacks It isn’t based on prefix or suffix extensions. At the end of the day, we have a damn complicated series of characters that we have a nice easy key to remember, I just have to remember how arrogant I am, and my password is there!

Of course, now you all know the algorithm I use to make up passwords. All you need to do is spend some time trying to figure out what kind of sentences I might use and build a special dictionary for me. (Trust me, I’m not that arrogant I would actually use that sentence!) But the size of that dictionary would be insane. How many characters did I go for? Did I really hit 14? Or did I keep it small? Or bigger? What was the source of the sentence? I could have an in-joke only a few people know. A favourite line from one of the three hundred DVDs on my shelves. Producing an appropriate sentence based dictionary to attack my password is not a realistic thing to do.

Especially since I’m thinking hard about attack vectors so would try and find a way to come up with a sentence that no-one would guess. A line from a movie I hate? Who knows.

That leaves Social Engineering to get my password, or clues to it. A bar of chocolate might be all you need.

Storing Account Passwords

So, you have users. They set their account password. Chances are it’s weak. Some passwords might even be strong passwords. Chances are, they use the same password loads of places. Perhaps including their on-line banking. You must not be the weak link in the chain. You must not be the service that gets hacked or accidentally leaks data and gives away thousands of your users passwords. Which can happen even with the biggest players.

This means safely storing passwords in the database in a safe way. The safest way to do so, and the standard web approach that all sites should take is to store a cryptographic hash of the data. A finger print. From this finger print, you can not retrieve the original data. However, you can compute the finger print of an entered password and compare it to the stored finger print.

This means you don’t have the password to leak. Except during login. It also means that you have a fixed data size for storing the finger print. Cryptographic Hashes always produce a fixed amount of data.

The defacto standard for this in web applications is the MD5 Checksum. Implementations abound in most languages, many including PHP, have a built in implementation. This generates 32 characters of hex. However, recently weaknesses in this have concerned some developers. Personally, I think the weaknesses are irrelevant to passwords, focusing on the ability to produce a large document that matches a checksum. There is much less room for collision in the password space.

These days, the seriously security concious go for SHA-256. This generates 64 characters of hex.

For comparison, and ease of re-setting my password in development environments, I produced a Google Gadget to generate MD5, SHA-1 and SHA-256 hashes. You can find it here, and add it to your Google Homepage by clicking .

A Further Note on Microsoft’s Password Strength Checker

I’d just like to make it clear that I understand that Microsoft’s on-line password strength checking tool is a simple little thing just making sure that the password matches some basic rules. I’m aware of the limitations that that tool has as a result. It can’t really check for obvious things like, your password shouldn’t be your first child’s birthday, or your wedding anniversary (especially if you’re a man as you’re bound to forget it!). But, this is not made clear to the kind of user this tool is targeted at.

EdenToby01072000 would be a “Best” strength password, but so easy to guess if you knew my anniversary and children’s names. Any decent planned assault on my accounts would use those items as dictionary inputs and prioritise them. If you are going to produce a tool that is designed to educate basic end users about password strength, that tool needs to be as good as the passwords need to be.

And Microsoft’s tool isn’t.

Popularity: 33% [?]

So, today I’ve finally finished installing and configuring a Wordpress installation for running InAnger.com. This may seem a fairly odd decision to certain people who know certain things. The main reason it’s odd is that I am a member of the core development team for the Geeklog system. Wordpress is a PHP application using a MySQL database for running a Blog. So is Geeklog. So then, if I am a Geeklog developer, why have I chosen a competing system to run my new site? Interesting question, and one I shall discuss in length.

Firstly, I consider it important to investigate the innovation going on in competing products. I take a similar approach with software languages and tools. Something else is out there and has some buzz, so I play with it to find out why it has that buzz and what that new thing can do for me. With software languages and tools this is likely to be a switch to develop with a new language, even if it’s just for certain tasks that that language is particularly handy for. With a piece of software like a Media Player it’s a possible full switch to that product if it’s better.

With a CMS however, it’s more likely to be that I experiment with it and frankly steal the neat features and implement them in Geeklog. So, I’ve often seen posts “I tried geeklog, but now I’ve switched to wordpress and like it more”. Time to find out why and see if I can address those issues.

That’s not all though. I’m a terrible one for tinkering. I can’t find-out that some piece of software I use is customisable or configurable without becoming dissatisfied with what it can do, and try and customise it. As a Geeklog core developer, if I was using Geeklog, I’d get constantly side-tracked customising things and re-writing things. With Wordpress being a stable application with an active development community which I am not a member of I’m more likely to be able to keep my hands off, and concentrate on using the application.

So, Wordpress vs Geeklog, what’s the difference?

Wordpress

Wordpress is a highly popular Open Source blogging tool. It’s focussed on “aesthetics, web standards and usability”. It has a simple elegant usable interface.

Geeklog

Geeklog is also an Open Source blogging tool. It’s focussed on security. Out of the box it provides a full portal implementation as well as the core blogging features.

Installation

Installation of both is reasonably simple. In both cases you download a tarball archive of the latest version. In both cases you extract this and create an empty MySQL database to install into (in Geeklog’s case, you may use a Microsoft SQL Server database too). In both cases you set up database connection information in a configuration file. In the case of Geeklog all your site’s basic configuration is also in the configuration file and may be edited at the same time, plus, there is the additional need to configure file paths in two files (the configuration file and lib-common.php, the core functionality file). In Wordpress’ case you have to copy the config file to a new name.

Then you navigate to the install script location for either system and execute the install process. Voila, two complete blog package installs. You’re then left to configure up your system to meet your needs.

Publishing Blog Entries

The main thing you’re going to be concerned with day to day with your blog engine is writing, editing, posting and maintaining entries.

Both Geeklog and Wordpress have similar options for your posts. Advanced HTML editors (though I feel the use of FCKEditor gives Geeklog the edge here), control over the way the link is generated (post slug in Wordpress and Story ID in Geeklog, they form part of the URL for Search Engine Friendly URLs), control over user feedback permitted (comments etc), the ability to place an article into a category (and here Wordpress wins with multiple category support), image upload etc.
So where are the differences? Well, Wordpress allows Custom Fields on stories. I have yet to fully explore these, but they allow plugins to provide rich functionality easily to stories. Geeklog has Autotags which replace this functionality.

Geeklog has a strong security model, you can have many user groups and can set permissions for stories and topics in a very controlled fashion. Wordpress lacks any of this subtle security, it’s focussed on public blogging.

Geeklog also has the ability to auto-archive stories after a certain amount of time.

Really at the story level, the only differentiation seems to be that Geeklog has an excellent security system and also allows users to contribute stories (via moderation if necessary) to the site.

Both have strong API’s for plugins to extend things, however, I think extending the posting engine in Wordpress is a lot easier than in Geeklog.

So what about at the display end of stories? Both support comments, trackbacks and pingbacks with anti-spam measures and control over who can comment etc. Both have ways the display of a story can be tailored to suit the webmaster’s needs. It’s pretty even , with minor differences.

That leaves the user experience. Geeklog is (out of the box) a richer and more complex application than Wordpress. It does more. And thus, it’s a bit harder to learn your way around at first. That doesn’t mean Wordpress is a saint. I think I found my way round it reasonably quickly, from scratch, but, it could have been a clearer process. That said, Wordpress’ documentation which is linked at the foot of every admin screen is rich and detailed and vastly superior to the limited (by comparison) documentation for Geeklog.

Other Features

Wordpress is a blogging engine. That’s about it. It gives you static pages and links. But out of the box, that’s pretty much your lot. Geeklog is more of a portal, it comes with a calendar (for events, not to be confused with a monthly post view calendar which both systems have), polls system, links directory and static pages. Geeklog has a modular system for blocks on both the left and right hand side of the page, which allows the administrator to configure up static text, import RSS feeds, or use various built in functions to produce various types of dynamic boxes. To do this in Wordpress, you must edit the theme to include the HTML and/or function calls.

Themeing/Skinning

Both Geeklog and Wordpress come with perfectly nice default themes. But you don’t want your site to look like Just Another Geeklog/Wordpress Site. You want it to look individual and have an identity of it’s own. Both systems therefore offer a theming system to change the look and feel of your site.

Wordpress has a small number of PHP files that make up the base theme. These contain PHP function calls to output data and even loop structures to iterate over posts. This is quite confusing for non-programmers to get to grips with, but there is a lot of documentation, many community developed themes and lots of community support for this work. Plus, there aren’t that many files to edit.

Geeklog has many THTML files that make up the base theme. These contain HTML and place holders for dynamic data (in curly braces, for example {story_title}). It takes a fair bit of work to get your head around how these files are used to actually construct the layout of your site, and the documentation isn’t fantastic on these. But, I feel the content of each template is less confusing.

Extending

Both systems support plugins to provide the functionality you want. Some of Geeklog’s out of the box functionality is from core plugins (calendar, links, polls) and can be uninstalled if you do not like it.

The Geeklog API consists of a lot of functions you can define that get called at appropriate points. The Wordpress API consists of a lot of places you can tell Wordpress that your plugin wants a function call inserting into the chain. Both API’s seem to be pretty mature and well thought out and provide a really great way of extending the application.

If anything, I would suggest the opinion that Geeklog’s API is more mature and powerful, implementations include various image galleries (including integrations of popular Open Source gallery applications like Gallery), forums, file repositories and even further anti-spam measures. Wordpress however seems to have many more plugins available, more focussed on adding features to the story engine.

Summary

So, to just recap. Geeklog is a bigger system. It does a lot more. But, for people who just want to set up a simple blog, that might be too much, too daunting, too confusing. They’re targeted at different audiences. Geeklog is for running sites that are more than just a blog. Wordpress is for sites that are just a blog. The reason people are switching, is because all that power and all those features get in the way of having a plain, simple blog that everyone can read.

Popularity: 72% [?]