Remosi's Rants

I’m sick of typing usernames and passwords into webpages all across the Internet. Like most people for most “low security” sites I use the same password. I use my browser to remember passwords for me so I don’t have to. I’m lazy. But the thing that irritates me more than having to login to all these different sites is the fact that I have to implement new authentication systems all the time. Create a new website? Write yet another authentication system.

So I thought I should do my own Single Sign On system. My goals:

• It should be secure (duh!).
• You should be able to run your own SSO server.
• It should only do autentication. It says “this user is l33tkiddie but doesn’t do anything about telling you l33tkiddies email address, or credit card information or even name. As a website it’s up to you to collect their details. I’m just doing authentication
• You have the right to not be able to be autenticated without your explicit permission. (Although you may waive this right)
• Be simple enough that anyone can use any server. You don’t need to pay $10,000US per year for permission to use it. It’s an open protocol, anyone can add support for SSO, anyone can run their own SSO server for their own users.
• Authentication servers are not tied down to username/passwords, they are free to authenticate you via other methods (client side SSL certs would be one example).
• You don’t need to trust the site that’s authenticating you. ie, you don’t ever give them your password
• Make phishing attacks hard
• You can have multiple identities. eg, Isomer the Undernet Oper, Perry the programmer, and l33tkiddie the warez courier.

Things I’d like (but not so sure about at the moment)

• Sites not being able to aggregate user data between themselves. Each site gets a userid token which represents you, and each site gets a different token. Two sites can’t figure out you’re the same person without outside help
• The ability for sites to correspond with you without your email address, and for you to know which site sent you the message and be able to revoke a sites ability to contact you at any time.

Things I’m relying on:

• DNS is secure (ha!)
• SSL is secure (heh)
• Users aren’t terminally stupid. (bwahahaha)

So my idea of how you’d implement this is as follows:

• You goto sitea.example.com and it asks you for your username. You type in perry@secure.meta.net.nz
• sitea.example.com sends a redirect to https://secure.meta.net.nz/auth?user=perry@secure.meta.net.nz&return=http://sitea.example.com/login&amp.ccokie1= where cookie1 is a sha1(user:secret:time) where secret is just some secret that sitea knows.
• secure.meta.net.nz authenticates the user, and sends a redirect back to http://sitea.example.com/login&user=perry@secure.meta.net.nz&cookie2= Where cookie2 is a sign(hash(user,cookie1,return),secure.meta.net.nz’s) where it’s signed by secure.meta.net.nz’s private key, which sitea verifies by fetching http://sitea.example.com/public.key (and caching)

So, can anyone see any fundamental flaws in this? This should be safe against MitM attacks (I think). Fishing attacks can be thwarted by showing a different style of login screen based on the username and a secret to secure.meta.net.nz. Unless the fishing site knows secure.meta.net.nz’s secret they can’t replicate the correct login screen and thus the phishing attack is avoided.

Anyway, I’d like to hear peoples opinions. I’m going to try and code it up. The biggest problem at the moment is that things like php don’t seem to have public key functions.

Update: Some notes from various people:

• The antiphishing stuff would provide a different page to every user based on their username. This could change the colours, the layout of the page, the wording, the font (!), icons around the page etc.
• Authentication doesn’t necessarily require a password, you could show people 10 pages with a grid of 10×10 images on them. The user selects the right image in each page, this gives 100**10 different combinations and perhaps would have more entropy than passwords. (since people are unlkely to use their birthdate).
• Authentication could also use SSL client certificates from CACert or something.
• I forgot the timestamp to send back to sitea this prevents replay attacks.
• I forgot to send the original cookie1 back to sitea unmodified so that sitea doesn’t requre any extra storage (like syncookies)

 

This entry was posted on Thursday, January 13th, 2005 at 10:56 am and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.