Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Understanding the GDN_Session table

1) Why are there 30+ rows in this table for my userid? I would expect one while logged in, zero when logged out.

2) What determines if a session is expired? When I log out, all those rows are still there. Is there a way to detect if a user is logged out via this table alone?


  • Options

    GDN_Session isn't for registering active sessions.

    http is stateless anyway, so there isn't really such a thing as session outside of a single request. Of course a cookie bridges requests but that doesn't determine whether it will end up in the session table.

    The session table is used by Session->Stash

    It is fine to purge older entries via crontab

    grep is your friend.

  • Options

    So the administrator authenticates, and has cookies inserted into his browser.
    On the next page request, there is no username/password being passed, so which cookie does Vanilla use, and AGAINST WHAT to determine the user has privs for the next page?

    I see the cookies:

    VanillaSessionID (I assume), has to be associated with privs in the backend somewhere.
    Thats what im looking for. Need to understand this architecture.

    Very different from phpBB which has a sessions table.

  • Options
    x00x00 MVP
    edited December 2013

    Authentication is done with Vanilla cookie only using HMAC

    There is a difference between the the password authentication and the cookie authentication.

    In fact Connect Authentication doesn't necessarily use a password authentication to link the user.

    The only way you would get a collision is from "hanging session", such as when you use the same salt on a different forum an userbase.

    grep is your friend.

  • Options
    x00x00 MVP
    edited December 2013

    VanillaSessionID is related to stash values.

    Stash is a way of passing data between requests for that session. In other word creating a separate cookie VanillaSessionID to act as a back reference.

    grep is your friend.

  • Options


    Chrome development tools wasnt showing me the vertical bars in the cookie data

    So UserID-Expiration|HMAC|Timestamp|UserID|Expiration

    Looked like one giant blob that threw me off. DOH.


    So once authentication is checked, I assume HMAC is generated, and inserted into the cookie for future validation on every page request. Yes?

    So which table holds this HMAC data to check the cookie against for future requests?

    Still missing something.

  • Options

    So which table holds this HMAC data to check the cookie against for future requests?

    No table. The whole point of HMAC is you don't need to store a hash somewhere.

    HMAC is a way of checking data against itself. it is not just a standard hash as this would be simple to forge. In encrypt that data, using a key. It would be near impossible to guess a valid hash.

    pass one generate key using salt an and timestamped data, then pass two generate the hash using the data an key.

    To check it you alread have the data so you just repeat that process to see if you arrive the the same hash.

    You can change the cookie name, domain, salt, and core hash algorithm (only md5 and sha1 are supported, this is used in both key generation and hash generation, which is stronger than simply hashing without HMAC which would just be a checksum in that application).

    If you wish to understand how this works, look at class.cookieidentity.php and read the wiki.

    grep is your friend.

  • Options

    Looked at the code, but still missing a BIG piece.

    When vanilla receives a request from a user, how does it determine if the user is logged in and thus has additional permissions?

    In phpBB and other systems, a large hashed string, or random unique identifier is placed into the cookie AND a session table somewhere.

    This acts as an authentication key, so subsequent requests can be checked to see if the user has already authenticated and is logged in without having to ask for authentication again on every request.

    If they are NOT using https, its possible for someone in the middle to sniff this key and fake a cookie to get the users permissions. However, the key is big enough not to be guessable.

    Im not sure what vanilla is doing to prevent this problem. I see the userID in the cookie, but surely that alone is not being used to determine if the user has authenticated, is logged in, and gets extra permissions. Way too easy to find or guess other users userid and create a cookie to get control as another user.

    So what does Vanilla use to prevent an engineered cookie to take over someones session?
    I see IP tracked in the DB in some places, but thats not enough either, or anyone on a shared IP could snag someone elses session.

  • Options
    x00x00 MVP
    edited December 2013

    Sorry I have provided all the information.

    Like I said there is no such thing as "logged in". http is stateless. "logged in" merely a term used for "sessions" represented by client cookie, outside of individual request these is no "session".

    Session table is unrelated, and for stashing bits and pieces cross request. But that does not mean that a session state exist cross request. It is bit like wordpress transient api, maybe that would be a better name for it.

    I explained quite clearly that HMAC takes the data (including UserID and salt) and uses it to generate a key which used get a hash. This Hash can be compared to by repeating the process the subsequent request. <- this is how you determine if the person is has a valid cookie and therefore "logged in".

    If you want further help please ask on a cryptography forum, maybe they will explain it better. The key is understand how it is using HMAC to verify it is valid data.

    You are welcome to try an forge it. Most likely it will be invalidated.

    Actually having a something stored somewhere to compare with, caries it own weakness too.

    grep is your friend.

  • Options

    Btw you could use this for verify any data not just the user, etc. And it is not just a checksum, the salt is obviously private, the key generated and the subsequent hash will be unique and near impossible to guess. None of this is stored anywhere which can be an advantage.

    CompareHashDigest prevents timing attacks.

    grep is your friend.

  • Options


    do you purge your session table of old entries? if so, how far back do you purge.

    I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.

  • Options

    you can, but ti is not used offen enough concern for a long time.

    It is extremely transient, so you are unlikely to need anything more than a day.

    it is for 'stashing' between requests.

    grep is your friend.

Sign In or Register to comment.