james mckay dot net

Anyone who has ever tried to edit Wikipedia will have encountered wikitext, the rather esoteric syntax used for markup on its pages.

Wikitext is, in theory at least, simpler than HTML. Two single quotes delimit ''italics'', while three single quotes indicate '''bold text'''. [Square brackets] indicate external links, [[double square brackets]] indicate internal links, and so on. A lot of other wiki software uses similar syntax. For example, Trac, a popular open source bug tracking system, uses a very similar markup language, and since you can also embed HTML in it, and even use a fairly sophisticated macro language, it allows very fine-grained control of the contents of the page. For the novice, there is a helpful toolbar at the top of the edit box, so that you can easily mark up various parts of the text as bold, italics, hyperlinks, and so on.

However, in late 2007, it somehow feels wrong. As wrong as it felt not being able to get broadband in late 2005.

Perhaps there is a place for wikitext, as a fallback to improve accessibility when JavaScript is not available. And some things are simply not possible (yet) without it, such as typesetting mathematical equations. However, in terms of usability, it sucks. Apart from having to navigate away from the main article page, you have to scroll through the box to find the part of the wikitext corresponding to where you want to make the change (not obvious in an article with a lot of footnotes, references, tables and the like). It also creates a distinct range of systemic biases, which is a problem that Wikipedia itself acknowledges. How much nicer it would be, if clicking on “edit” on a section of a wiki page were to bring up an in-line rich text editor where what you see is what you get.

Web browsers have now had rich text editing capabilities for over seven years. This feature was first introduced in July 2000 in Internet Explorer 5.5, and nowadays every major browser supports it one way or another. It needs a lot of fiddling about with JavaScript in order to work properly on all of them, of course, but there are several popular and mature libraries and components such as FreeTextBox, TinyMCE and FCKeditor that handle this very well, so that’s pretty much a solved problem. Even cleaning Word HTML and producing valid XHTML — once common objections to rich text editors — are solved problems too.

There are many rich Internet applications these days that raise the bar significantly in terms of quality of user experience. Slick, good looking, easy to use sites are becoming more and more commonplace, and while ones such as Google Maps or EyeOS still have a bit of a “wow” factor, it’s getting easier all the time to develop them. With libraries like jQuery, for instance, you can implement a Google Suggest-style Ajax search facility in a couple of hours.

With it becoming increasingly easy to create elegant rich Internet applications, and the tools to do so being readily available, free and open source, having such an awkward and clunky way of editing content is beginning to look very last millennium. It’s time it went the way of the dinosaurs.

Comments closed (2) »

Posted at 12:30 on 26 November 2007.
Tagged: wikipedia

How does your website handle users who have forgotten their password?

Chances are, you ask for their e-mail address, look them up, extract their password from the database, and e-mail it to them. Nice and simple, and convenient for the end user, and easy to program.

Unfortunately, it is seriously and dangerously flawed.

Almost everyone re-uses login details across multiple web sites. It simply is not realistic to expect them to do otherwise. As a result, if an attacker manages to compromise your user database, they will be able to impersonate your users on potentially thousands of websites, including some that store their credit card details.

Never think you are immune to this. It happened to Reddit, a popular user-generated news site similar to Digg, and it can happen to you. It is very difficult to be 100% sure that your database will never fall into the wrong hands: unless you have enterprise-level security staff, infrastructure, procedures and budget, every single person involved with your data will be a weak link in the chain, from the developers to the DBAs to the dodgy geezer who comes in as a contractor to do the building’s networking. Do you know where all the copies of your data are — even the partial, out of date ones that your developers use for testing? Are you sure there aren’t any hanging around on backup CDs, USB key disks, laptops, or old PCs that you are throwing out?

No, you should never store your users’ passwords directly in a database. Instead, you must use a salted hash: a one-way encryption algorithm which makes it impossible — or at the very least, computationally very expensive and impractical — to reverse engineer them into the original password.

Unfortunately, this means that you can’t send password reminders to your users. Instead, you have to send them a single-use link to a page where they can reset their passwords on confirmation of their e-mail address. Because of this, some people prefer to sacrifice security in favour of convenience here. In fact, if the comments that were left on Jeff Atwood’s blog when he wrote about this subject are anything to go by, sometimes this design decision is imposed on developers, against their recommendations, by their managers.

I think that Mats Helander comes up with the best response to this, when he says that it should be illegal to store passwords in a database in plain text:

Many comments on Jeff [Atwood]’s blog lamented the fact that sometimes your boss will decide for you that passwords should be stored in plaintext (or two-way encrypted using a secret key, which the hacker will of course be able to obtain as readily as your password list, meaning it’s as good as plaintext). One often suggested reason would be a requirement that the system must be able to mail back a user’s forgotten password.

In my opinion, this is one of the very rare cases where I think the law should get involved, protecting the developer from having to compromise my security in order to keep his job. The developer should be able to say “No boss, that would be against the law”.

I couldn’t agree more. Really, the extra complexity introduced by the “reset password” option is very minor, and given the potential consequences of losing your data to an attacker, seriously compromising my security in favour of convenience in this way is inexcusably reckless, especially in a day and age when identity theft is a serious and growing problem.

Comments closed »

Posted at 00:55 on 15 November 2007.
Tagged: antipatterns, security