SitePoint Sponsor

User Tag List

Results 1 to 10 of 10
  1. #1
    SitePoint Guru okrogius's Avatar
    Join Date
    Mar 2002
    Location
    US
    Posts
    622
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Authentication concept

    Here's an idea I've been thinking about as far as implementing a very speedy uahentication. My main issue is that a user base will likely be on a different database (or server altogether) from the one with this application - so doing a constant "SELECT x FROM user WHERE userID=y;" on every page load is not really an option.

    Now to the idea...
    • Whenever a user is browsing as a guest - there is no cookies, no sessions. Nada [img]images/smilies/smile.gif[/img].
    • Whenever a user is logged in - there is one cookie always set (no cookie - not logged in).
    Cookie will be assembled like this:
    userID.username.passwordHash.expiration.cookieFingerprint

    An example one could be:
    "1.Admin.5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8.12345.0bfc3e5677f7f7e7337cd32ab8782fcba9f1c8bb

    In case you're curios above the above hashes:
    sha1('password') == 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
    sha1('1Admin5baa61e4c9b93f3f0682250b6cf8331b7ee68fd812345salt') == 0bfc3e5677f7f7e7337cd32ab8782fcba9f1c8bb
    12345 is just an example of an expiration value - it will be a unix timestamp formatted date within two weeks after the login (the time the cookie will stop authenticating someone)

    On each page load, if the cookie is present and validates (fingerprint - I assume I can trust data if the fingerprint matches since the "salt" is secret). If a cookie is not found, or fingerprint doesn't validate I don't authenticate the user.

    This works nicely effeciency wise as there is no session tracking at all, and no constant queries to get user information.

    Now... the disadvantages:
    -user is banned
    The system in now ay can tell if someone is banned at any point OTHER then login, when they get the cookie in the first place; but this isn't a biggie for me since I'm not planning to ban users from my webSITE.
    -password changed
    If a user logs in, doesn't log out, then changes the password on another computer, the first computer will still authenticate the user from the old cookie. Is it really a significant issue? I'm not sure. Part of the cookie is "expiration" value (unix timestamp), so even if a cookie like that is set - it will expire eventually (I'm planning to allow logins to be remember for only up to two weeks). Another measure I can do is ONLY verify the password on the first page load in a visit.

    I'm not really placing anything particularly sensitive on the website, so this systems seems adequate to me.

    If anyone can give impressions or critiques of this concept, I would greatly appreciate it. [img]images/smilies/smile.gif[/img] Perhaps, I'm missing some other disadvantages to this?
    Last edited by Codename49; May 8, 2003 at 16:28.

  2. #2
    SitePoint Guru
    Join Date
    Feb 2002
    Posts
    625
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well the first thing that comes to mind is, what if cookies are turned off?

    Another thing, if you are using cookies, you might as well use sessions, there is no difference. Sessions use a session file along with a cookie.

    Which means you could just as well use the advantages of Sessions (Session lifetime etc...). (and if cookies are turned off you can use url rewriting)

    Just my 2 cents

  3. #3
    SitePoint Guru okrogius's Avatar
    Join Date
    Mar 2002
    Location
    US
    Posts
    622
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If cookies are off... tough luck. Even if I will use sessions, I will have transid set to 0 since passing session IDs in URL is not only not pretty (think bookmarks), but is also a danger to getting a site spidered by search engines.

    As far as using sessions rather then this concept... I don't see much of a huge advantage, unless i start a new session on every browser session rather then keep one long happy session. But then again, I can just run a password check against the cookie on the first page load in the browser session.

  4. #4
    ********* Genius Mike's Avatar
    Join Date
    Apr 2001
    Location
    Canada
    Posts
    5,458
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Codename49
    -password changed
    If a user logs in, doesn't log out, then changes the password on another computer, the first computer will still authenticate the user from the old cookie. Is it really a significant issue? I'm not sure. Part of the cookie is "expiration" value (unix timestamp), so even if a cookie like that is set - it will expire eventually (I'm planning to allow logins to be remember for only up to two weeks). Another measure I can do is ONLY verify the password on the first page load in a visit.

    Well, I assume that if the Finger Print is correct, then you go on to validate the password, so why not log them out if the password is wrong but the fingerprint is correct?
    Mike
    It's not who I am underneath, but what I do that defines me.

  5. #5
    SitePoint Guru okrogius's Avatar
    Join Date
    Mar 2002
    Location
    US
    Posts
    622
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The concern is that the table with users (and their up to date passwords) is in a completely different database from the one that this program uses (and potentially, could be on another server & datacenter altogether). For this reason I'd prefer to avoid opening up two seperate DB connections on every page load - the whole reason for coming up with this very weird and unique authentication...

    I could however for example, do something like a:
    if ( rand(1,50) == 1 ) validatePassword();

    This will make the password be validated on every 50th page load (on average).

    On the other route that can be done is have a seperate cookie like "passwordChecked". If the cookie doesn't exist, I validate the password and set the cookie (duration for the browser session).

  6. #6
    ********* Genius Mike's Avatar
    Join Date
    Apr 2001
    Location
    Canada
    Posts
    5,458
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    It wouldn't need a second query at all.

    PHP Code:
    if( sha1(userID username passwordHash salt) == 'cookieFingerprint')
    {
        
    // query
        
    if( sha1(password) == 'passwordHash')
        {
            
    // good login
        
    }
        else
        {
        
    // cookie valid, password not.  possible change password
        // display login form with username already as a value in form text box
        
    }
    }
    else
    {
        
    // haxxor

    It's nothing special though.
    Mike
    It's not who I am underneath, but what I do that defines me.

  7. #7
    SitePoint Guru
    Join Date
    Feb 2002
    Posts
    625
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Codename49
    If cookies are off... tough luck.
    You know, from a personal point of view, i agree 100%, really

    Even if I will use sessions, I will have transid set to 0 since passing session IDs in URL is not only not pretty (think bookmarks), but is also a danger to getting a site spidered by search engines.
    Actually i ment, Session URL rewriting + mod_rewrite (this way your site get's spidered), which i must assume is in use anyway, unless your whole site does not use a single GET (ie. index.php?foo=bar , will not be spidered by for example Google, but i guess you know that).

  8. #8
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't see much of a huge advantage, unless i start a new session on every browser session rather then keep one long happy session.
    I don't actually think that you can generate a new session ID w/in the same browser session from the one it originally generates anyway - I've tried it.

    Sure, you could generate your own random 32 character ID but it's not a new session in it's self is it ?

    I can see your point of view really - I can, though I don't actually see why you cannot simply use sessions anyway; then you wouldn't be in the predictament your in just now

  9. #9
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    BTW - on the matter of creating a new session ID - i.e. more than one - two reasons when I remember

    1) Security
    2) Session wouldn't then be unique for that browser session, would it ?

  10. #10
    SitePoint Guru okrogius's Avatar
    Join Date
    Mar 2002
    Location
    US
    Posts
    622
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by naramation
    It wouldn't need a second query at all.

    PHP Code:
    if( sha1(userID username passwordHash salt) == 'cookieFingerprint')
    {
        
    // query
        
    if( sha1(password) == 'passwordHash')
        {
            
    // good login
        
    }
        else
        {
        
    // cookie valid, password not.  possible change password
        // display login form with username already as a value in form text box
        
    }
    }
    else
    {
        
    // haxxor

    It's nothing special though.
    The query to the databsae will be needed to get the real password .


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •