Thu Mar 29
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.
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.