Can a user diy a cookies? 1

[secondleft]

Hi,

To validate a user, we can do something like:
In login page, check the inputed username and password by database, if pass, set
response.cookies("username") = username.
In any other page, check if
request.cookies("username") <> ""

1. Do you think that way safe? Can a user just diy a cookies to let
request.cookies("username") <> ""
2. If the diy is easy, what we can do to make the user validation safer (without using session)?

Thank you in advance.

 

[onpnt]

cookies shouldn't be used for something as crucial as login information. I have a hard time even using cookies period just for simple layouts and personal preferences because they are so volital. Basically you are weighing your applicaitons functionality far too much on something that may or may not work given the environment in front of you.

user vbalidation can be much easier and more have more stability with a simple mdb (ms access db) if you are looking for quick easy no overhead solutions to a user validation method


General FAQ faq333-2924
5 steps to asking a question faq333-3811

 

[Sheco]

Absolutely a user can make their own cookies.

Sessions are just cookies. Session cookies expire when you close the browser.

A session would be more secure because, from the perspective of the user's computer, it holds a meaningless value. The browser automagically sends this value to the server along with every HTTP request. From the server's perspective, the value is not meaningless because each user sends a unique value. The server matches up the value with a collection of "session variables" for that specific user.

So, if you use cookies at all, there is no good reason not to make them session cookies... except perhaps to squeeze every last drop of performance out of your web server.

 

[secondleft]

onpnt,

Thank you for your quick response.
Tha reason why I don't check username/password by access in every page is that I don't want touch access mdb too often. It may cause problem if too many users touch mdb at the same time...

 

[secondleft]

Sheco,

If use session, I want the expire time is very long + I have a few hundreds visitors per day, do you think the server will suffer?

 

[Sheco]

The expiration time is the amount of time that is allowed to elapse between HTTP requests before the server decides that the user must not be coming back. So if a user clicks a new link every 5 minutes or less, the expire time could be 6 minutes and the user would never hit the time-out.

On the other hand, if your site contains any single page forms that may take the user 30 minutes to complete then you'll definately need a longer time-out than 20 minutes or else you'll have some very angry users that just spent half an hour working on something only to have it rejected by the server... so it depends on the usage profile of your web application. A site that has less 1000 hits per day shouldn't be a problem at all unless perhaps they all hit at the exactly same time and your server is running on 128mb of RAM.

Your server's memory needs to be large enough to hold all of the sessions initiated with 2x the timout period. So the default of 20 minutes needs to be able to hold 40 minutes of peak trafic.

This shouldn't be a problem for you since you are only talking about saving a small amount of plain text in the sessions... It might be a problem if you stored object variables like an ADO Recordset or dictionary objects... but the username is plain text so that is small from a memory usage standpoint.

 

[secondleft]

Sheco,

Thanks a lot for your explanation.

I didn't mention, the server is not my computer, I just rent some space in a company's server. Perhaps many sites in that server and the visitors number = (my visitor) * (the sites in the server)?
And 20 monutes expire time is not enough for my site.....

 

[Sheco]

Before go about the effort of recoding your log-in routine, perhaps a simple stress test.

Put something like this on your main page:
<% Session("Time") = Now %>

This will give each user a session variable that is updated each visit to the main page... The variable will hold the time of day from the server.

You could do this and see if there is any impact on performance.


... or are you saying that your hosting company does not allow sessions?

 

[secondleft]

Sheco,

That is a good idea......I will try that test.

One thing more: I have just tried to delete cookies in Internet Options in my IE during visiting my site (use cookies in each page) but I can still visite all pages!! Where is the cookies for my site? In memory??

 

[Sheco]

How a browser stores its cookies is its business, it doesn't matter from the server's perspective. Your session cookie is probably in memory.

 

[secondleft]

Sheco,

If the cookie is in memory, no user can make a cookie!?

 

[Sheco]

From the server's point of view, the cookie is merely some additional text in the HTTP Request. It doesn't know anything about the how or where the browser saves the cookie.

You don't even need a browser to talk to a web server, you could fake it and the server wouldnt be any the wiser... like FireFox pretending to be Internet Explorer.

You could, for example, use Telnet to connect to port 80 on the web server. You could then just type in an HTTP Request... type it right into the terminal window with your fingers. If you included cookie data, the server would never know that you just pulled the values out of thin air, you could do the same thing with form values.

Now granted, most users are not going to do this, but the orignal problem is from most users... its from a few hacker-type users and they absolutely will spoof HTTP requests.

If a hacker is trying to spoof a session, it is highly unlikely that they would be able to guess the unique ID of a currently valid session... its not impossible, but a session hijack would be much more likly to proceed through a sniffer interception of the browser-server HTTP data stream than via a brute-force guessing attack on the session ID.

On the other hand if you use a cookie to hold the userID and that user ID is the value transmitted between client and server then it becomes much easier to exploit... all the hacker needs to know is the username.

 

[secondleft]

Thanks a lot again for your explanation!