The exclusion of special characters mentioned in the editorial is a far too common bad practice. It's sometimes taken to extremes - characters with accents count as special, only letters without any diacritic mark are allowed and only letters from the current English alphabet (so no Þ for example) and passwords are case insensitive, and length must be 6, 7, or 8 characters (fortunately digits are usually allowed as well as letters). So there are only 36 different characters, and a character has an entropy of only 5.391 bits. I imagine the system mentioned in the editorial was case insensitive, giving 62 different characters so an entropy of 5.955 bits per character. Allowing "special" characters (but restricting to a reasonable 8-bit set) gives somewhere between 176 and 252 different characters so per character entropy between 7.457 and 7.958 bits (depending on the definition or "reasonable") but probably very few have keyboard shortcuts set up that allow more than about 155 characters (7.276 bits entropy per character) and don't want characters they can't type in passwords, and most computer-oriented people probably have shorcuts that extend the keybord reachable set to between 120 and 136 characters (so entropy about 7 bits per chatracter). Of course given that many websites will be used from countries with people from countries all over those parts of the world that use some variant of the Roman alphabet, we can expect the number of distinct characters used in passwords to be rather more than might be used by any individual user - for example an Irishman might use "ú" but not "ö", while a German would use the latter but not the former, so attackers not knowing the user's language would have to consider a larger set of charaters than those really available to the user.

Anyway, the meaning of "not reversible" changes as computers get faster. So more entropy per character is a good idea. But even with about 176 different characters I don't want to use passwords with fewer than 16 chracters for anything important, and some of my financial passwords are longer than that.

A long time ago I spent quite a bit of "spare time" effort on designing an adjustable slow hash algorithm because SHA1 was not slow enough to peven preproduction of hash dictionaries, so an attacker who manage to bag the hashed passwords and the seeds would have no difficulty taking over ever user's account. Adjustable because if it was too slow it would mean unacceptable login delay, while if it wasn't too slow now it would probably be too fast the year after next, so the number of rounds of some aspects of the algorith would have to be changed (and the hash recomputed, probably with a new and longer seed as wll as extra rounds) immediately after a user still having his password stored as hashed by last year's version logged in. Unfortunately the collapse of the bursting of the high tech baloon killed that off befoe it was completed. I still think something of that sort will be needed in future, but there were a lot of flaws in the way I was approaching it and when (of if?) someone does it they will have a different approach.

edit: Of course I don't remember passwords like F%$Qv142&szc1c@é|?hogTY^Ýò, I let password safe do it for me.