On Tue, 2008-09-02 at 16:10 -0400, Eric Butera wrote: > On Tue, Sep 2, 2008 at 4:06 PM, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: > > On Tue, 2008-09-02 at 12:58 -0700, mike wrote: > >> As an additional note suhosin can transparently encrypt and decrypt > >> your session data for reasons just like the /tmp issue. It happens > >> without you needing to configure anything (except to enable or disable > >> it) I think it is enabled by default. > > > > This won't help since the OP mentioned he was worried about code > > injection exposing the contents of $_SESSION and presumably suhosin > > doesn't prevent restoration of the session on page load. > > > > Cheers, > > Rob. > > > > > > > >> On Sep 2, 2008, at 12:35 PM, "Dan Joseph" <dmjoseph@xxxxxxxxx> wrote: > >> > >> > 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 > >> >> > >> >> = > >> >> > >> >> > >> >> -- > >> >> Powered by Outblaze > >> >> > >> >> -- > >> >> PHP General Mailing List (http://www.php.net/) > >> >> To unsubscribe, visit: http://www.php.net/unsub.php > >> >> > >> >> > >> > 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 > >> > > >> > www.canishosting.com - Plans start @ $1.99/month. > >> > > >> > "Build a man a fire, and he will be warm for the rest of the day. > >> > Light a man on fire, and will be warm for the rest of his life." > >> > > -- > > http://www.interjinn.com > > Application and Templating Framework for PHP > > > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > If code is getting injected into our apps we're screwed. Too true *lol*. The database is probably exposed at that point. Although, if you can see passwords in plaintext, your system is compromised beyond any fixes you may introduce. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
