Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Unique Authentication in PHP

  1. #1

    Unique Authentication in PHP

    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)


  2. #2
    Join Date
    Sep 2004
    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.

  3. #3
    Join Date
    Aug 2001
    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

  4. #4
    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...


  5. #5
    Senior Member
    Join Date
    Oct 2001
    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...

  6. #6
    Join Date
    Jul 2003
    [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

  7. #7
    Senior Member
    Join Date
    Mar 2004
    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"-
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  8. #8
    PHP/PostgreSQL guy
    Join Date
    Dec 2001
    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.

    PHP Code:
    $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.

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

    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:
                    <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">
    At the tail of each page, I have this, via a function:
                    <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">
    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.
    We the willing, led by the unknowing, have been doing the impossible for the ungrateful. We have done so much with so little for so long that we are now qualified to do just about anything with almost nothing.

  9. #9
    Senior Member
    Join Date
    Nov 2001
    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?
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  10. #10
    Senior Member
    Join Date
    Oct 2002
    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.

    I\'m a SittingDuck, but the question is \"Is your web app a Sitting Duck?\"

Posting Permissions

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