Authentication Cookie to be extended with every page load

  • I’m trying to change the auth cookies so that they extend with every page load but therefore I’d also set them for a much shorter time, say 15 mins, much like it’s needed for web apps for example (which is how I intend to use the portion of wordpress I’m going to use this for).

    Ideally I would want to do this the JS way too to extend the cookie time with every mouse click and keystroke, so if you have ideas in doing so, it’s very much welcome too.

    What I tried, the PHP way – the problem with this one is that it logs me out every time I reload the page (added this to functions.php) – one of the things I’m a bit unsure about in this code is the arguments of wp_set_auth_cookie:

    /* Renew cookie at every page load */
function renew_wp_cookie() {

    global $current_user;
    get_currentuserinfo();
    $userinnow = $current_user->user_login;
    if (is_user_logged_in()) {
        wp_set_auth_cookie($userinnow, $remember, $secure);
    }
    else wp_clear_auth_cookie();

}

add_action('init', 'renew_wp_cookie');

    On the JS front, I have found following function in one of the .js files provided with my theme – I may make some use of it, not sure yet how:

    function setCookie(c_name,value,expiredays)
{
	var exdate = new Date();
	exdate.setDate(exdate.getDate() + expiredays);
	document.cookie = c_name + "=" + escape(value) +
	((expiredays==null) ? "" : ";expires=" + exdate.toGMTString()) + '; path=/';
}
Viewing 9 replies - 1 through 9 (of 9 total)
  • Moderator bcworkz

    (@bcworkz)

    Every time you call wp_set_auth_cookie() it creates a new cookie with a different hash. This discrepancy forces a login request. I don’t think you can change the expiration of the auth cookie after the fact, as it is part of the hash. You get a different hash when you change the expiration, so a login request is forced again.

    You probably need to manage user activity yourself somehow and if there was no activity in a certain time, clear the auth cookie on the next request to force a logout. It’s somewhat impractical to monitor keystroke activity server side, though possible. And client side script can be compromised, so I’m unsure of an effective approach here. I’m just pretty sure you will not get anywhere trying to change auth cookies.

    Thread Starter webeno

    (@webeno)

    Well, most of the web apps, even bigger ones, use some method of logging out clients after a certain time of inactivity and they seem to measure time by checking clicks and keystrokes, so it’s certainly a client side check that they’re making. How do they do it to remain secure?

    Moderator bcworkz

    (@bcworkz)

    Clicks are easy to monitor server side so easy to be secure, it’s only keystrokes that are problematic to monitor. I can’t really imagine a web page that would have only keystrokes and no clicks in any reasonable no activity forced logout time frame.

    To be honest, I have no practical knowledge about how various sites time out with inactivity. For all I know they just do it insecurely client side. What I have said is based on my knowledge of HTTP communications and how servers and browsers utilize such to operate.

    Thread Starter webeno

    (@webeno)

    Don’t you have to load a page or reload at least in order to monitor clicks server side? I have seen a way around actually reloading the page using a self-closing pop-out that actually does the check and closes itself afterwards if the request is valid (user is a valid user). Were you referring to this?

    Moderator bcworkz

    (@bcworkz)

    Heh, no, I didn’t really put that much thought into my response. Details of how to implement this was not on my radar. I only had in mind the client needed to communicate with the server in some way, perhaps via normal AJAX interactions with the page, rather than loading an entire page. The pop-up idea would work, except I’m still not convinced it’s totally secure. It certainly would not be if it were javascript driven. Using the refresh meta tag would be more difficult to circumvent, but I’m not sure that would work very well.

    I can imagine all sorts of javascript techniques to monitor activity, and perhaps the reality is most sites do not consider security to be a serious issue in monitoring activity so have no issue with javascript techniques.

    Thread Starter webeno

    (@webeno)

    well, if I’m already allowing the user to extend their session with every page load, doing a similar action (extending the session) with a client side script (making sure it is built so that it does not to allow too much access to the server side stuff or sensitive info) shouldn’t be any less secure, right? the server side check would still remain and include a check to see if the client side code has been executed (ie. javascript enabled) at all or not.

    so basically what i would do…

    …if the user doesn’t reload the page:
    1. at session start (successful login), i’d create a session variable (server side) with a token and add this token to the db along with the login time. setup a timer on client side ensuring user activity (mouse move, keystroke) reset the timer and updates a different session variable basically storing the info that the timer is on (not yet expired).
    2. when close to end of time and no activity, pop-up coming up with a countdown and logout (this one would log the user out, both session variables are cleared, login time cleared from db) / continue options (latter one would reset the timer).
    3. when time expires and no response, user is logged out, both session variables are cleared, login time is cleared from db.

    …would the user reload the page:
    1. check the first session variable with the token against the db
    – if not present, log the user out (clearing everything)
    – if present…
    2. check if the session variable for the timer being on is set
    – if not and time defined counted from login time stored in the db has expired, log the user out (clearing everything)
    – if yes, keep the session alive

    did i miss anything? where is the security flaw, to your opinion?

    Moderator bcworkz

    (@bcworkz)

    How would the server know to extend the session if the user were active on the page with keystrokes and mouse movement/clicks but did not reload the page or otherwise make a server request? The client will be content, but on the next request, the server will think the session has timed out and force a new login. That would be annoying.

    As for security, all I know is client side scripts are inherently insecure. I’ve really no idea how someone would actually game the system, say alter your timer so it never times out. I would not know even where to begin doing something like that, but I’m sure many others do. So maintaining a server side session variable is the right approach, even if the client timer is compromised, the server will not comply with the next late request without a new logon.

    The crux of the problem as I see it is how to let the server know the page is active without a nefarious sort being able to fake activity by sending false requests to extend the session. I’m not really qualified to suggest a secure method. One needs to think in evil ways to ensure a method is secure and that is just not my nature.

    I may be wrong, but I’m not sure how important total security is here, perhaps the goal should be make it difficult enough to game the system such that the vast majority of users could not be bothered to even try.

    I think what I would do to extend the session server side is to have javascript occasionally send a GET to the server before the session times out to extend it. By using true nonces, not the WP good for 24 hours nonces, this exchange could be reasonably secured. A user could disable the whole system by disabling javascript, but that will just cause the server to time out even if there was honest activity. Their current page may not “logout” with javascript disabled, but they won’t get any new information from the server without logging on again.

    Someone could develop an auto pilot script to constantly extend their session, but to what end? So they can go to lunch and not have to login again? And to do this, they may need to login dozens of times in order to figure out what’s needed to game the system. It’s possible, but would anyone really bother?

    Thread Starter webeno

    (@webeno)

    It’s really a nice thought that people wouldn’t bother breaking code, but it is actually happening. I’d rather take care of it now than having to think of what I have lost after it’s done.

    To your question at the beginning: the server would know to extend the session has been described in my point 2: “check if the session variable for the timer being on is set” – this variable would be updated by javascript every time there is activity on client side. This step would basically also take care of javascript being deactivated, as in that case the server side code would make the user log out.

    As to sending a GET to the server, doesn’t it need a page reload for it to work? Or else, considering the login time is stored in the server, wouldn’t you need a database connection made by the client-side script in order to know that you can keep the session alive…?

    Moderator bcworkz

    (@bcworkz)

    Yeah, some evil bastard always ruins things for everyone. But remember we’re only try to tell if a verified user is still active or not, we’re not giving privileged access to bad actors. I don’t know what you’re up to (don’t want to know) so I don’t know what degree of protection is warranted. If it’s so important that iron clad security is required, I’m not qualified to advise you. I know enough to suggest reasonable security, I cannot know if it’s hack proof.

    Sorry I missed the update part, I admit I did not read your entire post with the utmost care. Sounds like you’ve got it all covered then.

    If the GET is sent by javascript, it’s up to the javascript and the GET target as to what happens. A page can reload, or not, or some javascript variable can be updated, like the next nonce, or not. Nothing needs to happen at all, but then there’s not much point in that. The field is open, anything within the limits of server and client can happen.

    Client connection to the DB? No, don’t do that! It must be filtered through the server. Client only communicates with the server. The server decides if the request is valid and only then checks the database and updates as necessary, then responds to the request so the client side script knows how to proceed, either continue as normal, or redirect to a login page, pop up warning or whatever.

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Authentication Cookie to be extended with every page load’ is closed to new replies.