Turn on, tune in, log out

British biometric passport

I hate logging into websites.  And I’m a master of it.  After a number of hassles with external websites revealing my passwords to the world, I now have a lastpass setup managing my login credentials and a google authenticator to keep my google identity (which is probably more important than my birth certificate) extra-secure.  And does this work?  Well, most of the time, but the other day I got logged out of a banking account and had to reregister because I got my details wrong 3 times in a row.  Was it my fault?  Well, maybe, but I don’t for the life of me know what exactly I did wrong  - or how I could avoid doing the same things wrong in the future.

I also hate writing login mechanisms for websites.  They always seem overly complicated – the sort of thing you wish could just be done better by someone else.

My first experience of a half-decent login system was with tripit.com.  With tripit, all I had to do was start forwarding emails to their email address.  I got an email back telling me I could go to a magic URL, where all my details were awaiting me.  But then it asked me to set up a password to secure it all.

On most websites, it doesn’t matter who I am.  It only matters that I am the same person I was last time I came to the website.  Why should I have to log in?  In fact, a lot of web sites recognise me and log me in automatically if I’ve been there fairly recently

So, Idea 1:  Instead of making me sign up to a website, just assign me a cookie, and then whenever I come back in – in a day, a week, or a decade, read that cookie, and log me back in.

This is simple.  It is session management.  Website writers are going to have to do session management anyway, so why not just have two sessions – a short term ‘is currently doing a particular thing’ session and a long term ‘is still the same person’ session.

There seem to be two big problems here:  Security and Multiple Browsers

The security problem is that cookies remain the same and are passed in plaintext.  This can be resolved, in part, by making all connections via https.  All the evidence seems to suggest https-only is the way to go for lots of reasons, so this is no big loss.  As for cookies remaining the same – well, the website can always decide to change your cookie on its own schedule (so long as you log in).  And because the cookie will be website generated, it will only ever work for that website – and if that website gets hacked, well, they probably have access to everything you stored on that site anyway.  No no huge risk, so far as I can see.  (we could probably do more complicated things like making the cookie you provide a public key, and making session initiation a challenge response procedure, but that probably isn’t needed)

The multiple browser issue is harder.  If I want to access the same account from two browsers, the cookie generated account issue is a problem.  Different cookies will be generated for each browser – meaning you are a different person at work and home.  There are three ways around this:

1 – add the ability to set a username and password to your account once you have logged in.  Let people associate different browsers with the same account by then loggin in with the username and password.

2 – add the ability to associate an email address with your account.  You can then request the site emails you with a way to log you in on other machines.  Since you’ll need to do this if you have the username password mechanism, you’ll proably have to do this anyway

3 – make the problem your browsers problem.  Come up with an way of identifying the cookies as shareable, then let your browsers choose a central location to allow them to be synched.  This is ideal as it also allows browsers to let you switch between multiple accounts with the same site.

So – this seems quite simple, but it seems you still need to write code to register an email address with your site (at least until all the browsers come up with a solution to synch cookies).  My suggestion here is:

Idea 2: someone needs to generate a web service which will manage the storing of email addresses and associating them with an internal representation of user ids.  All your site would have to do for registration purposes is provide a form which sent the email address and internal id to said service.  When a user wanted to receive a log in email, you would have to provide a simple request whereby you provided the email and your sites id, and got back the internal id.  You would then look up the id, then generate an email which would lead the user to a page which would allow them to access their long term session cookie.

some bonus ideas:

Idea 3: if I send an email from my valid account to ‘logmein@whatevermywebsiteis.com’, it should, by return post, send me an email that would log me in – meaning I wouldn’t have to do any setup work’

Idea 4: You could happily sign up with multiple email addresses.  The site should only send to the email address you request.

Idea 5: If you lose control of an email address, you may need to revoke it.  The best way to manage this would be to allow you to revoke all email addresses, then let you assign them again one by one.

xoxco makes a similar argument (which didn’t so much inspire this piece, as made me think there was probably something up the tree worth barking at)

You must be logged in to post a comment.

© Ben.Cha.lmers.co.uk
CyberChimps