[MUD-Dev] Re: Quick question re: SSL

[Christopher Allen]

adam <ceo at grexengine.com> wrote:

> (depending on what response you come up with :) this might be
> worth posting on MUD-DEV, but it's pretty specific so I thought
> I'd ask via private email instead)

> A year ago I had an HTTP server front-ending a game server using a
> nice simple token-based authentication based on:

>  - user authenticates via SSL

>  - ...whilst still encrypted, SSL returns a cookie that is a hash
>  of > (username), (day-of-century), (IP Address that user
>  connected on).

>  - user's browser now uses non-SSL standard HTTP for all comms
>  with > game server; game server rehashes the same data wherever a
>  security > check is needed (usually once per page).

>  - ...(and the day-of-century) forces them to relogin once every
>  24 > hours).

> Unfortunately, it didn't work for 5% of players, and soon stopped
> working for up to 25% of players. Simple reason was a major ISP
> changing their HTTP routing from "everything direct" or
> "everything via caches" to "SSL direct; everything else via
> caches" which of course means you have a different IP address
> depending upon whether you connect via HTTPS or HTTP, and it
> breaks the simple token scheme :(.

> We're now faced with either using SSL for all game traffic, or
> allowing anyone who can snoop the HTTP requests and responses the
> ability to spoof as anyone else (nb: obviously SSL + relogin would
> be forced if you tried to view billing details etc, or change
> passwords).

> I'm thinking there must surely be a better way, but I can't seem
> to bypass the ISP's webcaches. I just thought you might know of
> something, given your SSL expertise :). I like token-based
> security because of the good performance and simplicity, but it
> appears to be not possible here (I can't think of an invariant
> that the HTTP server knows to guarantee the client isn't spoofing
> someone else's token :( ).

> PS If you can think of anything, and think this might be worth
> posting on MUD-DEV, feel free to reply there , but if so please
> replace my email address with "ceo at grexengine.com" since that has
> the spam filter on :).

Cookies based on the client's IP number are not going to work for
you 100%, not on HTTP nor HTTPS, because even HTTPS can be
redirected through a proxy and for major ISPs you may have several
proxy machines that are load balanced so one moment you may be using
one proxy ipnumber (which is what you'd base your cookie on) and the
next moment you could have a totally different one.

What you want to do is, and has worked well for Skotos, is to pick
some random number, and pass that on via a cookie along with the
hash of it, the username, and something that only the server knows.
The user cannot with the username and the random number along figure
out how to reproduce the hash (assuming you use a strong hash like
MD5 and keep your server secret really secret).

To be more specific for one of our projects, called a Chat Theatre:

Initial authentication for a Chat Theatre is based upon the existing
authentication scheme of the web hosting site. In order to allow
access to a Chat Theatre, the hosting site must create a session
cookie when site authentication occurs. This session cookie consists
of:

  - A lower case string of the username, stored as "user".

  - An authentication value created by returning the md5 value of
  the username and concatenating a special code generated by a
  Server Side Secret function, which serves as a session password.

On the RPGnet server, where the first Skotos Chat Theatres were
released, the following PHP code was used to create the session
cookie:

 // after succesful login is validated:

 $user_array = $db->getUserInfo($user_id);

 $user = $user_array[$f_user_info_user_name];
 setcookie("user",strtolower($user), "", "/",COOKIE_DOMAIN);

 $server_side_secret = getServerSideSecret();

 $pass = md5(strtolower($user) . strtolower($server_side_secret));
 setcookie("pass",$pass, "", "/",COOKIE_DOMAIN);

The Server Side Secret function can be different on any server
hosting Chat Theatres, with the caveat that the secret should be
updated at least once a day in order to preserve security on the
Chat Theatre. The following function was used for the Server Side
Secret on RPGnet:

 Function getServerSideSecret()
 {

     define(ToDay,86400,1);

     $day   = (int) substr(SEC_START,5,2);
     $month = (int) substr(SEC_START,8,2);
     $year  = (int) substr(SEC_START,0,4);

     $day_start = gmmktime(0,15,0,$month,$day,$year);
     $now = time();

     $temp = (string) ((($now - 15) - $day_start) / ToDay);

     $temp = substr($temp,0,strpos($temp,"."));
     $temp = (int) ($temp + SEC_DAY);
     $ret_val = SEC_BASE . $temp;

     return $ret_val;
 }

If a member arrives at a Chat Theatre without a session cookie set,
or with an outdated Server Side Secret, he will be redirected to the
appropriate pages on the hosting site to authenticate. Once a member
has been authenticated, and a current session cookie has been
created, he should be returned to the Chat Theatre.

If a member arrives at a Chat Theatre with a session cookie set he
will be given access to the Chat Theatre. Because of the algorithms
suggested for the Server Side Secret code, a user may be able to log
in to a Chat Thatre for up to a day after his account has been
terminated, provided that he has not ended his current browser
session. For certain games you may want to reduce the number of
hours.

-- Christopher Allen

------------------------------------------------------------------------
.. Christopher Allen <ChristopherA at skotos.net>       Skotos Tech Inc. ..
..                2342 Shattuck Ave Ste #512, Berkeley, CA 94704-1517 ..
.. www.skotos.net  www.rpg.net       o510/647-2760x202  f510/849-1717 ..
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev