how secure are cookies?

[james438]

How secure are cookies as a way to stay logged in? I use them, but it seems to me that it is probably very easy to write a program that will alter cookies 1000 times a second till the hacker is recognized as logged in.

[BLiZZaRD]

Using PHP Sessions is probably better. Harder to fake them and all that.

[james438]

How do you get around the problem of staying logged in with Sessions?

[traq]

generally speaking, sessions are gone after the visitor closes their browser. the server usually keeps session info around longer; this means that even though the browser has decided the session is gone, the server can still be tricked into thinking it's valid (if someone has stolen the session id, for example).

I don't know what the default session life is, but you can change it to whatever you please:
you can change the max lifetime for a session with the function ini_set().

<?php
ini_set("session.gc_maxlifetime", "18000");
?>
This will set the max lifetime of the script to 5 hours. You have to use this in every script that you want to change the default lifetime for.

if you want to know the lifetime of your current script, you can use:

<?php
echo ini_get("session.gc_maxlifetime");
?>

[james438]

Thanks for that. I'll try it out.

It is a bit hard to steal session ids, because they are processed server side. I can no more steal someone's session than I can their php code.

[djr33]

Cookies are not secure. They are stored on the user's computer.

Sessions are also not secure in the sense that they are linked to a session id cookie.

So if you are worried about a brute force attack, then there's not much you can do either way.

Cookies are not in any way secure. Sessions are completely secure except when someone has the session id cookie. Also, the session DATA is ALWAYS secure, regardless of having the session id cookie-- the user gains access to being "logged in" for the session, but they do not gain direct access to the session data. In other words, session data is secure unless you output it to the user. You can theoretically store your mysql password in the session data and it will never be a security risk as long as you never echo $_SESSION['mysqlpw']. I'm not suggesting it, but there's no technical reason that's not secure. Your PHP script is the only way to access session data.

But that session id cookie will authenticate a computer as the correct computer, so that they can get whatever access your PHP script then allows to the session data.


Generally speaking, sessions are very secure and nothing to worry about.

One way to get around session concerns is to link the ID or security check to the IP address. I've done this and it works well and it is (I think) completely unhackable: you attach the IP address to the md5() check for password, or something along those lines, and there is no way that someone can hack around it by stealing the session id, etc.

[traq]

A session's vulnerability -like many things- is in transit. If you're not using SSL, someone could "listen in" and grab the session ID. If you're allowing sessions to use GET, using the session id is very easy. You can set sessions to use cookies only, which is safest.

As djr says, the actual data is as secure as you make it - but a malicious user could do whatever the legitimate user was allowed to do (such as deleting messages, changing their password, etc.).

