Jump to content


Session Security

  • Please log in to reply
21 replies to this topic

#21 Psycho


    Advanced Member

  • Gurus
  • 10,709 posts
  • LocationCanada

Posted 28 April 2014 - 10:32 AM

I think this thread has come off the rails a bit. Let me clarify a few things.


Determining if a user is an 'admin' or not and storing that information in the session is perfectly acceptable. The whole point of session data is to store information that you will use throughout the session. The only potential problem with this is if you will need to immediately know if their admin status has changed during the session. That is a business decision. If the answer is absolutely yes, then you would have to do an admin check on each login. If the answer is 'sometimes' based on what the user is doing, thenyou could add a DB check for the specific functions where you need to reverify their admin status. Otherwise, you can use the data in the session to check their admin status.


The discussion about using SSL is irrelevant to the discussion about using session data or not. If you are not using SSL, then ALL traffic between the client and host is in clear text - this includes the user's credentials when logging in. If the communication between the client and server is compromised, it wouldn't matter if you store the admin status in the session or not. Yes, a malicious user could potentially capture the session ID and then hijack the session. But, they could just as easily get the login credentials which is much more significant.


So, I still stand by my earlier statements that determining if the user is an "admin" at login and then storing a value in the session to reference makes the most sense (assuming you don't have a business need pursuant to the requirements noted above). For the vast majority of general purpose sites, this is acceptable.


As an additional comment to using SSL, my opinion is that if you are not storing sensitive information or are not a high-visibility site, it is probably not necessary. There will always be people at both extremes and I would typically err on the side of security. But, the reality is that it is not a significant of a problem (at present). Plus, if your site warrants SSL, then there are a whole lot of other things you need to be doing to secure your site other than SSL. Most website attacks are not done through the data transport. Also, SSL doesn't come without a cost both financially and with performance.


So, as to using SSL, think about what would happen if your site was compromised. I.e. all the data exposed to a malicious user. Is there any confidential/financial data that would be obtained? If yes, use SSL, it probably isn't necessary. You should, of course, have regular backups in case you need to restore your site from any loss of data - whether it is malicious or not (e.g. failed hard drive). The chances of someone trying to use an unencrypted transmission (i.e. HTTP vs. HTTPS) to try and gain access as an admin is extremely unlikely. There are many much easier methods (e.g. social engineering) to gain such access.

The quality of the responses received is directly proportional to the quality of the question asked.

I do not always test the code I provide, so there may be some syntax errors. In 99% of all cases I found the solution to your problem here: http://www.php.net

#22 Jacques1


    Advanced Member

  • Members
  • PipPipPip
  • 513 posts

Posted 28 April 2014 - 12:23 PM

I understand what you're saying, I just don't agree with it.


To me, caching the status in the session in order to save one trivial query per request (maybe not even that, because the script may already have a query on the users table) is a classical premature optimization. I have absolutely no reason to believe that this has any relevant performance benefit whatsoever. If Timothy provides us with a concrete profile or benchmark which indicates the opposite, I'm happy to change my mind. Until then, this is pure speculation, especially since none of us has any information about the website. Is this a private homepage with 10 users per day running on a cheap shared host? A commercial site with thousands of requests per second? 


Yes, you can do this. It's acceptable. But when I implement something, it should be more than just acceptable. So what are the benefits?

  • It may theoretically save us a fraction of a millisecond under certain circumstances. Frankly, I don't care.
  • Checking the status is slightly easier, because you can just get it from the session. But you might as well wrap the database stuff in a function or method.

Compared to the downsides (duplicate data, risk of running into weird situations), I don't find this very convincing.


Again: Both is valid. This is not some life-altering decision. But when I have to choose between clarity and some speculative micro-optimization, I always go with clarity.




The arguments against TLS are rather weird in my opinion. When you're dealing with the passwords and e-mail addresses of other people, then this is sensitive data. It's not always about money.


How do you come to the conclusion that attacks against plaintext traffic are “extremely unlikely”? This certainly depends on how exactly each user accesses the Internet. If you have TLS enabled, you let them make that decision instead of forcing HTTP on everybody.


Worrying about the performance or possible costs is, again, speculative. If we're talking about a big site, then, yes, you'll have to take this into account. But who said anything about a big site? As far as I'm aware, Timothy might as well run some small personal website, in which case there would be zero costs and zero performance issues.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Cheap Linux VPS from $5
SSD Storage, 30 day Guarantee
1 TB of BW, 100% Network Uptime