Re: ASP authentication

[ido () cs uchicago edu (Ido Mordechai Rosen)]

Benoni (and list),
  I thought I'd make a response to this original message, since I only
  responded to a kind posting of my code so far.  My responses are
  inline, so please read on...

What you are looking for is called "single sign-on" in the web development
world.  There are many good sources for information on this.  A few are listed
at the end of this message.

On Thu, Aug 26, 2004 at 06:50:10PM +0100, B?noni MARTIN wrote:

> Hi List,
>
> I am wondering what was the most secure way to allow users to access
> pages after authentication, i.e.: user authenticates in toto.asp,
> and after that, access is granted to tata_1.asp, tata_2.asp, ...,
> tata_n.asp. The trouble is obviously to ask the user once for his
> login / password (just in tot.asp), and to allow him to get to the
> other pages without asking each time his credentials.
>
> Googling around, I saw a couple of ways to meet my needs, but all seem

This is a sign of independence: You searched around before posting to the
list.  I respect you for this.

> to be weak: - I can set a hidden field where I can say "yes, he is
> authenticated" or "no, he is not", but anyone a little bit skilled can
> create a fake request having this set up by hand (with a proxy ! ), -

Setting a hidden form field simply saying "yes, he's authenticated" would
be rather silly.  I agree.  You are looking for something that would fool
a slightly more intelligent intruder...

> I can check a session number or smth like that on each page...but this
> does not seem very reliable, - I can check IP adress...but when you
> use AOL for instance, IP adresses can change !

You used the word session above, but I don't think you were thinking
of what is generally meant by a session variable.  In any case, IP 
address checking is a Good Thing(tm), but not for authentication.  
You should make sure a user's IP address stays the same between
page views (if the user is logged in and has a session open), as a 
way to thwart session hijacking, which is described at this website:

(Since you're an ASP developer, this article will be particularly
relevant to your interests):

http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/default.aspx

This is a different, but related, issue to the one you are asking about.

But before you look at the link above detailing session hijacking, let
me explain briefly (for those on the list that don't already know) what
makes a session:

A web session is, by definition, a set of page views which are linked
in some way.  Ideally, sessions are connected page views ("hits") which
are connected by the fact that the same human being ("user") is viewing
that set of pages, with or without certain privileges/permissions.

PHP and ASP have template mechanisms for treating page views as sessions,
which usually involve setting a cookie on the user's browser which contains
a "session id" -- a random and hard-to-guess string indexing the session in
a filesystem or database of some sort.  The user's browser sends the cookie
data (session id) to the web server.  The web server checks in a database or 
(in the case of default PHP behavior) in a filesystem for a session with the
same session id.  If found, the web application running is granted access to
all of the data stored within that session (the session variables) relevant
to that session id.

Now, onto authentication using sessions...

Sessions are good because they are (a) hard to find since a user must correctly
guess a (long) session id, which is usually 16-40 characters long; (b) very good
at hiding data from the user's view and access, which would, in the case of GET
or POST (form) requests be visible to the user/user's browser, and editable; (c)
if done right, excellent at preventing sensitive data from unnecessarily 
crossing the wire, such as in the case of Basic HTTP Authentication, where the 
username and password pass over in plaintext with every page view; (d) possible
to be expired at the server side with no user intervention, such as after an 
hour...and there are other reasons.

Assuming a session is established as soon as a user first hits your website,
then session variables may be stored on the server side (in a database, for
example) and referenced by the session id freely.

In general, this is the solution that most sites employ to achieve secure 
authentication and access restriction:  A user hits a "login page", where he/she
types in his/her username and password.  The user hits "submit" on the login 
form, which is then sent to an HTTPS (SSL/TLS-secured web server).  The 
authentication server (HTTPS) sends back a redirection to the final destination
upon successful authentication (Location: http://... header), or sends the user
back to the login page displaying an error message if failure to authenticate.
In addition to this "redirection" upon successful authentication, the auth 
server also modifies the session variable "authenticated" (or similar) to "yes"
(from NULL/unset), or sets appropriate session variables to indicate that the
user by the name of "username" has logged in.  Now, whenever the user requests
any page from the web server, by sending the session id (stored in a cookie 
usually), the user is saying "I am the same person who did the previous 
action of authenticating myself.  Please let me in."  The server may choose
to act in a fashion of "I am convinced.  Enter." or "Your IP has changed, as
denoted by the userIP session variable which I set upon your authentication, 
please re-authenticate and I will let you through." or "Your authentication
was too long ago (over an hour ago, for example), please re-authenticate.", etc.

The user can never edit the "authenticated" session variable without proper 
authentication, and the server can decide the terms of authentication.

Does this make any sense to you?  It's about 5:30 AM here, and I haven't slept,
so I'm going to end this message while I am still able to spell my own name...:)

Ido

Though I despise ASP (I prefer Python or PHP or even Perl), here are a few
ASP-relevant sources of information on single sign-on using sessions.

This one is a tutorial intended to teach ASP, but it covers an "extended
member's area" which uses some single sign-on techniques.
http://www.theukwebdesigncompany.com/article.php?id=392

Oops, I closed my list of links...the above should suffice.  If needed, email
privately and I'll dig up some more tutorials/resources.