[thesite] how ueue works

[Mark Nickel]

On Thu, 18 Oct 2001, Martin wrote:

> OK, say J R Hacker's got a meo account & you visit his
> His site reads and reports your cookies as
> userid = 5
> userid_hash = 3cc076a28ccb2505ea525aca65e1185b
> 
> When JR visits his SuperSexySecretUEUESet page, he picks
> which user ID to have today, and it sets those same cookies
> to his browser.
> 
> JR then visits (say) aeo and wreaks havoc.
> 
> How do we stop that?
> 

By introducing a subsite_secret_key that is assigned by ueue.evolt.org
which is unique to each subsite?  :)

ueue.evolt.org will maintain a list of all subsite's and issue each
subsite a secret key.  When the subsite passes user authentication up to
ueue.evolt.org, it includes a MD5 hash like this:

subsite_id_hash = MD5($subsite_secret_key.$ueue_server_secret_key);

Then before ueue.evolt.org does the user authentication and sets the
user_* cookies, it will verify that the authentication request has come
from a valid subsite server.  

If you look here:  http://members.evolt.org/garrett/uetest/register.phps,
you'll see what I'm talking about...  

Here is the ueue register emulator:
http://members.evolt.org/mnickel/ueue/ueue_register.phps that the form on
garrett's site POST's to.

ueue.evolt.org should probably build the user_*_hash using the following
formula:

userid_hash = MD5(userid.$ueue_server_secret_key.$subsite_secret_key);

Then when the subsite validates the hash, it uses this method to verify
that the cookie is for it.

So, if the subsite were m.e.o, the haxor couldn't just use the userid_hash
for a.e.o. because a.e.o would have a different subsite_secret_key than
m.e.o.

Now you may ask, how can I go to a different *.evolt.org subsite when My
cookies are only for a specific subsite?  Ok, maybe your not asking
that... :)  :)

This process will be a lot of back and forth between the browser getting
redirected all over the place, but remember, we are doing this because we
don't want to do the XML-RPC BS yet... :)

Ok.

Now, my cookie jar is full of cookies that are signed by m.e.o. and I want
to do something on a.e.o.  So, I go to a.e.o.  a.e.o detects that I've got
cookies and attempts to authorize me.  It's $subsite_secret_key is
different from m.e.o.'s so the hash comparison failes.  a.e.o redirects 
the browser to ueue.evolt.org and includes a.e.o.'s subsite_id_hash.
ueue.evolt.org then picks up all this stuff and rewrites all the cookies
to be MD5'ed with a.e.o. $subsite_secret_key.  ueue.evolt.org redirects
back to a.e.o. and a.e.o. can now properly authorizse the cookies...

This will necessitate adding a 
user_passwrd_hash = MD5(user_password.$ueue_server_secret_key) 
cookie.  Obviously we won't need to have the plain text version of the
user_password.. :)

When ueue.evolt.org gets the redirect from a.e.o. it will verify the
users_password_hash.  Then it will be able to reMD5 the cookies to include
the a.e.o. subsite_secret_key...

whew...

I hope that this somehow makes sense...

Garrett and I will work to include these new cookies/hashes into the
prototype so you can see a little better what's going on....

 
 
> Would it be better to hash the password?
> btw, you're right - MD5 is *super* cool.
> 

As you say, Martin, yup, hash the users password so that only the
ueue.evolt.org will be able to authenticate the user and rewrite cookies
to include new $subsite_secret_key's as the user moves between *.evolt.org
sites...

Mark