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.
[snip php-source]code/authhash/authhash.php[/snip]
Download the code
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.
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 …
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.
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.
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
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.
Thanks for your information.I have another doubt?
Storing session in db is fast?
http://www.w3answers.com
In most cases, storing it in a file will be faster.
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.
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.
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
I often use this method as sometimes you just can’t use sessions or cookies and the above method is the only elegant solution.
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
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.