-1

I've been reading a lot abut this in the last month, and I've tried many different stuff, and I've heard many different opinions.

In the total ignorance in this subject, I've started building a custom session handler in PHP, running a validation script in every page, that was checking if the following conditions saved in $_SESSION were true (all them are hashed in MD5):

1) IP equal to the last used in the last page 2) Browser equal to the last used in the last page

And I had a custom session timeout, specified in the login, that was just allowing me to stay for example 5 minutes logged in. I was regenerating the id too, every page.

I've entered in a #php irc channel, and someone called me crazy for trying to replicate the php pre-defined functions to do all this, and said me just to setup the PHP variables (session.max_time, etc) to the limits, and it would be enough.

I've setup it, but it worked in some servers (localhost and webserv), others seem to be ignoring it.

A teacher of mine said me to use database session validation. One more time, people in irc called me crazy for wasting a lot of memory each time that the page was loaded by making just a connection to validate that stuff.

C'mon, I really don't know what is the right choice, what to follow.

Any advices?

Ivo Pereira
  • 3,410
  • 1
  • 19
  • 24
  • It just depends. However, from the first part of your question the quys from #irc are right: It already exists. If some servers ignore settings, you have the problem, that some servers ignore settings, and not, that you need to implement it yourself ;) – KingCrunch May 25 '12 at 12:43
  • MD5 is not encrypting it is hashing. Something totally different. Encrypting is reversible hashing is not. – Daan Timmer May 25 '12 at 12:57
  • Corrected Daan, thanks for the note. KingCrunch I agree, but I need make my application working at the majority of servers that I test, and it is really strange that it is not working. – Ivo Pereira May 25 '12 at 13:13

3 Answers3

1

Don't rely on the IP address being the same. That one's out of control for your users.

One reason to store sessions in the database is to support multiple web servers that all share the same database server (or cluster). This allows you to scale. It also saves you from worrying about PHP session settings, so a lot of third-party applications use this just to simplify support.

The default cookie-based (file-based on the server) session is fine in most cases. Ensure that you prevent session fixation with regenerate_session_id() immediately after authentication and use SSL to prevent other means of session hijacking.

If you need users to stay logged in, you use sessions normally, but you add another cookie that represents a token onto it.

I don't get what you mean when you say that your session is encrypted with MD5. Maybe you can explain further.

Marcus Adams
  • 53,009
  • 9
  • 91
  • 143
  • Hello Marcus, Don''t forget that someone can sniff a session id, and use another IP and pretend to be another user. What do you mean by another cookie with a token? Shouldn't be that saved into database or something? And if it is saved into db, wouldn't it be a lot slower? I was hashing them, sorry. Something like md5($last_visit_ip), and comparing them every page. – Ivo Pereira May 25 '12 at 13:16
  • @IvoPereira, No one will sniff your session if you are using SSL. The user isn't guaranteed to have the same IP address for each request. The route can be different for reach request, and only the cookie should be used for state, not the IP address. Yes, on the server side, the token will be stored in the database, and on the client, it will be stored in a cookie. I don't see how it would be slower since you would only use it if the session had expired. I still don't get why you're hashing the IP address. You could just compare it in plain text. – Marcus Adams May 25 '12 at 13:35
  • Good info about the benefits of DB sessions and avoiding session fixation/hijacking. – Ami May 25 '12 at 13:41
1

1) IP equal to the last used in the last page

This will fail for valid scenarios - e.g. access via load balanced proxies.

2) Browser equal to the last used in the last page

This will fail for valid scenarios - Google Chrome will update itself on the fly, even mid session.

I was regenerating the id too, every page.

This is going to cause prolems if the user opens more than one browser instance. You should change the session id if the user presents a sesison id which does not exist, or when you change authentication status. Not at other times.

You don't say what you are trying to achieve with all these shenanigans, so it's impossible to advise what the right solution is. And so far this is not about the session handler but how the session is managed.

A teacher of mine said me to use database session validation

Why? Presumably this is in preference to the default file based handlers but what shortcoings are you trying to address?

symcbean
  • 47,736
  • 6
  • 59
  • 94
0

I suggest that you implement session handling in the database, as it is the most server-settings-proof solution, while being relatively simple at the same time. You use php's session handling functions as you would, but you store them in a database instead of the disk. Google it a bit, but I would suggest reading http://www.devshed.com/c/a/PHP/Storing-PHP-Sessions-in-a-Database/

periklis
  • 10,102
  • 6
  • 60
  • 68