Unique Authentication in PHP

[slarty]

I think you can use fake basic authentication in Apache to use client certificates.

That said, they are a PITA to set up, and it's difficult for nontechnical users to use them, as they have to install the keyfile etc.

Also they tend to lose them.

Slarty

[Soda_Popinsky]

The project is a content management system, and I am looking for unique ways to secure the CMS and admin sections (not by obscurity, ) . I left out the details of the project just to see what kind of ideas would pop up.

That being said, htaccess and ssl and others would be tossed out because that would not have to do with the CMS itself.

Thanks for the input everyone.

[Limpster]

Why not something simple? Such as a cookie with a password or code in it.

[Soda_Popinsky]

Because cookies are vulnerable to physical attacks and cross site scripting attacks. It's not smart to keep passwords saved.

[xmaddness]

Check out the posts I did in this thread:

http://www.antionline.com/showthread...0&pagenumber=1

It explains how to build a complete database driven PHP admin login.


xmaddness
http://www.planetmaddness.com

[HTRegz]

Hey Hey,

I may be shooting in the dark here but why not do your own CHAP implementation?

User browses to Admin Portal (preferably all over SSL)
Server Includes a 'Challenge String' on the page, along with a JS MD5 Hash Generator.
User Inputs their username into the username box and then there are two password boxes... The user inputs the 'Challenge String' in Box 1 and their password in Box 2.. a third hidden field contains their Browser Version (or some other identifying information). They click the Generate button and a hash is generated using the 'Challenge String, Password and Browser Version'. The user then hits submit and the username and hash are sent to the server. The server pulls the browser version itself (HTTP_USER_AGENT) and then pulls the password by matching the username against a local only SQL database.. It also knows the challenge string... It now hashes the Challenge String, password and Browser Version and compares the hashes... If the hashes match, the user logs in.. if they don't... they get an error..

Then use Vorlin's session suggestion to verify identity... hash the IP on every page and make sure it matches the value originally stored when the Challenge was passed... You could even include a counter table in the SQL that stores the session hashes... decrease it by one on every page load (start it at 5 or something) and every 5 pages challenge the user again with a new Challenge string..

I think that makes sense... I'm tired and just had a long day at work.

Peace,
HT

[xmaddness]

Well, as someone was so kind to point out, I missed the "Beyond password" line in your original post. (must be because of the lack of sleep and the programming I have due in the morning)

OKay, so unique ways of authentication eh?


Well, If you are running this CMS in an internal LAN, you could base it on the mac address of the boxen and use that as a token for a session, and add vorlin's md5/uniqueid combo to really mix up the session id. But as that would only be available in an internal lan, using arp etc, this would not work out over the inet.

Now, as far as over the inet is concerned, the only real way I know of doing a user authentication scheme like the one you saying is as follows:

1) a local EXE file on the users machine to execute a no-ip type of authentication.

2) Using IP address, but you are limited by dynamic ip's

3) Some other type of fancy click here and here secret society handshake type entrace to the site (although this will get very annoying after a while)

4) Using an SSL cert auth or an htaccess type deal (which most end users would probably screw up a few times before figuring it out)

5) a key swap PGP keys, public keys, private keys etc.

