Authentication without sessions in PHP

by Arnold Daniels on 03/4/2008

The normal way to save a state, like the fact that a user is logged in, is to use sessions. Session work really nice, you can save all kind of data on the server (in a temp file) which is identified by a hash which is known on the client in a cookie or by url rewriting.

However if you only need to save a small bit of login info, like a username and timestamp, using sessions is a bit of an overkill. Also, if your system would grow beyond to a size where you need load balancing over multiple servers, having a solution with sessions would be somewhat of a burden. You would need to store them in a centralized place, like a DB server.

Another way to do this, is to create an authentication hash. The idea is fairly simple: Join the information you want to known into a single string and append an md5 key of all the info + a secret word. On each request, check if the hash is available and correct, otherwise redirect the user to a login form. You can use the hash the same way PHP uses the session hash, using cookies or URL rewriting.

Arnold Daniels

I've spend a big part of my life behind a computer, learning about databases (MySQL), programming (PHP) and system administration (Linux). Currently I playing with HTML5, jquery and node.js.

E-mailTwitterLinkedInGithubGittip

There are 18 comments in this article:

  1. 5 March 2008Loïc Hoguin says:

    Like sessions, this is fine as long as you add more security to it. You have to make sure that the browser that logged in your system is the one using the session, by checking the IP adress or other things.

    Otherwise just getting the authentification string will be enough to log into another person’s account.

    ReplyReply
  2. 5 March 2008Fabian says:

    That’s a really nice solution! I just thought about using asymmetric cryptography instead of the MD5 sum to secure the information – but I can’t really see an advantage …

    ReplyReply
  3. 6 March 2008DH says:

    Why bother with asymmetric? Won’t the encryption and decryption be by the same entity, the server?

    Hashing like this is useful to verify something but you don’t mind the user seeing all the non-obvious information, such as their own username.

    But if you want to transfer something secret from one web page to another without the user knowing what it is, you’ll need to either store it and transfer some sort of reference (like an ID), or else you can encrypt the secret with a symmetric key derived from, say, the user’s password salt value.

    ReplyReply
  4. 6 March 2008Arnold Daniels says:

    The rot13 doesn’t give any real protection. It’s only a bit of obfuscation for the hash. Using a user id is more logical. This is just an example, not the code I actually use.
    ;)

    And yes, with this the user can see the data. It is not encrypted.

    ReplyReply
  5. 6 March 2008kate says:

    Do you mean that we can store sessions in database? waht is the advantage of this ,instead of storing in files.db also will take time to load.But i think for the security issues db is good.but not sure.please clear my doubts.
    http://www.w3answers.com

    ReplyReply
  6. 6 March 2008Arnold Daniels says:

    Yes, you can save session data in the DB. Have a look at this article: http://www.devshed.com/c/a/PHP/Storing-PHP-Sessions-in-a-Database/.

    You can use it if your site is so popular that it needs multiple webservers with load balancing. The session data should be known on each of the servers.

    I don’t see any security advantages. If someone has access to read the session file, he can probably also the configuration file of your webapp with the mysql password. If you have users other than you on the system and worry they might fish a session file out of /tmp, you can create a /session dir and make it only readable for www-data.

    ReplyReply
  7. 6 March 2008kate says:

    Thanks for your information.I have another doubt?
    Storing session in db is fast?
    http://www.w3answers.com

    ReplyReply
  8. 6 March 2008Arnold Daniels says:

    In most cases, storing it in a file will be faster.

    ReplyReply
  9. 13 March 2008David Branco says:

    For security reasons I wouldn’t support authentication via a GET or POST methoud. These can easly be shared and often lead to a feeling of false-security. As stated above, limiting the session by IP will help dramaticly; however, I am also aware that many companys run a single building consisting of several hundred computers throught the same Internet Protocall Address.

    ReplyReply
  10. 13 March 2008Arnold Daniels says:

    You can save if it in a cookie if you prefer. However I don’t think it’s false security. If you don’t have the hash, you can’t get it in. If a user copies and pastes the hash, it’s a different story.

    The exact same goes however for session ids. If you don’t like putting session ids in URLs, don’t put the hash in an URL but put it in a cookie instead.

    ReplyReply
  11. 14 March 2008ThanosEA says:

    Hi

    I try to use the new version of teleport for my website but when I test, firebug give this error ‘jpf is not define’.

    When I compare with my old version I can’t find the initialisation of jpf as Kernel (Kernel =)

    Anyone could help me ?

    CU

    ReplyReply
  12. 2 April 2008PHP Encoder says:

    I often use this method as sometimes you just can’t use sessions or cookies and the above method is the only elegant solution.

    ReplyReply
  13. 21 July 2009ccapela says:

    Hi Arnold Daniels

    Can you explain me please, this instruction in your code above?

    $logged_in = md5($username . $time . $secretword) === $authhash && $time >= time() – 3000;

    Thanks in advance,
    ccapela

    ReplyReply
  14. 22 July 2009Arnold Daniels says:

    ccapela,

    The code does 2 things:
    1.) Check if $authhash is valid, by doing the same operation as done when creating the hash on line 20.
    2.) Check the timestamp to see if the hash was created less than 50 minutes ago. This means that there is a 50 minute time out.

    ReplyReply

Write a comment: