CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
Search Posts SEARCH
Who's Online WHO'S
Log in LOG

Home: General Discussions: Internet Security:
Member Password Access



Nov 4, 2001, 8:01 AM

Post #1 of 5 (56452 views)
Member Password Access Can't Post

At my forum, you can sign-up (duh!).

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)?


Nov 5, 2001, 4:39 AM

Post #2 of 5 (56448 views)
Re: Member Password Access [In reply to] Can't Post

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!



$a="c323745335d3221214b364d545a362532582521254c3640504c37292f493759214b3635554c3040606a0",print unpack"u*",pack "h*",$a,"\n\n"


Nov 6, 2001, 10:16 AM

Post #3 of 5 (56445 views)
Re: Member Password Access [In reply to] Can't Post

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.

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.

What'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.


Yet an Other Perl Programmer

Find out more about programming


Nov 7, 2001, 6:48 AM

Post #4 of 5 (56442 views)
Re: Member Password Access [In reply to] Can't Post

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)
Deny Access
Is this a login?
If Yes,
validate username and password
If Valid User
display initial options
Deny Access
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.

Good Luck with your project,


$a="c323745335d3221214b364d545a362532582521254c3640504c37292f493759214b3635554c3040606a0",print unpack"u*",pack "h*",$a,"\n\n"


Nov 8, 2001, 1:58 AM

Post #5 of 5 (56439 views)
Re: Member Password Access [In reply to] Can't Post

Thanks a lot.

Still I don't get the reason why I shouldn't store the password, or a double-crypted password. Anyone can install a cookie, containing the username, right?

I just typed in javascript:alert(document.cookie) in my browser.
It returned:

Username=yapp; Password=(something crypted); language=english; Stylesheet=stylesheet

Without the password cookie, I shouldn't be allowed to do anything in this forum.

Yet an Other Perl Programmer

Find out more about programming


Search for (options) Powered by Gossamer Forum v.1.2.0

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives