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?

Yes, that's better, but it does guarantee that some users will not be able to use your site. The user might be sitting behind a proxy that uses a different IP address with every request. AOL users, for example, have a different IP address almost every time they connect. Thus, if anyone connects to your site using an IP address that someone else has used, they'll gain access to the other person's session.

You want to use some form of random session ID that times out. One caveat, though: do not use sequential IDs. If someone connects and has a session ID of "307920" and the previous person had "307919", then someone can easily change their cookie value to hijack someone else's session. Random session IDs that time out in a relatively short period of time stand the best chance of avoiding a session hijacking issue.

Also, I should mention that you want the session start time to be stored on the server and not relying on the "-expires" key in your cookie. You maintain control over the session timeout yourself and you don't have to worry about someone changing their clock on their computer (or worse, having a non-standards compliant browser ignoring the timeout value for the cookie).

Cheers,
Ovid

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

Not really. That won't work for multiple proxy setups such as AOL, and it will break if you've got two users behind the same NAT gateway. I would reccomend using some sort of session tracking system instead. Check out CGI::Session.

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.