tork

Thanks .josh. I agree in principle. My challenge is that an attack on the database will have extreme consequences should user's data get to the marketplace. I'm wide open to any ideas as to how to keep other users' data safe from a lazy pw user (and I don't mean people who don't like constraints, but people who just throw in a name they know). I am already using a number of techniques to prevent attacks throughout the site. Basically, I'm down to password control now. BTW, I hear you; I too like to control my own password structures with the sites I'm on. Where's the balance?

I'm building a regex for password control. I'm trying to have the passwords have at least: 1 small letter, 1 capital letter, 1 number, and 1 special character, while having between 8 and 20 characters inclusive. All seems to work up to this point in testing, however, the 20 limit seems to work except that when I compare the 21 (or more) first password with the comparison password entered by the user, they are interpreted as being different when in fact they were entered the same. Any ideas? #.*^(?=.{8,10})(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.*\W).*$#

That was it. Thanks to both of you. Don't you just love that Aha feeling when you discover something new?

Ah! That explains why it didn't work. However, I got this error when I replaced the code: call_user_func_array() expects parameter 1 to be a valid callback, first array member is not a valid class name or object

Here's what works: $q = "SELECT user_id FROM users WHERE pass=? AND active IS NULL"; $r = mysqli_prepare($dbc, $q) mysqli_stmt_bind_param($r, 's', $pw); mysqli_stmt_execute($r); However, what I'd like to do is make the SELECT like the following to check active IS NULL: $a = 'IS NULL'; $q = "SELECT user_id FROM users WHERE pass=? AND active=?"; $r = mysqli_prepare($dbc, $q) mysqli_stmt_bind_param($r, 'ss', $pw, $a); mysqli_stmt_execute($r); Since this doesn't work, anybody got any ideas what would work?

Perfect! Thanks Ch0cu3r.

Here's the non-prepared MySQLi procedural code for registering a user - the appropriate parts are for the password ($p) protection: . . $trimmed = array_map('trim', $_POST); // Assume invalid values: $fn = $ln = $e = $p = FALSE; . . // Check for a password and match against the confirmed password: if (preg_match ('/^\w{4,20}$/', $trimmed['password1']) ) { if ($trimmed['password1'] == $trimmed['password2']) { $p = mysqli_real_escape_string ($dbc, $trimmed['password1']); } else { echo '<p class="error">Your password did not match the confirmed password!</p>'; } } else { echo '<p class="error">Please enter a valid password!</p>'; } . (identical code up to here in both scripts - actually, untouched) . $qa = "INSERT INTO nm_users (email, pass, first_name, last_name, active, registration_date) VALUES ('$e', SHA1('$p'), '$fn', '$ln', '$a', NOW() )"; $ra = mysqli_query ($dbc, $qa) or trigger_error("Query: $q\n<br />MySQL Error: " . mysqli_error($dbc)); . . (end this part of script) When logging in to the saved password, it works perfectly. I decided to use prepared statements instead, so here is the equivalent code: . . $pw = SHA1('$p'); $qa = "INSERT INTO nm_users (email, pass, first_name, last_name, active, registration_date) VALUES (?, ?, ?, ?, ?, NOW() )"; $ra = mysqli_prepare($dbc, $qa) or trigger_error("Query: $qa\n<br />MySQL Error: " . mysqli_stmt_error($dbc)); mysqli_stmt_bind_param($ra, 'sssss', $e, $pw, $fn, $ln, $a); mysqli_stmt_execute($ra); mysqli_stmt_close($ra); (end this part of script) The prepared code vs.the standard code generates a different hex value for the same passwords ($p) even before the prepared statements start! How can this be? There were no changes to the front code. And when logging in after successful registration and activation, the same password used to register is rejected as you'd expect. Does anyone know what's going on here?

Great! Thanks again.

Thanks for that clear explanation. As a matter of understanding session parameters, I set the probability at 100% (100/100) and maxlifetime at 240 secs. Then I ran a session and timed the session record for when it got deleted. I expected it to delete in 4 minutes from the start of the session (session_start()). Yet it's been there much longer. Am I missing something here?

Correct me if I'm wrong, but if I session_regenerate_id(false) and set my php.ini gc parameters to a high probability to kick in after a short maxlifetime, would this not minimize the risk of a race condition? I tested this, yet my session file has not been removed after 240 - I set the probability at 100% (100/100) and maxlifetime at 240 secs. Now I'm getting confused

Race conditioning and security are indeed my issues. Thanks.

Thank you. However, I need to be more specific. Is there any way of deleting a session file by naming it? EG (and I know the parameter must be void): session_destroy(session_id). Clearly this won't work. What I need is a non-regenerate method of destroying particular sessions by their session_id. If it's not removed, then user data may be picked up via the race issue. Any ideas anybody?

I notice that when I've regenerated a session_id(), that the original session remains on the server while the new one is added. I'd like to know how I can remove the old session. I may be mistaken, however I believe the issue is called racing, and is that the old session could (rarely, but possibly) be re-used if the session_id algorithm created it again, thus allowing the second user to have access to the first user's old session. 1. Do I understand the issue correctly? 2. How do I remove the old session?

I appreciate your help, guys. Now it all makes sense.

