Re: [PHP] Re: Question regarding passwords/security

2011-12-23 Thread Curtis Maurand



Store everything in the database in an encrypted form.

Stuart Dallas wrote:
 On 22 Dec 2011, at 19:34, Paul M Foster
wrote:
 
 I have concerns that the items in a
session buffer can be copied and
 used to spoof legitimate
logins. This is harder to do when the info is
 held in a
database.
 
 Storing stuff in a database is no more
secure, it simply requires one
 single extra step... finding the
DB credentials in the source code. Given
 that the only way a
user could read session data (assuming you're using
 the default
session handler, i.e. file-based) is if they have access to

those files.
 
 If they do have access to those files
they almost certainly also have
 access to your source code
(since the web user must be able to read both),
 especially if
you're using a shared host. If you're using a dedicated
 server
then you should address the reason you're worried about people

having access to session files first.
 
 -Stuart
 
 --
 Stuart Dallas
 3ft9 Ltd

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



[PHP] Re: Question regarding passwords/security

2011-12-22 Thread Al



On 12/22/2011 10:05 AM, Paul M Foster wrote:

Not sure how to ask this question... I've always eschewed consulting a
database on page loads to determine if a user is logged in, primarily
because of latency issues. For example, you could store a nonce like the
session ID in a table for a user when they log in. Then each time they
arrive at a page which needs certain permissions to access, you'd check
the table for the nonce and compare it to the actual session ID or
whatever to determine that they're properly logged in. This seems
reasonable but suffers from the lag on the database link's
query-and-response lag time. So I've always preferred some solution
where something is dragged along in a session cookie instead. Maybe
something like the hash of user login, email and user name, which
wouldn't be there unless you'd put it there on login. But this latter
scheme just seems inherently less secure than consulting the table.

Is there any concensus or overwhelming argument one way or the other?

Paul



Why not just use Sessions, that's what the function is for.
http://php.net/manual/en/features.sessions.php There is a good example on this 
page.

I'm also big on using the session buffer to maintain the current states for 
visitors.  e.g., one I'm working on now. Obviously, most are binary switches. 
Makes condition logic simple.


[confirmedRestrictedUser] =
[idPassed] =
[loggedIn] =
[newRegRecordMode] =
[pendingRestrictedUser] =
[recordToken] =
[regModeLoggedIn] =
[regUserEditMode] =
[restrictedMode] = 1
[secrCodePassed] =
[securityPassed] =
[sessionStart] = Thu, 22 Dec 2011 12:49:54 -0500
[userType] = restricted


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




Re: [PHP] Re: Question regarding passwords/security

2011-12-22 Thread Paul M Foster
On Thu, Dec 22, 2011 at 12:55:41PM -0500, Al wrote:

 
 
 On 12/22/2011 10:05 AM, Paul M Foster wrote:
 Not sure how to ask this question... I've always eschewed consulting a
 database on page loads to determine if a user is logged in, primarily
 because of latency issues. For example, you could store a nonce like the
 session ID in a table for a user when they log in. Then each time they
 arrive at a page which needs certain permissions to access, you'd check
 the table for the nonce and compare it to the actual session ID or
 whatever to determine that they're properly logged in. This seems
 reasonable but suffers from the lag on the database link's
 query-and-response lag time. So I've always preferred some solution
 where something is dragged along in a session cookie instead. Maybe
 something like the hash of user login, email and user name, which
 wouldn't be there unless you'd put it there on login. But this latter
 scheme just seems inherently less secure than consulting the table.
 
 Is there any concensus or overwhelming argument one way or the other?
 
 Paul
 
 
 Why not just use Sessions, that's what the function is for.
 http://php.net/manual/en/features.sessions.php There is a good example on 
 this page.
 
 I'm also big on using the session buffer to maintain the current
 states for visitors.  e.g., one I'm working on now. Obviously, most
 are binary switches. Makes condition logic simple.
 
 [confirmedRestrictedUser] =
 [idPassed] =
 [loggedIn] =
 [newRegRecordMode] =
 [pendingRestrictedUser] =
 [recordToken] =
 [regModeLoggedIn] =
 [regUserEditMode] =
 [restrictedMode] = 1
 [secrCodePassed] =
 [securityPassed] =
 [sessionStart] = Thu, 22 Dec 2011 12:49:54 -0500
 [userType] = restricted

I have concerns that the items in a session buffer can be copied and
used to spoof legitimate logins. This is harder to do when the info is
held in a database.

Paul

-- 
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com

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



Re: [PHP] Re: Question regarding passwords/security

2011-12-22 Thread Stuart Dallas
On 22 Dec 2011, at 19:34, Paul M Foster wrote:

 I have concerns that the items in a session buffer can be copied and
 used to spoof legitimate logins. This is harder to do when the info is
 held in a database.

Storing stuff in a database is no more secure, it simply requires one single 
extra step... finding the DB credentials in the source code. Given that the 
only way a user could read session data (assuming you're using the default 
session handler, i.e. file-based) is if they have access to those files.

If they do have access to those files they almost certainly also have access to 
your source code (since the web user must be able to read both), especially if 
you're using a shared host. If you're using a dedicated server then you should 
address the reason you're worried about people having access to session files 
first.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Question regarding passwords/security

2011-12-22 Thread Al



On 12/22/2011 2:54 PM, Stuart Dallas wrote:

On 22 Dec 2011, at 19:34, Paul M Foster wrote:


I have concerns that the items in a session buffer can be copied and
used to spoof legitimate logins. This is harder to do when the info is
held in a database.


Storing stuff in a database is no more secure, it simply requires one single 
extra step... finding the DB credentials in the source code. Given that the 
only way a user could read session data (assuming you're using the default 
session handler, i.e. file-based) is if they have access to those files.

If they do have access to those files they almost certainly also have access to 
your source code (since the web user must be able to read both), especially if 
you're using a shared host. If you're using a dedicated server then you should 
address the reason you're worried about people having access to session files 
first.

-Stuart



Sessions are faster, one step to read the session array.

Encode a token e.g., MD5 the timestamp, and save it in the session buffer. Gets 
pretty secure.  If you're on a shared host with poor security, bad folks can do 
anything on your site.


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