chop Posted July 30, 2011 Share Posted July 30, 2011 Is it safe to carry around a user's password, from page to page, in a session variable? thanks Link to comment Share on other sites More sharing options...
Jonathon Posted July 30, 2011 Share Posted July 30, 2011 I would think that it would be better to set a $_SESSION['valid_user'] = true on a correct login and query for the presence of the $_SESSION['valid_user'] rather than an actual plain text password, especially depending on your hosting, as shared hosts often write to a tmp folder accessible to all on that server. Link to comment Share on other sites More sharing options...
chop Posted July 30, 2011 Author Share Posted July 30, 2011 Well, I wanted to compare the pw in the database to the one just entered by the user. So I could actually compare the two hashes of each password. So I would be carrying around just the hash of the original password. That would be okay wouldn't it? Link to comment Share on other sites More sharing options...
HartleySan Posted July 30, 2011 Share Posted July 30, 2011 If it's just the hash, I would say it's okay. Link to comment Share on other sites More sharing options...
chop Posted July 30, 2011 Author Share Posted July 30, 2011 Okay. I'll go with it.. thanks Link to comment Share on other sites More sharing options...
Stuart Posted July 30, 2011 Share Posted July 30, 2011 As much as I don't see a problem with it - I also see no need to? Why not just query the database at the point the user logs in then set a variable to confirm logged in status in the session? Link to comment Share on other sites More sharing options...
HartleySan Posted July 31, 2011 Share Posted July 31, 2011 I agree with Stuart. Link to comment Share on other sites More sharing options...
chop Posted July 31, 2011 Author Share Posted July 31, 2011 There are several places in the program where users might be changing their personal db information. Though they are already logged in, I ask them for their password just before they "submit" their edited information (in case they walked away from their computer while logged in and some lowly character walks by). To query the db each time just before posting their data seems more complicated than simply comparing their "confirming password" (that is the last field in the "update" form) with the $_session password that is being toted around from page to page. Make sense? thanks, chop Link to comment Share on other sites More sharing options...
Stuart Posted July 31, 2011 Share Posted July 31, 2011 Yeah that makes sense perfect sense. If you planned on storing these values in the session make sure your sessions are secure... most importantly change the session save path (or consider moving towards database driven sessions). You could also consider salting the passwords when you store them to prevent the same passwords having the same hashes. The thing is these are what I'd call utility tasks - which generally means they don't happen very often and so querying the database is not a major problem. Link to comment Share on other sites More sharing options...
chop Posted August 1, 2011 Author Share Posted August 1, 2011 Okay, thanks. I'll read up on what makes a secure session as opposed to a non-secure session (I actually thought that sessions were secure by default but I'm still in the early stages of learning about server security). thanks for your help, Chop Link to comment Share on other sites More sharing options...
Stuart Posted August 1, 2011 Share Posted August 1, 2011 The main issue's regarding sessions AFAIK is that on shared servers your session text files get stored in the same directory as every other domain on that server - therefore it's not that difficult to create a script to read the session files. To prevent this you call: session_save_path($path_to_folder); Passing to it a writable directory either stored outside the root directory OR one secured using the correct CHMOD settings. The alternative is to have sessions stored in a database - it's quite code intensive compared to changing the session save path but there's an example in Larry's PHP5 advanced. Database driven sessions have a few other advantages in allowing you to interrogate sessions in ways not really possible with file driven sessions. Equally if a site expands and it becomes necessary to host the sites content across multiple servers then database driven sessions are the only way to allow sessions in this environment. Link to comment Share on other sites More sharing options...
chop Posted August 1, 2011 Author Share Posted August 1, 2011 Thanks Stuart, "session_save_path($path_to_folder);" is something I'd like to add. Can you give me more specific instructions as to where I'd locate this code? thanks, Chop Link to comment Share on other sites More sharing options...
Stuart Posted August 1, 2011 Share Posted August 1, 2011 Yeah sure you basically just need to place it on the line before you start your session... eg: session_save_path($path); session_start(); That's all there is to it really there are a few other functions you can use to improve the security of your sessions in the manual and in addition http://phpsec.org/ has some great articles on sessions. Link to comment Share on other sites More sharing options...
chop Posted August 1, 2011 Author Share Posted August 1, 2011 Simple. That's great! Thanks again. Link to comment Share on other sites More sharing options...
HartleySan Posted August 2, 2011 Share Posted August 2, 2011 That's really useful advice, Stuart. I didn't know about that either. Thanks. Link to comment Share on other sites More sharing options...
Recommended Posts