Web single sign on idea in a slashdot post
chris.hammond-thrasher at hushmail.com
Fri May 27 08:49:59 PDT 2005
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
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:
* 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
side code. This becomes the website 'registration hash'.
* The server stores this directly into it's user database without
any further manipulation.
* 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
* 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
* The server compares this expected login hash to the login hash
from the user and authenticates the user if they match.
* 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
* 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.
* 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
* 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
* 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.
More information about the yadis