PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Sun Jun 07, 2020 4:36 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Aug 23, 2011 12:17 am 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR
When a user authenticates, I want to store the user id and password hash in the session. On each page request, I would check for the existance of user id and then compare the password hash with what is on file in the database. If the password hash does not match, this means the user password was changed and to kill the session.

Basically it would boot anyone who was logged in under your account.


Is there any reason not to store the password hash in the session? The thought seems wrong, but I can't figure out why.


Top
 Profile  
 
PostPosted: Tue Aug 23, 2011 2:34 am 
Offline
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13592
Location: New York, NY, US
There are a couple reasons not to store the password in the session. The main one is security -- especially when you do not control access to the entire server hosting a site. On shared hosting it may be possible for someone to gain access to the session data and thereby discover passwords in it.

Probably the reason that it seems wrong to you is because of the mixing of Authentication and Access Control. Authentication is determining that the user is who they say they are. That is usually done by them supplying Credentials. One the other had, Access Control is determining what a user (Authenticated or not) is allowed to view on a website.

_________________
(#10850)


Top
 Profile  
 
PostPosted: Tue Aug 23, 2011 5:52 am 
Offline
Forum Regular
User avatar

Joined: Wed Apr 30, 2008 2:34 am
Posts: 794
If you use proper hashing, that is a strong hashing algorithm (e.g. whirlpool or sha512) along with salt & pepper, nobody would be able to retrieve any useful information from your session data. Besides, the number of people who actually can and will access your session data, is really pretty small.

Nonetheless it couldn't hurt to put an extra hashing step on the session data. For example, what you could store in the session data is: hash(p.s.u) where "hash" is a strong hash algorithm, "p" is the password hash which is stored in your database, "s" is some salt string, and "u" is some user dependent data (for example their user ID).

Keep in mind that session hijacking is still a risk, and depends on client side security (i.e. your visitor's). This wouldn't mean someone could ever read the actual session data, let alone extract anything useful from it if you apply hashing, but someone could still steal the session ID and impersonate another visitor. Including the visitor's IP in the "u" string above may help against this (at the trade-off of forcing people to re-login if they change location).


Top
 Profile  
 
PostPosted: Tue Aug 23, 2011 11:33 am 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR


Top
 Profile  
 
PostPosted: Tue Aug 23, 2011 11:54 am 
Offline
Briney Mod
User avatar

Joined: Mon Jan 19, 2004 7:11 pm
Posts: 6446
Location: 53.01N x 112.48W
There should be no reason to store the password in the session. If the entire reason is to be able to kill other logins as you, simply provide that functionality.

_________________
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.


Top
 Profile  
 
PostPosted: Tue Aug 23, 2011 2:51 pm 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR


Top
 Profile  
 
PostPosted: Tue Aug 23, 2011 3:01 pm 
Offline
Briney Mod
User avatar

Joined: Mon Jan 19, 2004 7:11 pm
Posts: 6446
Location: 53.01N x 112.48W
What you could do is store the most recent session ID with the username. When someone logs in, update that record with the person's session ID. Then, on each page load, check if the user's session ID matches the session stored with that username. If not, the user gets booted.

_________________
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.


Top
 Profile  
 
PostPosted: Tue Aug 23, 2011 9:32 pm 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR
Sure, but that means only 1 session can be logged in per user account, which may or may not be desirable.

In situations, like this message board, it is often helpful for me to type a reply in 1 window as I browse the thread in another. Right now I am logged in under both IE and Chrome. Other situations may be a joint account between husband and wife, or a generic "guest" account where you give the user basic credentials to access a semi-private area.

I could create a linkage table linking session id's to user id's, but then on password change, if I wiped the table, I would log out the user who just changed their password. It also seems a bit convoluted?

I understand the rule of thumb is not to store credentials in a session and I agree with it. However, why is it wrong to store the hash if the credentials/ingredients are not present?


Top
 Profile  
 
PostPosted: Tue Aug 23, 2011 11:07 pm 
Offline
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13592
Location: New York, NY, US

_________________
(#10850)


Top
 Profile  
 
PostPosted: Fri Aug 26, 2011 12:50 pm 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR


Top
 Profile  
 
PostPosted: Sun Sep 04, 2011 5:01 pm 
Offline
Forum Commoner
User avatar

Joined: Sun Sep 06, 2009 12:28 pm
Posts: 71
why do you not use php acl classes such as zend_acl, tackle and phpgacl


Top
 Profile  
 
PostPosted: Sun Sep 04, 2011 6:15 pm 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR


Top
 Profile  
 
PostPosted: Sat Sep 10, 2011 7:43 am 
Offline
Forum Regular
User avatar

Joined: Wed Apr 30, 2008 2:34 am
Posts: 794


Top
 Profile  
 
PostPosted: Mon Sep 12, 2011 5:01 am 
Offline
DevNet Resident
User avatar

Joined: Sun Sep 03, 2006 5:19 am
Posts: 1579
Location: Sofia, Bulgaria
My thoughts briefly are:

1. Marginally session and database are the same thing from the point of how securely you can access them - both are (ideally) under your control only (bar theoretical issues with shared hosting which you either have or don't have so you know if it applies to you beforehand). The crucial difference is in the data lifetime, since one is more volatile than the other. I might add that in my experience you are much more likely to have a vulnerability exposing database data than session data (think of how often you output data coming from one and the other source; in addition with vulnerable database access you can use timing attacks to extract info even without actual HTML output.

2. That said, I don't see why you would need such thing at all.


Top
 Profile  
 
PostPosted: Tue Sep 13, 2011 11:37 pm 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group