Authentication Options

Just wondering what options I have for authentication on our admin areas.

I'm getting a bit bored of sessions expiring and re-logging in so I'm looking for alternatives.

The platform is Apache/PHP btw.

HTTP authentication doesn't expire if the browser stays open which is great. I can create separate usernames and log ins BUT...

Can I let my php scripts know who is logged in?

I basically have an admin access levels system where one person logging in sees only what they need whilst another might see more functionailty. Works great now with login and sessions but like I said, I hate the sessions expiring (and this is on a shared server so can't change the max sessions lenth I believe). It matches the log in details against the permissions.

Can I match HTTP authentication (via htaccess) somehow with my PHP scripts?

Also, someone mentioned PKI to me. Can anyone tell me whether/how that would work or refer me to a quality resource on this subject?

Thanks!

 

echo $_SERVER["REMOTE_USER"];

PHP:

or check with

print_r($_SERVER);

PHP:

 

Or even worse:

  $_SERVER[PHP_AUTH_USER]  // login
  $_SERVER[PHP_AUTH_PW]    // password (ASCII)

PHP:

 

So I can retrieve the details and swap the session stuff with this. Interesting, will try that. Thanks!

 

PKI stands for Public Key Infrastructure - is a set of algorythms that work public/private key enctyption. I don't think you need it here, though. Your sessions expire because your session cookie lasts only 20-30 minutes or so. If you slip the authenticated user a persistent cookie, they will be able to login in, say, an hour. For example, once you authenticated a user and you want them to be able to come back within an hour, you can create a hash of the user's name, expiry timestamp and a server secret and return this as a cookie:

$hash = md5($user_name.$expiry_date.$server_secret);
setcookie("login",
      $user_name.",".$expiry_date.",".base64_encode($hash),time()+3600);

PHP:

Then check each request for this cookie and if found, check if the hash in the cookie is correct (by doing the same - hasing the user name, the date in the cookie and the server secret; use regex to extract parts).

If the user tries to edit their cookie by changing the name of the expiry date, their hash won't match and you will reject such requests. You can also throw in your server's host name into the cookie/hash, so that a cookie from one domain couldn't be used with another one.

You can make this mechanism more secure if you don't pass user name with the cookie, but instead use some kind of identifier that can be easily mapped to a user on the server side. Also, make sure to create a cookie with the secure parameter set to 1 so that the cookie wouldn't be transferred over non-SSL connections.

J.D.

 

J.D. & Co.

Any of you worked with systems based on Kerberos authentication? I was wondering how well PHP and Apache interact with it now.

 

I never used Kerberos with PHP, but Kerberos is a quite secure authentication system. It is used in Win2K within a domain. I think MSN may be using it as well, although I'm not sure.

The way interaction goes is that the client (PHP client in this case) will send Kerberos Key Distribution Center (KDC) a request informing KDC that it wishes to connect to some server B. KDC creates a ticket that only server B can decrypt and sends it back, along with the session key, to the client encrypted with the client's key. The ticket contains client's info, plus the client-server session key. The client sends this ticket to the server and they both can now talk using the shared session key. Because both were able to decrypt their parts, each one of them knows that the other party is who they claim they are.

You can encode these tickets as cookies or query strings and pass them to the users, so that they can authenticate once and then use the acquired ticket to logon to multiple servers without additional authentication (just with a bunch of redirects bouncing them off the target and authentication servers while they echange tickets).

That's just to give you the idea what Kerberos is about.

J.D.

 

Next question - How has J.D only got 2 greens?

 

Helping mostly one-time posters will do that to you

 

use cookies? with different user levels, md5 pass and user id in a cookie, and a script to read and match info with db, then set username and userlevel. you can see who's online, and even where they are (if added)

 

But using cookies limits one PC to one user doesn't it?

 

it doesnt exactly limit pc to one user, but when other user logs in from same machine, it logs another one off, because cookie is replaced.

 

Cookies are stored separately for each user.

J.D.

 

I didn't mean PC user, i meant website user

 

I'm afraid this statement doesn't make much sense. Each website visitor (which is a PC user, BTW) gets their own copy of a cookie. This cookie will never be overwritten by any cookies that were issued to other visitors.

J.D.

 

well, yeah, but he asked on the same computer. if i login to the site A from my pc, the cookie will be made (whatever the site names it) - cookieA. Now when i browse the site, it looks if i have cookieA and reads info from it. then i decide to login as another user. when i login as another user, the cookie gets rewritten. site still looks in cookieA but finds another info in there and auths me as other user. we are talking about same computer here. of course each user on their own different pc gets own cookie.

 

If you are talking about an OS user logging out and then logging in again as a different user, then you are mistaken, cookies are kept separately for each user account.

J.D.

 

i DIDNT mean that, but that was exactly why i said

lets not troll this thread, cheers

 

I won;t be logging out a windows user. We just have staff hotdesking to utilise office space to the max but they share the same PC login though have their own website login.

 

You are missing the point then. Nothing gets overwritten. Here's how it works (or doesn't in this case):

* person X logs into the website, gets a session cookie A and a persistent cookie B
* person X leaves the machine without logging out (from neither - web or PC), but closes the browser
* the session cookie A gets deleted, but the persistent cookie is stored until its expiration date
* person Y starts up the browser within the same OS login session and visits the same website
* the browser submits the persistent cookie B and the website is tricked into beleiving that the person Y is actually the person X and will not issue another cookie that would overwrite the cookie B

...just switching from a World of Warcraft forum I see...

Always a bad idea to share OS logins. Sharing PCs is fine, but you definitely want unique logins for everyone. Trust me.

As for cookies, you can't use persistent cookies in this configuration because of the reasons I described. Using session cookies will not help you much either - if somebody forgets to close their browser, the next person will be able to impersonate the previous one within 20-30 minutes (lifetime of a session cookie).

Your best bet is to use unique OS logins for your staff and use their OS authentication information to log into the website as well (it will be an intranet website). There's a setting in IE that will make it transparent - the last cluster of radio buttons in the security tab.

J.D.