Website security

A few recent goings-on (going-ons?) have made me think about website security. Firstly was the flurry of interest about Open ID, which is an open, distributed identity system. Basically you set up one Open ID account and use that account to log into websites, applications and services which support it.

It’s not without it’s problems, but in general it seems like a good idea. You just have to remember your open ID address (which, for me, could be the address of my website and then you’re prompted for your Open ID password. Easy, and it’s the same for every Open ID-enabled site you visit.

Secondly we’ve had a whole series of – frankly quite animated – discussions at work about persistent logins for web applications. You know the type of thing: you log in, ticking the “Remember me” button, and next time you visit (a few days later, perhaps) you’re logged in automatically.

Great, but that does intoduce some problems. Mainly that as long as you’re on your computer, under your operating system login, it works great. When you go to someone elses computer, or use another login, or (even worse) you don’t have any logins on your operating system and your computer gets stolen, lost or hacked – anyone can pretend to be you in the web application.

It’s a well-known problem, and most developers get around it by putting a sensible expiry time on the automatic login cookie, something like a week or a month works fine. But some want customers to never have to log in after they’ve done so for the first time. Ouch.

You see, if we think that customer won’t be able to remember a password – even when we provide a “Forgotten your password?” link on the login screen – can we trust them to not load one of these indefinate login cookies on a non-secure system? I don’t think so, and once the cookie is there anyone just going to the right address has access to the data.

We’ll find a solution to this problem soon. We’re good at doing stuff like that; it’s what we do.

In the meantime, I had a thought. How about a browser plugin that handles security? My browser of choice has an entire universe of plugins that do all manner of clever things.

My thinking is like this. The user logs onto their operaing system (say, Windows) and opens a browser with the security plugin installed. Because the browser, and therefore the plugin, is part of the operating system it can get the currently logged in username and send that (via SSL) to the web application, which verifies it against a list of users. Perhaps a token/key could be used to make it even more secure. The web application then logs the user in as themselves.

That way, you log onto one system and the web application uses that login to verify who you say you are. Some websites with integrated Windows authentication use this already, admittedly without a browser plugin, but this way would be cross-platform (both client and server).

As long as you had the plugin (which could be verified regularly) and your operating system login was secure, you’d be laughing. Or chuckling a bit, at least.

Do you see any problems with that idea? Tell me, there’s normally something major I miss.

Playing the sharing

One of my favourite free music site is 3hive, although these days I rarely get a chance to download much stuff. The problem is I have to download something before I know whether it floats my boat, so to speak. Even with broadband that’s a few seconds per song, which soon adds up.

Not any more. If you’re a user of the greasy monkey for Firefox, you’re in luck. Just download this GreaseMonkey script and you’ll get a little Flash player below each download link. You can preview each track before you download with a mere click of the mouse. The Flash player was written by Jeroen Wijering and he’s kindly giving it away free. In this version of the 3hive player the Flash file is run from my website, but you can easily amend the script to run the file from somewhere else.

Happy listening!

More Performing

There are a couple of new functions I’ve got in development for my unobtrusive JavaScript library. I’ve you’ve not had a look at what Performer does then have a ganders now, I’ll be waiting.

Anyway, new functions. Firstly I’m doing a simple Submitter function that will listen for a form being submitted, intercept the submission and send all the data in the form to the processing page. The response from the processing page is then loaded into a named element on the page. Simple, but I think I’ll be using that a lot, and I hope it will be useful for other people too.

Secondly I’m doing a Popper function which (amazingly enough) pops up content fom a remote page based on passed parameters. So it could be used for an image gallery, or perhaps in-page help. This function, unlike most of the Performer functions, is pretty dependent on some CSS, so I’ll be making the Performer.css file available along with the JavaScript file when those functions are released.

As normal, these additions shouldn’t break anything you’re currently using, but if you do see wierdness please let me know.