Sign in to follow this  
AdamGL

[web] Php sessions and Cookies

Recommended Posts

Hey People! I was wondering if sessions are a good idea to use on a site where someone needs to login to a site and stay logged in to view it.I heard that session ids could be stolen easily. I'm thinking of making 2 cookies for the site. One for username, and one for password, both being md5'ed. Each time a user accesses a page, it will draw the information from the cookies. Is this ok? I don't care for "Cookies need to be enabled".

Share this post


Link to post
Share on other sites
That won't provide any real security. You're falling into "it's encrypted, so it must be safe" school of thought.

First, the 2 cookie thing may simply be a terminology issue, but if you are actually planning on sending 2 cookies (different domains), it won't accomplish anything other then making your code hugely complicated.

Second, storing the MD5 hash of the users name or password, in their cookie, is not real security.

You need to drop the idea that encyption=security and begin thinking in terms of what does the "hacker" want to achieve, and what is the shortest path to that goal.

For starters lets assume that you have the username, and an MD5 hash of the users password stored on your server (this *is* a good security step, as it reduces the damage done if data is stolen). We'll also forget about the username part - that isn't a secret so lets assume we are already at the stage where we are verifying the password for the automatic login.

If we store the password as plaintext in the cookie, the code looks like this:

if (MD5(CookiePassword) == StoredMD5Password) Login


If we store the password as MD5 in the cookie, the code looks like this:

if (CookiePassword == StoredMD5Password) Login


Notice how similar those are? The fact that you've MD5 "encrypted" the password in the cookie means nothing - since you have now provided a way for users to login using an MD5 signature instead of a real password, the hacker does not need to decrypt the MD5 hash. They just submit the MD5 hash as their cookie and they are logged in. In this way you've made your system less secure, since you've now managed to counteract the MD5 hash used in the database. If someone was able to get access to your database (steal the file, find an SQL injection vulnerability to read records) he would no longer have to deal with the hash protection, because your site provides a way for him to use an MD5 signature in exactly the same way he uses a password.

The proper way to store the password data in the cookie so that it is not immediately usable if the cookie is stolen, is by using two way encryption and a form of client identity verification.

First, we need a two way encryption system (can encrypt and decrypt data, unlike a hash which only goes one way). The encryption key is stored on the server. Second, we need some piece of data that makes the client slightly different from other clients. An example would be the first 3 parts of their IP address (x.x.x.*), though you could also less reliable things like the users browser agent string.

When a user logs in and checks the "keep me logged in" option, we take the plaintext password, along with the unique identifier, and encrypt them with our secret key. The encrypted data is saved in the cookie. When it comes time to automatically login a user based on their cookie, we decrypt the data. That gives us a plaintext password, which we apply the MD5 hash to *on the server side* (meaning the hacker can never submit a hash in place of a password). We also check to see if the identifier stored in the encrypted cookie matches the identifier the client has now. If they don't match, they we suspect that the users cookie has been stolen and placed on a different computer, and ask the user to reenter their password.


On the overall subject of cookies and sessions - sessions can be "stolen", but it is *harder* to steal a session then it is to steal a cookie (proper sessions are server side data linked to by an ID stored in a very short term cookie - if you can steal a session, you can already steal cookies). Cookies can be stolen by local programs, by exploiting cross-domain vulnerabilities (FireFox and IE have had many of these), or by exploiting holes in your site to spoof the correct domain permissions. Session stealing requires a far more realtime approach, normally a man in the middle attack (such as if you are on a university network, and someone can read all network traffic between you and the remote server). If someone can run a man in the middle attack, he can steal the password without even needing a session - he can just copy it when the user sends it.

The exception to this is if you use use PHPs URL session identifier (index.php?PHPSESSIONID=.....). These are horrible from a security point of view - stealing them is as easy as posting a link to your site. The user clicks the link, and the hackers site records their session id as part of the referer value passed by the users browser. It's then simply a matter of sending that session id to your site before the session expires.

Share this post


Link to post
Share on other sites
Never store the password on the client's computer, even if it's an MD5 hash of the password. There is no difference between storing the MD5 hash and the cleartext because if your site simply checks if the hash on the client is correct then the hash IS the cleartext.

Instead, when the user logs in generate a token representing their session. This should be more or less random but should probably be tied in some way to the user's client. That means that if the session token was stolen then the attacker would not be able to gain access to the user's account because they are using a different client, or IP block, or whathaveyou than the original user and so the token would not be valid for them.

More information about sessions and security

Share this post


Link to post
Share on other sites
Ok. I see what you mean. What kind of encryption key would I use, and how can I find the ip address of the user? Could you give me a basic pseudo-code example of how I would create this session and validate it?

Share this post


Link to post
Share on other sites
Here is how I do it..

http://muer.njoerdba.com/paste/view.aspx?id=b5df51be-f1c7-4110-9ead-0c0b3a9accfe

I have 2 sections of code here. One is for when users log in, one is just for basic .php pages. I'm actually curious how well its written... I know it would be possible to steal a users cookie and log in while his session is still active (and I guess I could improve upon this code by linking a session ID to an IP address), but whats the probability of that versus useing a key-stroke logging trojan to gain access? Either way, for most applications (ie, non-banking), I think its good enough.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this