Authentication concept

[okrogius]

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?

[datune]

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

[okrogius]

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.

[Mike]

-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?

[okrogius]

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).

[Mike]

It wouldn't need a second query at all.

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.

[datune]

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).

[Dr Livingston]

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

[Dr Livingston]

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 ?

[okrogius]

It wouldn't need a second query at all.

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 .