ACCU (http://accu.org/) is "an organisation of programmers who care about professionalism in programming and are dedicated to raising the standard of programming". Bletchley Park (http://www.bletchleypark.org.uk/) was the wartime home of the British Code and Cipher school, where the Axis' Enigma military codes were broken.

The conference was organised by ACCU as a benefit for Bletchley Park, which, despite being one of the most importants sites both in the history of Computing and the Second World War, is continually starved for funds and struggles to remain open and intact.

Bletchley Park is well worth a visit even when there's not special event on, but this conference was exceptional. I've been to three conferences in the last few weeks (they call came at once this year), and they were fairly different from each other - FOWA (http://phase.org/blog/31336) was a big conference that mixed business and tech, Stack Overflow a slightly smaller one that was purely programming with tasters of various languages and systems, and this one was, for me, a bit of a wildcard. The focus was on security and cryptography, neither of which are particularly areas of expertise for me, although they're definitely interests. I'm also somewhat fascinated by the history of the Second World War, and of Bletchley Park and Enigma in particular.

So, I didn't particularly know what to expect, except that some big names would be speaking on topics that should be interesting; and that it would benefit Bletchley. Oh, and that it meant getting up early on a Saturday to get to Bletchley by 9:30.

When I got there, it was a distinctly chilly autumn morning, but bright sun meant that the park and Mansion looked stunning in the morning. The mansion, if you've never seen it, is a unique building; it's not even the same as itself, in that no two parts of it seem to share the same architectural style:



I managed to grab a quick coffee and danish before Tony Sale started his talk. Tony is, quite deservedly, something of a legend at Bletchley; not only did he help start the National Museum of Computing and Bletchley Park Trust, he's also an authority on Enigma and led the rebuilding of Colossus (the world's first electronic computer) from absurdly little evidence.

He's also, I discovered, an excellent presenter. His energy and passion while explaining 'How the Germans gave away their "unbreakable" codes' by human error was incredible, and not only is he an expert on the Enigma machines and Lorenz SZ encrypted teletype system, but he can also present that material in a way that's simultaneously easy to understand, technically complete and entertaining. His resounding cry of "DURRRRRR" when describing a particularly foolish operator error is something I'll remember fondly for a long time. The talk was obviously widely enjoyed and led to one of the most heartfelt rounds of applause I've heard at a technical presentation.

Video of Tony talking on some of these subjects, and a mass of information on Colossus, Enigma and the Lorenz system can be found on Tony's site at http://www.codesandciphers.org.uk/

After Q&A from Tony, and coffees, we were given a guided tour of National Museum of Computing, featuring the Lorenz intercept and decoding station, the replica Colossus 2, and some (marginally) more modern exhibits such as the Witch computer, early mainframes and desktops. It was great to see the Colossus actually running and explained by Tony. We also got an explanation of the replica Bombe - all elements visible on the standard public tours at Bletchley Park, but given today at a more involved and technical level for a much more technical audience.

Colossus:



The Bombe:




After that, lunch (a mass of buffet sandwiches, hardly Cordon Bleu but pretty edible) and then Phil Zimmerman.

Phil, of course, is the creator of Pretty Good Privacy, a project based on Public Key Cryptography that sought (as Phil put it) to give political groups such as the american peace movement, and similar groups worldwide, the privacy to operate without government surveillance and interference.

For his pains, and his attempts to export this cryptographic system (classified as a munition) worldwide, he spent years under federal investigation. While he still seems to feel he did the right thing, his new project takes a very different angle.

PGP, as Phil puts it, was "a reaction to government attitudes to cryptography that were born, in part, at Bletchley Park"; that is that cryptographic security and research had to be the preserve of governments and military, tightly controlled and under the utmost security.

Phil's new project is ZRTP, a secure but open-source telegraphy protocol which he classifies not as a political project to protect citizens from overzealous goverments, but as a necessary technological project to protect all of us - including governments and the military - from global organised crime. He cites the increasing risk of interception of voice communications as they move off relatively secure PSTN networks onto inherently public IP networks, populated by packet sniffers and zombie desktops, and thereby open to interception by crime syndicates which may use the information for blackmail, insider trading or aggression. This technology is used, for example, by police in the south-west of the USA working against Mexican drug smugglers, who would otherwise have the capability to intercept these communications.

As well as ensuring an encrypted channel for voice communications, the ZRTP protocol has an impressive range of measures to prevent interception by man-in-the-middle attacks, which I didn't quite understand well enough to explain here...

Phil also had a very long Q&A session and a lot of technical detail, which I won't cover in much depth, but I'll drop in a few quotes (which I hope are accurate if slighly paraphrased - none of this was recorded, sadly) which give the tone:

"You can make a case that ... the harm from governments losing the ability wiretap theis citizens ... is much less than the harm that would result from criminals wiretapping us".

"Our protocol ... will affect organised crime more than governments ... as criminals tend to be more interested in the content of messages (for blackmail, interception etc) whereas governments tend to have to rely on traffic analysis against criminals using codes and codephrases".

In a response to a question on how his product differed from Skype: "Skype... won't release source code, or even say how their security works. How can I trust that?"

"The UK and China - the two greatest observation infrastructures in the world... How do you guys put up with it?"

After a fairly involved - but fascinating - discussion of key exchange, entropy and crime with Phil, we changed tone again with a talk from Simon Singh, starting with Stairway from Heaven - played backwards.

The first time you hear this extract, even if you're told there's a voice in it, you won't hear much. Then, when you're told what the message is (Simon ran this through a karaoke-style word highlighter), it's so clear you can't believe it's the same recording.

However, all this proves is just how far the human mind will go to find patterns and messages where none exist.

Then, an example of the importance of code security, in Mary Queen of Scots' intercepted plot to overtrow Elizabeth the First, easily decrypted even back in the 16th century, which led to her execution.

Simon's main talk was about the Cypher Challenge which featured in his Code book, and how it was solved. This featured substitution cyphers and frequency analysis, book ciphers - and the importance of finding the right book, Enigma machines, and how to accidentally turn a triple-DES challenge into a single-DES one. The talk included a demo of Simon's very own original Enigma machine - which of course obeyed the universal law of demonstrations by refusing to encypher symetrically. However, Phil Zimmerman was almost entranced by it, a reaction I can thoroughly relate to!



Finally, back to the human ability to treat coincidence as revelation, courtesy of "The Bible Code", which claims that hundreds of prophecies are hidden within the Bible. However, the bible is a vast corpus of text, and once you give yourself loose enough rules, you can "find" messages all over it. However, you can also find remarkably similar messages in Moby Dick using those rules.

Simon's summary of a range of historical ciphers and code-breaking rounded the day off well, and was followed by a few words from Simon Greenish, Director of Bletchley Park. He recounted that, while Bletchley Park is one of the most important historical sites in the UK, at least in terms of technological and military history, it has existed on a shoestring. "It has often bumped along the bottom financially... and very nearly didn't make it on more than one occasion". Fortunately it's now in slightly less dire straits, but still needs more funds to do more than just survive - there are now vast amounts of repair and restoration to do, before fulfilling the plans that will make the site a truly outstanding museum.

Fortunately, the day raised around £7000 towards these efforts. It was an excellent day, and I'll be delighted to retun if, as planned, it's repeated next year.

My good friend @barneyhanlon has been specifying the next release of the SVN version control system recently, with some help from our design team:

More of their contribution can be found on flickr

The latest version of Subversion is in alpha, and a list of new commands are in testing. I've added a list of some of those currently in testing so that you can familiarize yourself with them. Note that as the product is in alpha this will be a growing list as I believe there is a "wishlist" system going on.

svn repent
Used after another repository user has set svn blame. Indicates that the user acknowledges the fault and is very sorry.

svn resent
Used either after an svn blame function or to show disaffection with version control. The flag essentially shows that the use of Subversion in general is causing them distress.

svn relent
Used to either stop the above two commands or to stop arguments regarding changes to a committed file.

svn revolt
Turns the svn client into a simple FTP program, bypassing the version control system.

svn commie
Flag to show that the user has an ideology they wish to express. Allowed flags are -che, -stalin, -marx, -lenin, or -lolcats

svn tor -rent
Turns the subversion client into an anonymous Torrent client and hides the resultant .iso files in the repository. If used in conjunction with svn blame, then the IP address of another user is stored so the RIAA will seek legal action against the other user.

svn odd
Marks that changes made by another user look weird.

svn picard
Immediately makes a file live, sucking the entirety of the company bandwidth to do so, and bypasses the sysadmin.

svn ensign
Sends a request to the sysadmin for a tag and release, attaching a lolPicard to the email with the -caption attatched. The default caption is "wtf is this shit?"

svn fu man chu
The file is deleted, but the world shall here from it again.

Apparently there's a rule that every twitter user and blogger has to tell Twitter how to run their business, and now it's my turn.

OK, wind back a bit. Twitter is taking the world by storm; it's an excellent technology and has massive takeup; it may be a game-changer.

The bit that's (frankly) scaring everyone is that it has no income stream or business model. That raises the risk that it might Go Away™, and for large number of people who make serious use of it (or are building sites and businesses around it), that's an alarming possibility.

True, there are other services such as identi.ca, seesmic and brightkite, but none of these seem to have anything like the takeup. And I'm not sure that we can support a multi-provider environment as we have with instant messaging.

There are also two particular technical problems that bug people, and that they want fixed. One is the occasional downtime, and the other is the total lack of key-based or limited authentication in the API. The latter is that one that *really* bugs geeks; Twitter is perfectly placed to be the poster child for OAuth, but instead it's the king of the Password Antipattern - every site that wants to interact usefully with your twitter account has to ask for your username and password. This, frankly, sucks; any site can thereby easily hijack your twitter account and "spam" from it; and you can't de-auth one twitter-using site without de-authing the lot *and* having to re-auth all your twitter clients.

So, recommendation one: Let's have OAuth in Twitter. Free, please.

OK; we need money. Lots of money ideally. Ads aren't likely to go down well in a distributed messaging/ multicasting system. So we need to find an itch to scratch, something useful that's not essential (there's no point making basic accounts non-free, that'd kill the service) but would be Really Useful.

Various ideas spring to mind (which, frankly, the guys at Twitter have probably already thought of):

Paid "firehose" access - ie, access to *all* twitter posts. The problem here though is that's an astounding amount of data. Even if Twitter had the ability to send this data out to multiple source, most recipients simply wouldn't be able to receive it fast enough.

Increased feed calls: Every user is currently allowed 100 API calls per hour, which is plenty for basic users, slightly borderline for heavy users, and not nearly enough for "commercial" or professional use.

Customisable profile pages. At the moment, you can post a 160-character bio and set a background image. This has lead to some inventive solutions - even mine is quite decorative. There's capacity to improve this a bit, but how much, and whether people would really pay much for it, I'm not sure.

One thing I wouldn't ask for, though, is longer messages. Technical limitations aside, longer tweets wouldn't be the same thing; they'd be IM, email or blogs. In this case, twitter's limitation is its strength.

Premium service levels with increased uptime are also an idea that look better on first glance than on consideration. Improved service for some implies lesser service for others, and you have to be really careful with that.

I'm sure I had a couple more ideas. In the meantime, what are yours?

It's not polite to mock the stupid. But when a major company like Apple does something quite this astoundingly dumb, the only real option is to propagate it as a warning to others. And I don't mean just other .mac users. I mean other tech support teams or webmasters who might think that sending out passwords to unvalidated addresses is a good thing.

(Or root SSH keys, for that matter. You know who you are).

I've commented a few times on just how bad customer authentication is in the UK's banks, but hadn't got around to blogging about it. Now that the UK government's managed to achieve one of the greatest confidential leaks of modern history, it might be worth doing so.

So, for those outside the UK, or who might, for other reasons, not have heard about this story:

Two computer discs holding the personal details of all families in the UK with a child under 16 have gone missing.

The Child Benefit data on them includes name, address, date of birth, National Insurance number and, where relevant, bank details of 25m people.

From http://news.bbc.co.uk/1/hi/uk_politics/7103566.stm


Now, NI numbers (approximately equivalent to US Social Security numbers, although much less widely used or risky) are definitely sensitive data. Bank account numbers, while not an explicit risk by themselves, become a very useful target for identity theft when coupled with, for example, full names, dates of birth and addresses. The extra security information you tend to need are your Mother's maiden name and some sort of signature or PIN. Online and phone banking systems sometimes only ask you for two digits of passcode (sometimes from as few as four) to gain full access. And, to start a standing order, or direct debit, little more than the above data seems to be required.

There also seems to be an incredible superstition held by banks that your mother's maiden name and your date of birth (and sometimes place of birth) are mysterious and unknowable. One has to assume from this that banking security experts are lonely people whose friends never remember their birthdays, and to whom they never talk about themselves. In particular, none of them are amateur genealogists, as their insistence on making such family data dangerous to share is a downright nuisance to anyone wishing to trace their family tree.

These data are, frankly, not secure, and nor should they have to be. Part of the essence of a good password is that it is hard to guess. Another is that it can be changed when required. A third is that it has no external meaning. Personally fixed data like this are therefore about the worst things you can use as a password.

A signature's not much better, as the growth of chip-and-pin cards attest. They are (comparatively) easy to copy, and no-one ever really checks them anyway.

And these authenticators are only useful if they're fully checked anyway. Often enough banks staff and so on seem to assume that, if you ask for something belonging to someone, then you must be that person. Defence against social engineering is shoddy at best, and staff, if they follow procedures at all, just tend to go through the motions without understanding what they're doing or why they're doing it. There needs to be a wholesale revision of the methods of, and approach to, data security in this country.

But, as yet, the data that's escaped should not be enough to access bank accounts without either serious extra work, extremely braze social engineering, or guessing of passwords. As in, it's hard - not impossible.

Of course, since many people use their children's names or birthdates as passwords (remember War Games?), that may not be so difficult.

The highest risk at the moment seems to be that of extremely convincing phishing attacks. Currently my various banks authenticate emails by addressing them to my full real name, and including some part of my account number, or my postcode.

In fact I'd also expect an opportunist wave of unsophisticated "To protect your data after this leak" phishing - which doesn't even require the data to be in bad guys' hands.

But, do the bad guys have it? The police and government "reassure" us that "There is no evidence that this data has fallen into criminal hands". This is one of the most astounding pieces of weaselling that either party has ever acheived. One might also ask, since no-one knows where the data is (and recall that, even encrypted, it can be infinitely duplicated), what evidence there is that it has *not* fallen into criminal hands.

There's also considerable doubt about the security measures placed on the data - according to government sources it was "password protected but not encrypted" - which is complete nonsense, and therefore probably wrong. If the data is not encrypted, it should all be assumed to be in the wrong hands. If weak encryption was used, data criminals have large enough botnets of infected, hijacked machines to make short work of it. If strong encryption was used - and given the complete lack of other security considerations taken, this seems unlikely - then perhaps we are more justified in just crossing our fingers and hoping for the best.

And that's what most people seem to be doing anyway, taking the approach that "nothing bad will happen to them". This might be pure fatalism; it may be trust of government (and bank) weaselling, or it might just be a complete unawareness of what can be done - as noted above, most of this data cannot be changed. I suspect that, under these circumstances, I'd be strongly considering changing bank, or at least getting them to re-assign my account number - which would admittedly be a massive nuisance. We have to give our bank details to so many people that re-providing it would be as complex as changing address when moving house - more so in fact, as there would be no realistic possibility of assisted notification or redirection services without further compromising security.

Now precisely what use is this to anyone? I can't back up my files in a usable fashion because I want my home directory to be secure? I have to log out to achieve even the monolithic protection of being able to restore my entire home directory in one lump? I don't log out; I lock my system and hibernate it; it's a single user system and the hibernation works extremely well.

And to add insult to injury, this is the error message I get *after* spending hours decrypting and re-encrypting my home folder, discovering backups were silently failing, and turning TimeMachine off and on again. The first time I tried this after upgrading from Tiger I was told that "Your home folder cannot be backed up as it was encrypted with a previous version of OS X. You will need to turn FileVault off and on again to enable Time Machine backups" (this is not verbatim, I didn't expect to need to screen grab it). And I get a little help dialogue (or possibly a link to a video, I don't recall now) showing me how to do this, and how to chose 128- or 256- bit security. Except that when you try and to that, it gives you no such choice, takes hours to de- and re-encrypt, and still doesn't let you back up anyway!

It would appear that the FileVault and TimeMachine teams at Apple are not on speaking terms, and that neither are giving correct information to the documentation team. This is shoddy, and the differing dialogues suggest that this is an incomplete feature that was rushed to release.

For now, I'll be sticking with Retrospect backup. That backs up what it claims, including FileVault folders, encrypts the backups on request, and restores properly. The interface isn't what you'd call user-friendly, but still it's a bit more friendly than a system that turns around and says "Oh, I didn't back any of your personal files up - didn't you guess?"

So, the background level of corporate / self-righteous complaint about ad-blocking software has boiled up again, to the extent that some webmasters, whether independent or corporate, are threatening to prevent site access to users who might be blocking adverts.

Now, this is one of those knee-jerk reactions that just opens up a whole world of dumb, for numerous reasons:

1) Many users are, rightly or wrongly, so morally opposed to on-line adverts that they will flatly refuse to click any ad links. Forcing them to view these just wastes your, or your advertising network's, bandwidth, and their time. Eventually you'll just push them away.

Why does this matter? Do you care about non-paying viewers? Well, this sector contains a significant proportion of technically savvy users and opinion-formers. Chances are, if your site has a community element, they may also be significant contributors there. You may, quite possibly, be pushing your best users away.

2) Some of these adverts are so intrusive as to severely degrade the user's experience of the site. Adverts that automatically play audio when you arrive on a page, for example, are going to send people straight away again - if they can hear them. In this case users may actually be doing you a favour by preventing these from blocking the audio and sticking with the site, rather than just turning tail. Office workers, who may well have a legitimate reason for visiting your site - say you're a technical review site or IT magazine - are not going to put up with sites that embarrass them at their desks.

3) Some adverts are actively harmful, and users are seeking to protect themselves and their systems by blocking them. These ads fall into two types.

Firstly, adverts that act as a conduit to install adware or other malware. I had something of a fight earlier today with a piece of in-page software that was determined to make me believe that my PC was infected with malware, and refused - for my own good - to let me navigate way from the invasive page. Now I'm sceptical at the best of times, and the fact I'm using a mac, not a PC, was a fairly conclusive giveaway. But, had I been on a PC, I'd have seen what appeared to be a popup from the system tray, followed by a number of system warning dialogs, and an automated scan starting. No doubt this would have then "found" something which would have required to me to install an application - possibly after payment - onto my system to "fix". What that app would have really done to my system I leave as an exercise to the reader. In any case, I think you'll agree that the advert was morally beyond the pale.

And this wasn't on a disreputable webpage either. It was on a respectable blog host who happen to use a (theoretically also reputable) third-party advertising supplier. This supplier, however, seems to be incapable or uninterested in maintaining their reputation and quality of their adverts, and so open a channel for disreputable advertisers to attack the end user. In most businesses, damaging your end-users or their property would be seen as a Bad Thing. I can only assume that adversing suppliers have some strange new business model in which this doesn't matter. Which, in turn, makes them, for all their vaunted professionalism, no better than spammers.

Secondly - damaging the end-user? How can an advert harm a *human*? We'll leave aside the case of bad, untested, forged or misprescribed drugs for the moment, and go for the direct approach. Some humans are very sensitive to flashing or flickering lights and colours, and to particular patterns of movement such as apparent fast or shaking movement. I'm mildly photosensitive - flashing lights at certain frequencies can give me a headache or, at worst, call me to gray out. And I'm not even particularly sensitive; I'm far from clinically epileptic. These ads could do some real damage to some people. The presumption of advertisers that allow this has to be that they simply don't care about human health.

4) If we now accept that some, if not all or most, users actually need to block some or all adverts, the policy of trying to "kill off" these users seems particularly foolish. But the dumb goes even further. It's at best hard to know if a user is blocking adverts, so the sites are either going to have to rely on fallible heuristics or sledgehammer tactics. One I've heard widely suggested is entirely blocking the Firefox browser from some sites, since it makes it moderately easy to block many forms of adverts. The problem is that Firefox is widely used by the technically savvy opinion makers who might buy your content or recommend your site - keep them away and you might as well just shoot yourself in the server rack. Ultimately, site owners are not going to be able to keep even the 'wrong' users away without a lot of collateral damage.


