After user log in, we could use session or cookie to remember the encrypted password and userid. We will match it every time a page loaded with the userid/password in the databaes to see if they are authorized to get in.
session is on the server, cookie is on the clients browser. It seems session is safer or at least as safe as cookie. But with the session fixation attacks, is session still safer than cookie?
Shoud we use session or cookie to authorize the user? What should we do?
Thanks!
searain wrote:After user log in, we could use session or cookie to remember the encrypted password and userid. We will match it every time a page loaded with the userid/password in the databaes to see if they are authorized to get in.
session is on the server, cookie is on the clients browser. It seems session is safer or at least as safe as cookie. But with the session fixation attacks, is session still safer than cookie?
Shoud we use session or cookie to authorize the user? What should we do?
Thanks!
Hello searain,
A lot of people would argue with me about this, but I feel that cookies are more secure then sessions as long as their handled correctly. This is because cookies can be encrypted using mcrypt or a strong encryption class such as RC4 making them nearly impossible to crack. Sessions on the other hand can be hijacked more easily. There is practically no way to completely prevent session hijacking. For example, a hacker can spoof an IP address to get around security checks that a session handler might use.
But if your new to php you might find that people can be fairly opinionated about the cookies vs. sessions subject.
That's my 2 cents 
I might also add that sessions cant be assumed to be safe unless cookies are used for passing the session id, which makes sessions subject to the same risks that you find with cookies
Due to there is session fixation attacks, will it be safe if I
use cookie (the life time of this cookie is until the session ends, so it is like a session but without worry of session fixation attacks?) to save the userid, useremail, userpassword (all of them encrypted), and on every page loaded, i will check these three values against the database values.
not check once, good for all the time of the session lives. I will check when every page in the secured area loaded, use the cookie value against the database.
Will that be safer?
Thanks!
Yes, and no... I have to first say that I don't know that much about session fixation attacks, but from what I have read it is possible with any means of session keeping that uses session id's passed to and from the user/server, regardless of type, be it cookies, php sessions, or custom sessions. But cookies when used alone don't use id's of any sort, because the server doesn't have to keep track of the cookies owner. they are stored and passed by the browser, rather then stored locally on the server, and not tracked via an id number. But if the cookie is used to store a session id, then it is possible as long as the hacker has means of injecting the users cookie, or physical access to his computer to edit the cookie manually.
But with that said, I think I might explain session fixation some. First of all, the means of storing sessions, or rather session IDs are used, is not where the threat of session fixation comes. session fixation is only a threat if the application does not properly destroy sessions when a user logs off. Let me explain:
Say I (the hacker) log into a web application and is given the session ID of 12345678910. If I pass this session id to you, you will end up using the session that has been assigned to this ID. This is not a risk to you unless the application allowed me to logoff and still kept the session alive. If it did, and you then log into your account, AND you are not assigned a new session, then I (the hacker) will now know the session id to the session with your credentials.
For this scenario to work in real life, the application (or the developer of the app I should say) would have to make two mistakes. first, this is only a risk if the said app does not destroy sessions when a user logs out of the system. Second, the app would also have to not be made to insure new sessions are made each time some one logs on.
In other words, this app would have to first create a session for that hacker, saving his data to it.. then when the hacker logs off, delete his credentials from it but still keep the session alive.. Then when you access it, save your data to it when you log on (instead of a new session), letting the hacker hijack it by using the known session id. These are very obvious mistakes, but I guess it is possible for some one to make them if they wish to keep certain settings active once a user logs out, such as theme settings or other user prefs.
Long story short, this is not the fault of the session, it is the fault of the application. As long as your app destroys sessions at logoff, and insures new sessions are made at logon, this is not a risk. If a hacker sends someone a link with a session ID, the session will either be for his account, a dummy account, or it will be dead. If you are taken to his account or a dummy account, you would have to log off (destroying the passed session) in order to log into your own account.
As long as your app destroys sessions at logoff, and insures new sessions are made at logon, this is not a risk.
This makes the assumption that the user logs off. Users often dont log off, e.g. they may close their browser window or perhaps they managed to crash their computer.
A solution is to use cookies to pass session ids (e.g. enable session.use_only_cookies), but this tends to be aimed at stopping session hijacking and trivial session fixation rather than stopping session fixation as a class of attacks.
Since it may be possible to trick users into accepting a maliciously constructed cookie, some form of session fixation can occur whether one chooses to use sessions or cookies. One way to avoid this would be to ensure that only one user can use an account at a given time. This can be done by issuing a new identifier (be it session or cookie) at every page access.
Also, the process you described above is good. But don't encrypt them together, as this can make them easier to crack. First encrypt them, then join them in a string and save it to a cookie. then you can explode the string, and then decrypt the id and pass. I say this because if you encrypt them together all that a cracker would have to look for is the format of the original data. for example, if you used a | for an explode point, and joined them such as
$cookie = $uid."|".$pass;a cracker would only have to look for a string with the format of numbers|numbersandleters to crack the cookie.
laserlight wrote:One way to avoid this would be to ensure that only one user can use an account at a given time. This can be done by issuing a new identifier (be it session or cookie) at every page access.
if it is a session, you mean
session_regenerate_id();
every page access?