Re: [PHP] Re: Question regarding passwords/security
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
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
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
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
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