So, ad-blocking good, ad-blocker-blocking bad, right? So, where do the sites get their revenue if users aren't going to see the ads? Surely they'll all shut down, bankrupted by all those evil ad-blocking users, and won't that serve us all right?

Erm... No. Not unless the site owners have a complete failure of both intelligence and imagination - which is, admittedly, not unknown. Site owners, in conjunction with ad networks and users are, however, going to have to do some thinking - starting off, in the case of the ad networks, by policing their houses rather more carefully, and acting much more quickly against rogue, lying, or damaging adverts. Site owners need to recognise that they are a customer of their ad providers, and that they should not be making themselves look uncaring or foolish by accepting damaging adverts. Ad networks need to recognise that they, as businesses, have certain legal and moral responsibilities, and will also harm themselves if they fail to meet these. And users need to be involved in a trusting interaction with sites; if they are getting benefit from a site, then it is reasonable to expect them to give something in return. New income models may need to be found - pro accounts, paid features or non-invasive ads may be a couple of examples, but there's definitely room for some imagination here.

In the meantime, sites and ad networks need to stop trying to ram increasingly harmful, irritating and irrelevant adverts down their users' throats, and I thoroughly encourage site readers to contribute to this progression by actively blocking invasive material - ultimately it will be in everyone's best interests if we can all outgrow this ridiculous online advertising war.

