Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: ASP authentication

Subject: Re: ASP authentication
Date: Fri, 27 Aug 2004 16:55:48 -0400
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 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 ! ),
- 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 !

So none of the ways I found seem to be the best... Cheers list, for any reply / clue !

The is a classic issue that every developer faces. One of the better ways to handle this is the following:


1. Use SSL to encrypt the traffic to begin with.

2. Your login page sets 3 cookies (or hidden form fields)
- One is a session id
- One is the time stamp (or epoch seconds) of this page view
- One is a hash (i.e. MD5) of the session ID, time stamp and their password using some random salt.


   - On the back end, keep track of who belongs to each session id.


3. On each successive page, you get these 3 values back and reset them (so the time stamp and hash keep being updated).


4. To determine if the person is authenticated, use the session id to look up their password in your back end. Use that and the passed time stamp to make a hash comparable to the one passed back to you.

   - If the hashes match, then the credentials have not been tampered with
   - If too much time has elapsed, you may want to automatically log
     them off to mitigate the effect of replay attacks.

Even this mechanism has problems with replay attacks
- The credentials can be sniffed if you do not use SSL or if there is an
SSL proxy in the middle you are ignoring.
- The credentials can be obtained by anyone with access to the user's computer.



--

Erik Kangas, Ph.D. --- President of Lux Scientiae, Incorporated

Lux Scientiae:       1-800-441-6612        P.O. Box 326
FAX:                 1-413-332-0598        Westwood, Massachusetts
Cell:                1-617-596-9558        02090, USA
AIM Chat:            Screen Name "luxsci"

kangas@luxsci.com  ---  http://luxsci.com

<Prev in Thread] Current Thread [Next in Thread>