Web single sign on idea in a slashdot post

[Chris Hammond-Thrasher]

Perhaps some of you have been following the slashdot discussion on 
the recent Berkeley paper on "Security Skins" and single sign on 
using the human ability to distinguish between faces. (See 
http://it.slashdot.org/article.pl?sid=05/05/26/1725228&tid=172)

Burried in the discussion, as user named baadger proposes a web 
single sign on idea that might interest this group. You can read 
the post at 
http://it.slashdot.org/comments.pl?sid=150801&cid=12648451 , but 
here is the meat of it:

<slashdot_quote>
Registration process
--------------------

* Your client side script or extension takes your master password 
and appends 'thewebsiteyouresigningupto.tld' or 
'generic.webhostorisp.tld/website/path/' to the end, perhaps with a 
nice seperator
* MD5 (or some other) hash this string using javascript or client 
side code. This becomes the website 'registration hash'.
* The server stores this directly into it's user database without 
any further manipulation.

Login process
-------------

* Server generates a random string (the current time since the 
linux epoc would do) and sends it in a hidden form field. Call this 
the session string.
* The client takes master password appends the website dependant 
domain or uri etc and reproduces the registration hash for that 
specific website.
* Take the registration hash and append the session string sent by 
the server and hash it again. This becomes the 'login hash' that is 
used only once, for this login only.
* The server retreives the registration hash from it's database, 
appends the same session string that it sent to, and kept 
associated with, the visitor and hashes it to produce the same 
'login hash'.
* The server compares this expected login hash to the login hash 
from the user and authenticates the user if they match.

Pros
----

* No information that can result in successful authentication for 
different session is sent across the wire.
* The user gets to hash their password client side so doesn't have 
to worry about whether the server side to storing it securely.
* The webmaster has no control over the client side hashing and 
can't modify anything their end to get your password to another 
website.
* The password for the website is unique to the websites domain/URI 
but the master password entered by the user can be used on any 
number of websites, this makes it easy to remember and conveinient.

Cons
----

* The registration transaction is open to a man in the middle 
attack - but at worst someone will only be able to comprimise that 
specific website because the registration hash is made unique to 
each website.
* The server side needs to be able to keep track of what session 
string it sent to the client - can be done by means of ip address, 
user-agent and cookie association etc. The server side also needs 
to ensure noone can authenticate for the current session by similar 
means.
* The worst one - if a website changes URL's then all the user 
passwords become invalid. But what the hell - send them all new 
ones by e-mail.

</slashdot_quote>