Read more here (http://us.php.net/manual/en/session.security.php), and the beginning of this paper (http://www.acros.si/papers/session_fixation.pdf) gives a good intro to session security issues.

[fileserverdirect]

One way to get around session concerns is to link the ID or security check to the IP address. I've done this and it works well and it is (I think) completely unhackable: you attach the IP address to the md5() check for password, or something along those lines, and there is no way that someone can hack around it by stealing the session id, etc.
This only works for static IP's where as more then 70% of the world is on dynamic IP's so this would almost never work.

[james438]

What constitutes a dynamic IP address? I'll look this info up as well. djr33's idea sounds really good though.

[djr33]

This only works for static IP's where as more then 70% of the world is on dynamic IP's so this would almost never work.That shouldn't be a problem. Of course the login will shift if the user's IP changes, but dynamic IPs don't change often enough that it's a risk to make the IP remain the same. If the IP changes every couple days, then the user has to re-login after a couple days. That's all.

Of course things can get messy if you are moving around a bit, such as with a laptop jumping from hotspot to hotspot, but while you are within a session, that should be fine. If you close the computer to move to another wifi hotspot, that's another session, really.

One problem might be with mobile devices because I don't know how IPs are distributed to, for example, 3G phones. That's something to consider.


However, no single session will be interrupted by a problematic number of "dynamic" IP changes.

Be sure that you don't require that the SAME IP ALWAYS be used, but instead, that within a SINGLE session, the same IP is used and if it changes that they have to reauthenticate.


Note: I used this system on a reasonably well used site and I never got complaints from users. It does mean that every time you go to the website (like each day) you may have to login again, but that is usually the case with sessions and sometimes with cookies. It's not a way to "keep me logged in forever" as some forums allow, but it is secure and will prevent session hacking.


Here's some basic code:

session_start();
$_SESSION['verify'] = md5($_SERVER['REMOTE_ADDR']); //Use this line UPON LOGIN ONLY
if ($_SESSION['verify']!=$_SERVER['REMOTE_ADDR']) { session_destroy(); ////etc

In the past when I did this I linked it to the password so it was something like md5($pw.$ip), but now that I think about it, that really isn't required, since you can store the IP directly into the $_SESSION array securely. You can also verify this against a database.
A more creative approach would be to generate a session ID that is based on the IP address and user's info like password or username, but I'm not exactly sure how that would work.

[james438]

That was a really good idea djr33. I am using your suggestion and have stopped using cookies as a way to detect whether a person is logged in or not.

What do you do about shared networks where multiple computers use the same ipaddress?

[james438]

I am now using cookies in addition to djr33's suggestion. I feel this is the most secure. Here is how it works:

When a user (admin) logs in for the first time there is a password form that needs to be filled out. Upon entering the correct password a 10 year cookie is created and an entry is stored in the database of the ip address of the user that entered the correct password. Only one ip address in the database is allowed to avoid being logged in as the same person at more than one computer.

If the admin then closes the browser and opens it again the php will match the $_SERVER['REMOTE_ADDR']; against the entry in the database. If there is a match then a session is created. The cookie is used as a safeguard against others on a different computer, but using the same ip address.

Just to be clear, if a person moves or decides to log in as admin at a neighbor's computer as admin then that ip address will replace the current entry in the database for the ip address thus causing the admin to need to re-login when he goes back home to login.

If a person logs out the cookie is destroyed and the databse entry for the ip address is erased.

If the password is altered then the other person with the same ip address and valid cookie suddenly has a valid ip address and an invalid cookie and is thus logged out.

[djr33]

It's possible to approach it that way though generally it's better to use sessions with the IP method, since that will be smoother.

As for shared networks, I've never really thought/cared about it. If you are having your account stolen by someone sharing your internet connection, you've got bigger problems than what the website does for security.

Plus, there's no real way to do it that will be secured if a cookie is stolen and it is used on the same network. One possibility is to then use other identifying information such as the browser/OS type, etc., though that can get messy and probably won't quantitatively help that much.

[james438]

I highly doubt any of my account info has been stolen, but I suppose you can never tell for sure ;). The reason I am looking into it is that I live near a college and use their free internet access (yes, it is legal) and it appears that a few of the ip addresses are the same; my ps3, which uses wifi and my personal PC. I did not set up the wifi, so I do not know how the PS3 has the same ip address.

Anyway, that is why I am using your method plus another identifying feature such as a cookie. I like your idea about using something else such as screen resolution, OS type, or browser version as very few people would have that combination or use Opera like I do.

EDIT: I also added cookies again as it required editing only 2 pages: the login page and the database include().

EDIT: Now that I think about it Sessions are not really needed or in any way used; just the user's ip address and cookie. If you log in as admin then the ip address stored in the database is updated. If I forget the password or through poor coding create a junk password and lock myself out I can always use my ftp account to fix things or alter the data directly via phpmyadmin.

[n1tr0b]

hey guys.. in sessions putting other variables in sessions will make the session even harder to crack right.. example in a session class



echo $ex->session["s_{$ex->session['s_id']}_user"];


am i correct??

[traq]

hey guys.. in sessions putting other variables in sessions will make the session even harder to crack right.. example in a session class



echo $ex->session["s_{$ex->session['s_id']}_user"];


am i correct??

Looking at the bit of code you posted, I have no real idea what it is you're doing (I'd need to know what the class looks like/does).

After reading your post, I'm not sure what, exactly, you're trying to do, or what you're trying to ask.
(What "other variables"? And why would anything you store inside a session make the session harder to "crack"?)
Maybe you can explain a bit?

[djr33]

No. It's not harder to crack. Sessions are just like other variables: they are data stored on the server. Additionally, if you have a session class, it won't be available from one page load to another.
My advice is that you stop trying to out think the system and instead learn to work with/within it.

There are possible security issues, but using awkward ways like this won't fix them. If you want real security, read a book about security issues, do what you can (such as using IP verification, but make sure it's the smartest way), then use https and other outside methods that secure it.