Thanks Ch0cu3r. So what I've done to stop the current cookie and start a newly named one follows. Is this correct? What actaully removes the old cookies? (I'm thinking they could accumulate to whatever max is allowed in the browser). // Identify the session that needs destroyed (if it is not identified, then the default session name in php.ini will be used - eg PHPSESSION) session_name('2011'); // Start the previous session - a new session id will be generated if the current one has expired session_start(); // Destroy the previous session - the 'destroy' doesn't remove the cookie, but simply makes the cookie invalid, and removes all session values and stops the session session_destroy(); // Now a new session name is given session_name('2012'); // And the new session begins session_start(); // Never use setcookie with session cookies

I wrote the following into my script, as per your reference: $params = session_get_cookie_params(); setcookie(session_name(), '', 0, $params['path'], $params['domain'], $params['secure'], isset($params['httponly'])); However, the cookies weren't deleted until I changed the php.ini parameter ; http://php.net/session.name to the session_name of the session cookie that I believe I had created it with. I was trying to delete it with the session.name PHPSESSION in php.ini. Is this what you expected, mentalist?

I'm not sure what you're trying to say. If I use session_delete(), it will have to come after the session_start() and will delete the new session. The cookies are all session cookies and were not set using setcookie. Can you explain what you mean please?

And .. php.ini has the following parameters set: ; http://php.net/session.use-only-cookies session.use_only_cookies = 1 ; http://php.net/session.name session.name = PHPSESSION ; http://php.net/session.cookie-lifetime session.cookie_lifetime = 30

Here's my original script: session_name('2010'); // to name the session session_start(); // 2010 session starts - either found or created Firebug shows the correct session cookie: 2010 and expiry data Script changed to: session_name('2013'); // to name the session session_start(); // 2013 session should cause the 2013 session cookie to be created setcookie(session_name('2010'), '', time()-3600, '/', '.site.com'); // old session cookie 2010 should be deleted Firebug still shows the 2010 session cookie and not the 2013 session cookie: 2010 and expiry data - no change to expiry data or cookie name. How can I delete the 2010 session cookie and create the new 2013 session cookie?

Ah! That explains it! Thanks Ch0cu3r.

Here are my relevant php.ini settings: session.name = hello session.cookie_lifetime = 30 session.cookie_path = / session.cookie_domain = .name.com And my script: session_start(); setcookie('hello', '', time(), '/', '.name.com'); The php.ini value works as expected with the cookie being created and then timing out after 30 seconds - confirmed in Firebug under 'Cookies'. Then I add the session_set_cookie_params statement with 75 second expiry: session_set_cookie_params(75, '/', '.name.com'); session_start(); setcookie('hello', '', time(), '/', '.name.com'); When I look at the Cookies tab in Firebug, no cookie shows up. Now I reckoned that the session_set_cookie_params 75 seconds would overwrite the php.ini session.cookie_lifetime value of 30 seconds, and the setcookie create a cookie timed to expire 75 seconds later, yet they seem not to. Why is this?

Thanks Guru. Works perfectly. $data = array(); function read_session($sid) { global $dbc; $q = "SELECT * FROM nm_session"; $r = mysqli_query($dbc, $q); if (mysqli_num_rows($r) == 1) { $data = mysqli_fetch_assoc($r); return $data; } else { return 'return no data from read_session<br />'; } } $data = read_session($sid); echo $data['id']."<br />"; echo $data['user_id']."<br />"; echo $data['last_accessed']."<br />"; echo $data['first_name']."<br />"; echo $data['user_level']."<br />"; echo $data['paused']."<br />"; echo $data['changed_pw']."<br />"; echo $data['tests']."<br />";

I'm trying to get the data, which is successfully read from the db table accessed inside the function, to be transferred via the list() below. However, I get the offset 7 error. Why is this? Ideally, I'd like to not use list() but simply echo the $data elements. Any ideas? An error occurred in script 'blah..blah' on line 203: Undefined offset: 7 Date/Time: 10-23-2013 21:16:26 $data = array(); function read_session($sid) { global $dbc; $q = "SELECT * FROM nm_session"; $r = mysqli_query($dbc, $q); if (mysqli_num_rows($r) == 1) { $data = mysqli_fetch_assoc($r); return $data; } else { return 'return no data from read_session<br />'; } } list($data['id'], $data['user_id'], $data['last_accessed'], $data['first_name'], $data['user_level'], $data['paused'], $data['changed_pw'], $data['tests']) = read_session($sid); // This is line 203 echo $data['id']."<br />"; echo $data['user_id']."<br />"; echo $data['last_accessed']."<br />"; echo $data['first_name']."<br />"; echo $data['user_level']."<br />"; echo $data['paused']."<br />"; echo $data['changed_pw']."<br />"; echo $data['tests']."<br />";

Thank you Guru. I set all the php.ini parameters that you recommended. And I put the session_set_cookie_params(120, '/', '.site_name.com'); (2 mins only, for immediate testing and re-testing .. ). It all works perfectly. Much obliged *secret hero worship taking place* If you're Canadian like me, have a good thanksgiving.

Also, when I start afresh with site_name.com after a successful login (but without being able to logout) then the session ID is picked up and "Welcome, Jimmy!" and the logout group appear. So now it's picking up the session data, when before it didn't. How come?