Printable View
I am writing an admin section for a project I am working on...
I was just wondering if anyone can think of unique ways to authenticate someone in PHP? I am trying to think past the password.
Ideas I have include requiring having a certain IP to enter an admin section, but my creativity is limited by my knowledge of PHP. I'm hoping others have possibly ran into some creative ways a user can authenticate themselves over the web (w/o hardware or secure ID's or the like)
Thanks!
IP wouldn't really work well because not everyone has a static IP but I like how you're thinking outside the box. I'll be checking back every now and then to see the great ideas.
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...
This way, it wouldn't matter what the client's IP is... al that matters is that the client has the exe to calculate the hash - kinda the same way MD5- or SHA verification works, only the other way around...
Might not be completely secure, though, since everything would depend on the safe-keeping of the exe.
Just something that popped up in my brain :D
Maybe using a file as a key would be just as effective? Upload a .jpg, php md5's the file, compares it to md5 in the db? It would defeat a dictionary attack, no rainbow table would find the password (file)...
Although you would have to make sure someone doesn't upload a .iso and hog the server...
hmm...
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...
[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-
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.
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.
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).PHP Code:$ip = $_SERVER['REMOTE_ADDR'];
$session_id = md5(uniqid($ip));
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.
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.PHP Code:$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...
}
At the head of each page, I have this, via a function:
At the tail of each page, I have this, via a function:Code:<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.Code:<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>
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?
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
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
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.
Why not something simple? Such as a cookie with a password or code in it.
Because cookies are vulnerable to physical attacks and cross site scripting attacks. It's not smart to keep passwords saved.
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
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
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
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.
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.Quote:
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...
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.Quote:
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 &lt;INPUT TYPE="HIDDEN" NAME="sessionid" VALUE="asdlkf;lsadjfosdgoxvblkjxsm"&gt; 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...
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 ;)Quote:
[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-
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.Quote:
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.
Ok, so that kicks ass.Quote:
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.
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).PHP Code:$ip = $_SERVER['REMOTE_ADDR'];
$session_id = md5(uniqid($ip));
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.
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.PHP Code:$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 &gt; $allowed) {
// put in some redirect to a login page here
header("Location: login.php");
} else {
// do some cool refresh stuff here...
}
At the head of each page, I have this, via a function:
At the tail of each page, I have this, via a function:Code:&lt;head&gt;
&lt;meta http-equiv="Content-Type" content="text/html; charset=utf-8"&gt;
&lt;meta http-equiv="Pragma" content="no-cache; no-store"&gt;
&lt;meta http-equiv="Expires" content="-1"&gt;
&lt;/head&gt;
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.Code:&lt;head&gt;
&lt;meta http-equiv="Content-Type" content="text/html; charset=utf-8"&gt;
&lt;meta http-equiv="Pragma" content="no-cache; no-store"&gt;
&lt;meta http-equiv="Expires" content="-1"&gt;
&lt;/head&gt;
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.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?
Depends if SSL is installed, right?Quote:
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
I hope to keep the install easy and simpleQuote:
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
Doing the hash locally would save the server a lil' effort, but because SSL might not be possible, would it be preferred?Quote:
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
Keypairs are sounding pretty good about now.
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.Quote:
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
Thanks a bunch for the ideas, keep em coming if you're willing!
sorry, when I pick up that one again - in principle, the first step can be "secured" as hardQuote:
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.Quote:
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.
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 ... :D
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:
Depends if SSL is installed, right?
That is how ssl client side certificate authentication works :).Quote:
<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
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
Indeed...Quote:
Originally posted here by SittingDuck
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 ;).
Perhaps I wasn't clear. I meant an HTML form, with a PHP backend which does the key processing. The key could be arbitrarily generated.Quote:
That is how ssl client side certificate authentication works :).
I agree with chsh about the key auth. I'd also limit who can access that part of the website via standard access controls limiting the requests to specific machines.