Re: Secure way to handle pw on session.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> ----- Original Message -----
> From: "Dan Joseph" <dmjoseph@xxxxxxxxx>
> To: php-general@xxxxxxxxxxxxx
> Subject: Re:  Secure way to handle pw on session.
> Date: Tue, 2 Sep 2008 15:35:26 -0400
> 
> 
> On Tue, Sep 2, 2008 at 3:27 PM, k bah <kbah@xxxxxxxxxxxxx> wrote:
> 
> >
> >  Hi,
> >
> >  I noticed session files are kept on /tmp for a while, and even if they
> > were immediately deleted, well, someone could use one of my php scripts to
> > inject code and read them, since they belong to the httpd user.
> >  What's the best way to receive passwords thru a form and store them in the
> > $_SESSION while I process other information to decide whether or not that
> > user is able to proceed and login (check to see if user is also allowed to
> > use that service, not just validate user/pw)? I use https, always, no plain
> > http is used.
> >
> >  Thanks
> >
> >
> I personally would recommend you never store passwords in $_SESSION.
> 
> I don't know how your auth code works, but the way I've always done it would
> be to process everything when you his submit, with the password being in
> $_POST or $_GET, then after you authenticate the user, drop it and don't
> store it with sessions.  If you find you need it to be stored for other
> things, I'd suggest rethinking the design/checking you're doing.
> 
> --
> -Dan Joseph
> 


 You're right, and thanks to all replies, they were all helpful.
 I rechecked and, really, there's no reason to store password values anywhere, the only 2 places in my code where I use passwords I use it "straight out from the POST". First I filter the content, only allowing to continue if preg_match_all() gives me a "continue" (I compare the return of preg_match_all() with strlen(), and if they are not the same, it means that the received POST value has at least 1 character that is not allowed), I was storing the value on the session, now I simply store it on a script variable (it will be unset once the script ends), and after that I pass it to another function (present on an included php file which actually communicates with the backend where hashed passwords are kept). As you said, after the input cleanup, I unset password on $_POST. Now it only stays on the script local variable, and the called function which does the real auth, once that function ends and the script (a form action url) ends, there's no password. Since I always use https, there's no reason to worry with the path between the user browser and the php script on the server that receives the POST. If there were no https, I would use javascript to not pass the password in plain text to the server.


 thanks again

=


-- 
Powered by Outblaze

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux