Your syntax is fine. I like lower case names, but perhaps that's just a matter of preference. I don't understand why you're trying to print the same cookie, twice, but it shouldn't have any effect. Here's what I used to test your code.

#!/usr/bin/perl -w
use strict;
use CGI qw/:standard/;

my $cookie = cookie(
    -NAME    => "Matrix",
    -VALUE   => "no password",
    -EXPIRES => "+2y"
);

print header(-COOKIE => $cookie, -COOKIE => $cookie);
[download]

That works just fine, even though it looks a bit strange.

Why are you storing the username and password in the cookie? Not only can someone sniff this traffic, it's vulnerable to cross-site scripting attacks and will be stored on the users computer for up to 2 years! This is a massive security hole. Even if you think that there's nothing too sensitive on your site, people tend to reuse their usernames and passwords when they can (even if you assign them, they might use them somewhere else). Thus, if an attacker gains this knowledge, you can potentially give them access too far more than just your site. Please do not use this code.

Check out my CGI course for more information about CGI security.

Cheers,
Ovid

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

Are you sure that's how you are supposed to send the cookie? and what exactly do you mean by "its not showing up on my computer, but it says it exists on my site" ?

drop off the CAPS.. parameters and in small-case, and when sending multiple cookies I think it's done like header(-cookie=>[$cookie1, $cookie2])

that looks about right. how did you decide that it's not showing up on your computer? is it in your cookies.txt file? are you sure you're looking at the same cookies.txt that your browser is using?

anders pearson

Well, first of all, they have a user name, so that's an advantage they don't need. Further, if they can research the user using the user name, they can now use the username to start guessing reasonable passwords.

As an aside, I once discovered that someone was doing something online that was violating the terms of service on a Web site. They had a very unusual username and it took me all of two minutes to track them down using http://www.google.com. If I was more inclined to be a bad person, this could have been the start of something ugly (I wound up finding code samples they had written and Web sites that were using them). Instead, I sent them an email asking them to stop what they were doing and they did, replying that it was a "mistake". User names shouldn't be given out freely unless the person who has the user name knows it's being given out (such as on Perlmonks).

As for the "crypted" password, if you're using the crypt function, the then salt is embedded in the first two characters and the cracker runs a standard "crack" utility on the password (again made simpler because having the username may make it easier it determine what sort of password might be used -- you merely feed the new information into the wordlist the crack utility uses). Even if the password is "encrypted", or a digest is used, it's still possible to attack the password and try to crack it. There's no point in allowing the possibility of this happening if you can avoid it.

If the attacker has managed to get a cookie without physical access to the person's box, then this suggests that they may using any of a number of techniques that could allow them to obtain more than one crypted password. If so, it only takes one weak password to start a cascading chain of vulnerabilities being exposed.

Question: just out of curiosity, what would happen if I sniffed someone's cookie and I were to submit it myself? Would I then have access to the system? Once again, there's a potential security hole open there. I'd personally recommend using a timed anonymous session id as the cookie's value, rather than something which is potentially a vulnerability.

For more information, you can read merlyn's column on basic cookie management. I think you will find it very informative.

Cheers,
Ovid

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

I got an idea, when the person logins, ill write there cookie, and store there I.P in a database, and then ill use the I.P to see were the cookie is coming from? ehh better?

It would be rather susceptible to a brute force attack. Imagine that someone sniffs your network traffic pulling out username/password combinations and storing them on a separate machine. That machine then whiles it time away doing a dictionary attack attempting various strings and various salts to generate the same signature of the crypt'd password. (The implementation of this could be made very efficient: it could be a hashtable of crypted password => username, then for each candidate password/salt generated by the cracking programming all that would be required is a key lookup to retrieve the username). You (the webmaster) wouldn't have any idea it was doing it, since it wouldn't be taking up your network resources trying different passwords against your website, and given a decently large sample of passwords, they'd probably find a weak one with ease.