I do like the idea of uploading a picture or image file, reading its code, and then comparing that to a saved image in the DB. (if you used sessions, you wouldn't have to keep uploading it for each page. JUst when you login). Although again this solution takes time to upload the file, to find the file, what if i loose the file, or edit it by accident. etc etc It leaves alot of room for mistakes in uploading also. On a slower slightly worse connection you may have to upload the file several times before getting it one hundred percent intact.

On another note, you could always use $_SERVER['REMOTE_PORT'] and have the.. its late.. nevermind...

When it comes down to it, the good old user pass combo is he easiest way to go. When building a CMS you must have the end user in mind. I certainly know that the people I build CMS's for don't want to have to jump thru hoops simply to change the price of one of thier items. These days you can make some very secure logins via SSL and PHP user pass combos and a good session dance via the php.

I will keep it in the back of my mind and see if I can think of anything that is easy, fast, and secure.

Good luck mate!

xmaddness
Planet Maddness Industries
http://www.planetmaddness.com

[Soda_Popinsky]

I'm going to try and go over everyone's ideas here. I think I need to note that this will be a open source, public CMS. Which means that people using it might not have access to their server.

You could write a little algo that creates a hash out of the client's IP address - a small executable on the client's computer, for example. Upon execution of the exe, the IP is hashed and sent to the server - the server then looks at the client's (unhashed) IP and performs the same algo on it; the client's hashed IP is sent to the server and there compared to the hash the server calculated...

Why use an EXE? When the admin selects IP's to allow, they enter it into some form, and then php MD5's it and sticks it into the DB. Then when you access the admin page, your IP is hashed again by PHP enviroment variables and compared to the one in the DB, and decides to allow you or not. Maybe less complicated... and OS independent.

Soda - With your latest suggestion, would I have to upload that file every single time I reloaded the page or changed something because HTTP is stateless? What a waste of bandwidth!


I think Session ID's were created to cover this. A random session ID is generated after you login and it is generally outputted in an <INPUT TYPE="HIDDEN" NAME="sessionid" VALUE="asdlkf;lsadjfosdgoxvblkjxsm"> type tag so that when the script gets input again the sessionID is also submitted and can be looked at. I think there is some way for PHP to handle most of this, but I don't remember the code...


Anyways, if you're thinking of ways for the server to authenticate you for the first time...I don't think a lot will beat a good password. You could create a Javascript keypad to type the password in order to defeat Keyloggers that might be on a computer, but in the end you'd want to send a string that could be recreated with ease...IE at an Internet Koisk you might not be able to upload a unique image file, etc...

I like the keypad idea, not forcing the user to use it but it will at least fool some keyloggers. Session ID's should be necessary as well.

[Crazy Idea]
Ok, this is probably a little bit off the wall, but what if you were to use some sort of interactive device on the webpage like a flash or java representation of a room with a set of interactive objects. The user trying to become authenticated would perform a set of actions with the objects (a decent sized list of actions), and upon completion of the tasks it would generate a temporary cookie for the user using php, and possibly write the users IP to a temporary db of acceptable IP addresses. The IP would later be flushed in a couple hours or so unless renewed by the user. The benefit I see to this is that the actions are easier to remember than a strong password (just think off all the odd complex game secrets people remember) allowing for fairly complex sequences for ID.
[/Crazy Idea]

My Slightly Out Of Whack 2 Pesos
-AzE-

That was sortof what I was thinking about with the file upload, it allows an easy way to have a giant password, and easy to remember, but I don't think I have the time to make a Myst password system. Off the wall is good though

What about a 2step auth, based on your initial IP idea.

1. Create in some non-related "administrator centre" (simple apache pw protected) a
little interface with two options:
"activate access to the following IP:" and
"disactivate access to the following IP".
In principle, "nobody" knows what this is for.

2. In your "admin section for a project" you check the user's IP based on that above db.

- In this way, you do not have to configure step 1 often if you have a static IP.
- It's simple for people with a dynamic IP
- It's moderately secure, however somewhat improved through a "secure through obscure"-
procedure.

I may be wrong, but there's nothing really obscure about it. It's just another level of security. Htaccess is something handled by Apache, not the CMS, although I have thought of making a htaccess generator of some sort. I'd rather advise that a htaccess password is used, instead of making a generator.

You could use something similar to hash session IDs based on the IP address of the person logging in. This is used in various areas, most popular in PHPBB.

$ip = $_SERVER['REMOTE_ADDR'];
$session_id = md5(uniqid($ip)); 

Then you can update the sessions table, make sure only one login is allowed per user, and even perhaps make sure that once someone's logged in at a specific IP, they can't log in somewhere else (like phpBB allows).

Put timeout values per page, depending on risk factor...higher the risk (profile pages, updating info, sensitive areas, etc), lower the timeout so that when the refresh is detected, it grabs the local time and compares it to the time the page was initially loaded.

$existing_time = isset($existing_time) ? $existing_time : time(); // Grab the page's existing time
$now = time(); // Get the time right now in seconds
$allowed = 900; // Seconds allowed, 15 minutes

if ($now - $existing_time > $allowed) {
    // put in some redirect to a login page here
    header("Location: login.php");
} else {
    // do some cool refresh stuff here...
} 

Also, make sure that all of your pages aren't cached and don't store anything. I do this with a few things, such as the following.

At the head of each page, I have this, via a function:

        <head>
                <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
                <meta http-equiv="Pragma" content="no-cache; no-store">
                <meta http-equiv="Expires" content="-1">
        </head>

At the tail of each page, I have this, via a function:

        <head>
                <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
                <meta http-equiv="Pragma" content="no-cache; no-store">
                <meta http-equiv="Expires" content="-1">
        </head>

I do the above to make sure that IE browers don't cache things because of the weird way they do. I know I went a bit more out of authentication, but adding in some extra steps isn't a bad idea.

Ok, so that kicks ass.

How about keypair auth via a website? Simply point it to a file that contains your key, which gets uploaded to the server and validated. If it's an invalid key, no go.

By the way, this isn't some lame attempt at security through obscurity is it?

I like the idea, but wouldn't want it to depend on something extra to be installed on the server, like gnupg, because I'm not expecting all the users of the CMS to have admin on their server. Could probably still work though.

Originally posted here by SittingDuck
Have you considered the idea of using client side certificates? I assume that you are running your admin area over and an SSL connection.

With client side certificates in place any user with one, would not even get the web page as the ssl connection would be dropped.

While this not a solution that can be implemented in PHP (I think correct me if I wrong), it is a very good idea to sites that require a high level of security, however a user name a password still needs to be implemented as well.

SittingDuck

Depends if SSL is installed, right?

Originally posted here by slarty
I think you can use fake basic authentication in Apache to use client certificates.

That said, they are a PITA to set up, and it's difficult for nontechnical users to use them, as they have to install the keyfile etc.

Also they tend to lose them.

Slarty

I hope to keep the install easy and simple

Originally posted here by HTRegz
Hey Hey,

I may be shooting in the dark here but why not do your own CHAP implementation?

User browses to Admin Portal (preferably all over SSL)
Server Includes a 'Challenge String' on the page, along with a JS MD5 Hash Generator.
User Inputs their username into the username box and then there are two password boxes... The user inputs the 'Challenge String' in Box 1 and their password in Box 2.. a third hidden field contains their Browser Version (or some other identifying information). They click the Generate button and a hash is generated using the 'Challenge String, Password and Browser Version'. The user then hits submit and the username and hash are sent to the server. The server pulls the browser version itself (HTTP_USER_AGENT) and then pulls the password by matching the username against a local only SQL database.. It also knows the challenge string... It now hashes the Challenge String, password and Browser Version and compares the hashes... If the hashes match, the user logs in.. if they don't... they get an error..

Then use Vorlin's session suggestion to verify identity... hash the IP on every page and make sure it matches the value originally stored when the Challenge was passed... You could even include a counter table in the SQL that stores the session hashes... decrease it by one on every page load (start it at 5 or something) and every 5 pages challenge the user again with a new Challenge string..

I think that makes sense... I'm tired and just had a long day at work.

Peace,
HT

Doing the hash locally would save the server a lil' effort, but because SSL might not be possible, would it be preferred?
Keypairs are sounding pretty good about now.

1) a local EXE file on the users machine to execute a no-ip type of authentication.