Creating and remembering passwords is, for many, one of the biggest hassles of using the 'net. Many people try and short-cut the process by chosing one simple, memorable password for everything, and never changing it. Sometimes they'll keep a note of it either in their wallet, or on their keyboard. In a recent experiment, researchers found that the majority of users would reveal their passwords for a chocolate bar or similar.

But why does it matter? Surely no-one's actually going to bother to hack *your* account - you might consider that:
1) You're not an interesting target
2) There are so many accounts out there that the odds of yours being picked is minimal
3) You're not actually *that* worried about revealing the data anyway.
and
4) your network guy at work or tech friend are just enjoying a bit of scaremongering or a power trip.

Unfortunately, (to use an astoundingly cheap literary construction), it don't work like that. Even chocolate bars aren't required to hack systems; pretty much any password-protected system these days can be hacked automatically - whether it's a website password, an email one, or a server login.

For example, security logs on a little-used, nondescript remote server I help administer reported around 500 password-guessing attacks on Sunday - in 3, 5-minute bursts. From Poland.

Now, I don't actually know anyone Polish, but apparently they don't care about that. Chances are they didn't know who they were aiming at either - they just fired up a script and went off for a nice cup of something Polish.

I've no idea how many people try and hack my blogs and webmail accounts, as I don't get to see the security logs from those. But I'm sure they're just as fun a target.

