in reply to Re: Cookie not being set
in thread Cookie not being set

do not store usernames and passwords in a cookie, this is a security hole
Could you explain why or point me to a node to look at?
You might want to setup a sessionid for that user and reference (and expire) that id
How would be a good way to go about doing this.

Thanks
Joshua

Replies are listed 'Best First'.
Re: (joshua) 2Re: Cookie not being set
by grep (Monsignor) on Jun 24, 2002 at 04:56 UTC
    Here is one node and another that hits closer to home. Other than that I imagine you can search.

    As for you session question - if you are using Apache, Apache::Session IIRC will handle it all for you. If not - a simple setup would be session table in your DB with username, timestamp, and session id. Then check for that sessionid (passed either as a param or cookie) and see if it expired



    grep
    Just me, the boy and these two monks, no questions asked.
Re: (joshua) 2Re: Cookie not being set
by Ovid (Cardinal) on Jun 24, 2002 at 05:22 UTC

    There are several reasons why this is a security hole.

    • Assuming this is not sent over SSL, someone could sniff the traffic and, since this is sent in plaintext, they can see your user's passwords.
    • This is usually stored on the user's computer, so someone else with physical access to their machine can get this data.
    • Cross-site scripting attacks can often read cookie data and send it somewhere else, thus allowing yet another way to compromise the user's data.

    Never fear, these things become second-nature after you work with the Web for a while :)

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

      I don't want to turn this node into a discussion on web security but...

      Here's my setup:

      • Password is stored encrypted using the crypt function w/ a random key in a file on the server outside of the public-viewing.
      • User enters pass in a form.
      • Password is sent to the server in plaintext (not good)
      • Server encrypts the user's entered password and makes sure it matches the one in the file
      • Server sends cookie to browser that contains encrypted password
      • Each time the user wants to go to a different part of the admin, the server checks the password in the cookie to make sure it's correct.
      I know this doesn't sound very secure, so I'll look into some of the other methods discussed.
      Never fear, these things become second-nature after you work with the Web for a while :)
      I'm kind of seeing that...I've come far since I started doing CGI, but I know I have a lot more to learn.

      Joshua