Then. a member file is created, and the member information is stored in it. The password is crypted first with the crypt() function. The member file has the same name as the login name ("members/$MemberID.mbr"). The folder is protected with a .htaccess file, not allowing anyone.

When you log-in with a valid user/pass combination, you receive two cookies. A. Your member-id B. Your password.

Although the password is crypted, it's identical to the string stored in the member file. Then means IF you can access a member file, you're able to fake a login success.

Is this problem significant, and how can I avoid it (making things more secure)?

A simple question says, why store the password in a cookie? Once the user has logged in, using their username and password, does it not follow that they are already validated once? If they are validated then the only thing you need in the cookie is their username and an expiration time. Also, I recommend you do not use the crypt function. Use the SHA-1 algorithm encryption you can get using the Digest::SHA1 perl module. It is much more secure than crypt and, to the best of my knowledge, cannot be decrypted at this point. To validate the id, store the SHA1 encrypted password in the .mbr file and then when user logs in, encrypt the password using SHA1. Compare the two strings to see if they are equal. If equal, validate the user, set the cookie and your off to the races!

Well, there is one problem with a CGI application. You propertly know it, but I tell it anyway to explaiin anything below this BLOCK of text.

Situation:a user requests GET script.cgi?show=login The webserver executes the cgi script, returns the html-page-result to the browser. The connection is closed by the webserver. b. user fills in the password in the recently received page, requesting POST script.cgi action=login user=(id) password=(password) The webserver executes the cgi script, print a html page telling you're logged in. The connection is closed again by the webserver., c. user enters a document, located at script.cgi?show=topic&page=1&topic=1 The browser connects to the webserver, the webserver executes the cgi script, returns the html page, and the connection is closed again. That's the case with CGI programs

Do you see the (little) problem here?

A HTTP connection is created everytime you request a page.

- How does the webserver know the one connecting is still the same guy?? - How Do I know it's you, logged in with user/pass? - Why should it believe the member is logged in when the browser only supplies the member-id cookie? Anyone can do that, and that means we doesn't have to login and validate via our system.

Anyway, if you login as administrator, the cgi script validates your login/password at every request, so it really knows it is still the admin.

That why I am using cookies

If you have a alternative, I would be very happy. I don't want to see the password in the address bar, so I use a cookie. What kind of approch you choose, the browser has to supply 'something' at every time it connects to the browser.

cryptWhat's on with the crypt() function? I though you couldn't decrypt it (perldoc said so). You really need to run a program testing all possible combinations of a password + crypting-key, then testing whether the result is the same as stored in the .mbr file.

You recommend the Digest::SHA1 module. Can I simply put it in a folder (at my webserver), and point to that folder with a use lib 'foldername' code?? I can't install the modele at the webserver off course.

Yes, I understand CGI. I have been using it for a long time and I am only suggesting that if you do not need to store the password in the cookie, then don't.

Here is how I normally do things:

Does the user have the cookie? If yes, Validate user name is valid username on server If yes, process request (because username in cookie is is valid user name on server) Else Deny Access Else Is this a login? If Yes, validate username and password If Valid User display initial options Else Deny Access Else Print Login Screen

This way, the cookie never exposes the password to the real world at any time. It also is only one way of doing the processing you are trying to accomplish. There are other ways. I was only suggesting.

In regard to the crypt being unbreakable, I have heard that it is supposed to be unbreakable. But not to trust in that. You may use it as you see fit.

As for using Digest::SHA1, it was part of the standard Perl Load from active state. If you can look at your server harddrives, you could see if it is installed or ask your Host if it is installed with perl. Most hosts don't seem to complain if you can show why it makes sense to add it.