So, strike 1), strike 2). Does it matter? Well, if you're talking about a closed system, where you have no privileged data, and you don't mind having everything of yours read and/or deleted, and the user faking your identity to send spam and attack other systems, then, perhaps not. But chances are, there's something in there that you or someone else would rather keep private, and you'd rather protect your reputation from being labelled as a spammer or hacker. And remember that most websites, and many related online system, will send helpful "reminders" of your password to your email account - so if that's compromised, everything's up for grabs.

Equally, it's not always only your data that your password compromises. For online communities such as Facebook, MySpace or LiveJournal, your password grants access to your frends' private posts, data and contact info. So a compromise in your account could affect a whole lot of people. And at work, a compromise in email can cause major commercial loss or embarrasment (Dear Our Biggest Client, F*ck Off, signed My Hacked Account), or loss of data (Someone used your access to delete the financial records? Sure, we have backups - but they're yesterday's data, and we'll have to take the system down half a day to restore them.).

So, hopefully, strike 3). Oh, and 4)? We've got *much* better things to do than scare people, trust me. Working out why the server keeps hiding the boss' email is a particular favorite, for example.

So, if you believe that you need a secure password (and I really hope you do), how do you create one for each of the dozen systems you use?

Well, if it's any consolation, I apparently have over 350 passwords. I use a secured password manager to hold this lot. Most of you will have a rather less scary task.

Livejournal, for example, will happily tell you what a secure password looks like:
http://www.livejournal.com/support/faqbrowse.bml?faqid=71 says:

Your LiveJournal password must meet the following requirements:

* 6 to 30 characters long.
* 4 different characters.
* 1 number or symbol.
* ASCII characters (characters found on a standard US keyboard).
* Not based on your username, email address, displayed name, or a commonly-used password.

Yeah, fine, but how on earth are you going to remember it without writing it down and so risking people seeing it?

There's a few tricks, which provide a range of levels of security:

1) Use two words, joined by a number, and mispell one of them (skwid8KIPPER)
2) Play "catchphrase": eg 9tiSTITCHme approximately equals "A stitch in time saves 9"
3) Take initial letters of a favourite book, act, album or track, eg:
40SoR:KSR (40 signs of rain, Kim Stanley Robinson)
pT3L3X-RH (Planet Telex, RadioHead)
4) This trick also works well with near-random phrases, which (research suggests) you'll recall better if they're slightly rude or outrageous (mbFsl99YoG - my boss' feet stink like 99 year-old gorgonzola, nouns capitalised). PS - boss - they don't, it's just an example, really.
5) Don't use licence plates, mother's maiden name, pet names, phone numbers - you'll run out, and someone will guess anway.