2) Using IP address, but you are limited by dynamic ip's

3) Some other type of fancy click here and here secret society handshake type entrace to the site (although this will get very annoying after a while)

4) Using an SSL cert auth or an htaccess type deal (which most end users would probably screw up a few times before figuring it out)

5) a key swap PGP keys, public keys, private keys etc.

I do like the idea of uploading a picture or image file, reading its code, and then comparing that to a saved image in the DB. (if you used sessions, you wouldn't have to keep uploading it for each page. JUst when you login). Although again this solution takes time to upload the file, to find the file, what if i loose the file, or edit it by accident. etc etc It leaves alot of room for mistakes in uploading also. On a slower slightly worse connection you may have to upload the file several times before getting it one hundred percent intact.

On another note, you could always use $_SERVER['REMOTE_PORT'] and have the.. its late.. nevermind...

When it comes down to it, the good old user pass combo is he easiest way to go. When building a CMS you must have the end user in mind. I certainly know that the people I build CMS's for don't want to have to jump thru hoops simply to change the price of one of thier items. These days you can make some very secure logins via SSL and PHP user pass combos and a good session dance via the php.

I will keep it in the back of my mind and see if I can think of anything that is easy, fast, and secure.

Good luck mate!

xmaddness
Planet Maddness Industries
http://www.planetmaddness.com

Again with the keypairs, which is still sounding good. But again with the .htaccess, which is preferred but I don't want to have to rely on it for the security of the CMS, plus I would prefer cross server, platform, yadda yadda.

Thanks a bunch for the ideas, keep em coming if you're willing!

[sec_ware]

What about a 2step auth, based on your initial IP idea.

1. Create in some non-related "administrator centre" (simple apache pw protected) a
little interface with two options:
"activate access to the following IP:" and
"disactivate access to the following IP".
In principle, "nobody" knows what this is for.

2. In your "admin section for a project" you check the user's IP based on that above db.

- In this way, you do not have to configure step 1 often if you have a static IP.
- It's simple for people with a dynamic IP
- It's moderately secure, however somewhat improved through a "secure through obscure"-
procedure.

I may be wrong, but there's nothing really obscure about it. It's just another level of security. Htaccess is something handled by Apache, not the CMS, although I have thought of making a htaccess generator of some sort. I'd rather advise that a htaccess password is used, instead of making a generator.

sorry, when I pick up that one again - in principle, the first step can be "secured" as hard
as one wish, using for example the other ideas presented here. The advantage however is,
that with a fixed IP, you don't have to do step 1 always - saving bandwidth, CPU time etc
(depending on nr of users and/or encryption-algorithms, ...).

Just make sure, that your fix IP always is your fix IP ...

[SittingDuck]

Depends if SSL is installed, right?

If you are running any kind of admin section, all the traffic to that area should be done over ssl, you never know who might be listening .

<quote>

How about keypair auth via a website? Simply point it to a file that contains your key, which gets uploaded to the server and validated. If it's an invalid key, no go.

By the way, this isn't some lame attempt at security through obscurity is it? </quote>

I like the idea, but wouldn't want it to depend on something extra to be installed on the server, like gnupg, because I'm not expecting all the users of the CMS to have admin on their server. Could probably still work though

That is how ssl client side certificate authentication works .

All in all after read this thread, form based authentication, with user names and passwords would still be best and probably you’re most secure option. Having said that is does rely on the auth being set up correctly.
i.e. the use of strong passwords,
not giving and information away in error messages (One static message is the best way to go),
account timeout for wrong attempts ( not account lock out, as it can be used as a DOS attack),
correctly validating all data sent from the client (not going to go into that or I will be here all day),
Storing all information about the client, like who they are and what rights they have etc in session scope variables.
etc, etc

let us know how you get on Soda_Popinsky.

SittingDuck