But, if the attackers are using automated tools, what good does a "secure" password do anyway?

Well, the good news is that these automated tools can't practically "try" all password strings - in an 8-character password, for example, there will be about 45^8=16,815,125,391,000 options. Even if each attack takes a fraction of a second, it'll take tens of thousands of years to try them all - and that's if they *know* it's exactly 8 characters. So most attack scripts just check simpler possibilities - dictionary words (particularly 'password', 'secure' etc) with basic numberic substitutions, variants on the account name or email address, and numeric strings. The further you get from these "easy guesses", the longer it takes the script, and the higher the chance it'll either give up or run out.

Whatever trick you use, it does pay to change passwords every few months. If, like me, you just have too many to recall even with the above tricks, you can look at password apps (which encrypt the data they store) like Password Safe, KeePass, or a similar app for your PDA or mobile phone. Whichever you use, though, you'll still need one *really good* password to lock it with.

If you write PHP code, and want to make any pretence at security, read this book. Clear enough? This book's not cheap at something over £20 for 100 pages, but it's clear and readable. You won't find every potential security flaw in your PHP code in here, but the vast majority are covered and the techniques advised will cover most eventualities. Plus you can follow Chris Shiftett's blog at http://shiflett.org/ to keep up to date.

PHP is often criticised as an insecure language - in fact it's an easy and powerful language that gives you enough rope to hang yourself. In particular, because it's easy to pick up (and I'd recommend it as a first language) it's used by new programmers who aren't security aware. This book isn't ideal for the PHP newcomer - you'll need some understanding of the language, but with that you'll find the content of the book clearly laid out and easy to follow. Even if you're already aware of many security issues, this book will add a couple more and act as an invaluable checklist.

Update It's been pointed out to me, quite accurately, that this book is not a complete guide to securing PHP applications; however I feel that its small size means that developers have no excuse for not reading this, or a more complete, book; reading this should at least make you understand what it is that you need to learn about.

Well, that last-but-one post proved to be rather more prophetic than I'd intended. Rest assured that, like 99.999% of London's population, I survived July without getting blown up. In fact, it's been another case of "too busy doing to document":

I've launched another site off this codebase: http://www.londongamelist.org/

Calendar: there's a graphical calendar view in place now, which can synchronise from iCal (and thus, indirectly, from most PDAs).

Filestore: Improvements to the upload system - in paticular fixes to handle the fact that MSIE uses some very strange mimetype declarations on file upload (image/x-png and image/pjpeg in place of image/png and image/jpeg, for example) and the ability to set icons manually (as they can't generate for Really Big images).

PHP code quality: I've turned on E_NOTICE and E_STRICT error levels on several sites using this codebase, which means I've had a fairly major task of updating code to the strict PHP5 way of doing things, and made sure all variables are pre-declared. A long task, but it should cut down on future debugging. (there are probably a few stray notices floating around this site - do let me know!)

AJAX: Many ajax tutorials advise you to use text rather than XML as your ajax page format, but also advise that you use the line
http_request.overrideMimeType('text/xml'); to force the behaviour of your XMLHttpRequest object
The new Firefox 1.5 betas throw errors on this in the (now misnamed) JavaScript Console (it now serves as a fully-fledged error console) which I've explained in updates to this page on DevMo:
http://developer.mozilla.org/en/docs/AJAX:Getting_Started
These errors can be pretty tricky to debug, particularly when they appear as JS errors...

XSS: Nasty stuff. Cross-site scripting occurs when you accidentally let a user manipulate the content of your website, either by submitted content or URL manipulation. This codebase caught most of those tricks, but at a recent talk by Rasmus Lerdorf at PHP London I discovered one that I'd completely missed: PHP_SELF. Needless to say I've done quite a few bugfixes on that one now!

MySociety: I've recently joined the MySociety group (http://www.mysociety.org/), and submitted a few code fragments - this is probably going to be a focus of my coding efforts from here, although I'll still be working on this site's codebase, particularly if there's user interest. For a start, there's a couple of external libraries that I can now jettison, due to PHP5 improvements.

I've also been to Linux World Expo, looked at picking up some LPI and MySQL certs, bought an iPod Nano (yes, they *do* scratch far too easily, Apple!) and started listening to Podcasts. Busy life.