PHP login session

Hello guys, just starting to get my hands wet on PHP.

Here's my question, after user authentication I want to redirect it to a page. Redirection works without any issue.

I'm just wondering what if the user bookmark the URL, how do I check whether the user has login or the session is still active?

How to create a URL with a PHP session? Is it safe?

Thanks for any ideas.

If the user bookmarks the page, and the page does not authenticate them itself, they will get it next time just for the asking.

Oddly enough, I saw this article earlier today, and was able to find it again. Read Tip #3, it is right on topic.

Whatever form of authentication you use, each protected page must authenticate the user on each request.

Typically, you would set a token (cookie) on the client upon successful login. Each successive page request would then validate that the token is received and that it is valid before delivering the content. The token must be secure against being forged or reused at a later time.

Hi Astrogeek, thank you so much for your reply.

I actually haven't start coding and not yet familiar with PHP, it just cross my mind. So before I delve into it I tried to think all possibilities that might happen.

Cookie is one thing but cookie can easily be tampered, i'm looking into sessions and putting it to URL.

Sessions always change but i'm not sure how to do it or if it is secure.

I read somewhere also about session fixation.

A beautiful world of programming with a lot of nastiness around it.

I suggest that you "surf" a number of topics before you dive into the PHP (or, any specific) language. For instance, be sure that you understand how logins are handled ... how cookies are set and retrieved ... how redirects work, and that you know that a redirect-response won't at the same time set a cookie.

There is a tremendous amount of material out there on these subjects. Most of them are specific to one programming-language or another, on the client-side or the host-side or both, but the concepts are fundamental and therefore universal.

Approach your learning this way: "first, understand exactly what you want the computer to do, and exactly how it will all work out between the two computers in all the possible situations." And, "be sure that you understand the situations clearly." Then, and only then, start thinking about <<PHP|Ruby|Perl|...>>. Because these are only various tools for the implementation of it.

Finally: also remember that most languages have rich libraries of "contributed code" which may allow you to "grab 80% of the solution to 'your' problem off the shelf," so that you can actually focus on "the other 20% that is actually particular to 'your' problem! The proverbial "80/20 Rule" is very significant here.

Actum Ne Agas: Do Not Do A Thing Already Done.™

Alternatively, you can prowl around the source-code of their "off-the-shelf solution" and see for yourself how it works ... knowing that it does. Hey, why build it from scratch when you can steal it?

Cookies are the usual way. But they need to be a randomly selected cookie and you need to store it on your side and look it up when someone comes back and submits the cookie to you. In other words, you don't make the cookie contain all the information for login.

Originally Posted by sundialsvcs I suggest that you "surf" a number of topics before you dive into the PHP (or, any specific) language. For instance, be sure that you understand how logins are handled ... how cookies are set and retrieved ... how redirects work, and that you know that a redirect-response won't at the same time set a cookie. There is a tremendous amount of material out there on these subjects. Most of them are specific to one programming-language or another, on the client-side or the host-side or both, but the concepts are fundamental and therefore universal. Approach your learning this way: "first, understand exactly what you want the computer to do, and exactly how it will all work out between the two computers in all the possible situations." And, "be sure that you understand the situations clearly." Then, and only then, start thinking about <<PHP|Ruby|Perl|...>>. Because these are only various tools for the implementation of it. Finally: also remember that most languages have rich libraries of "contributed code" which may allow you to "grab 80% of the solution to 'your' problem off the shelf," so that you can actually focus on "the other 20% that is actually particular to 'your' problem! The proverbial "80/20 Rule" is very significant here. Alternatively, you can prowl around the source-code of their "off-the-shelf solution" and see for yourself how it works ... knowing that it does. Hey, why build it from scratch when you can steal it?

Hi Sundialsvcs, to be honest I'm not starting from scratch. Yes, there's ton of examples in PowerPoint, PDF and some other formats.

I've seen that Symfony, Laravel, Yii and other framework can do it. I will be hosting the PHP program on Raspberry Pi, if it's quite loaded with framework it may not have a good performance.

I'm trying to see whether some pure PHP solution can do the job.

Thanks for your reply, good insight. Cheers!

Originally Posted by Laserbeak Cookies are the usual way. But they need to be a randomly selected cookie and you need to store it on your side and look it up when someone comes back and submits the cookie to you. In other words, you don't make the cookie contain all the information for login.

Thanks Laserbreak, I will do some test with Cookie and Sessions.

Agree with you, Cookie should be the simple way.

Originally Posted by JJJCR Thanks Laserbreak, I will do some test with Cookie and Sessions. Agree with you, Cookie should be the simple way.

Be sure to understand "what" the cookie is in this scheme of things and what properties it must have in order to do the job. Avoid thinking that the cookie is the important thing - it is not. A cookie, or a URL encoded with a session identifier, or a shared secret can all perform the same job, and all must be verified as non-fake on each use. All are only tokens which represent something else. The important thing is that the information they carry cannot be counterfeited and is verifiable on each use.

Always remember, the cookie or other token that comes from the client can be trivially faked - never trust them! If you send a cookie which says "logged-in" and accept that as proof, then all a cracker must do is send you a cookie which says "logged-in" and you cannot tell the difference!

On the other hand, if you send a cookie with a long and unique identifier which you also record in your private notebook, then when a visitor gives the cookie back to you, you only accept it if it is listed in your notebook! That is one mechanism which can make them un-fakeable. The same mechanism applies to cookies and session encoded URLs.

As sundialsvcs pointed out, first learn "what" is required, and only then think about "how" to do that using some mechanism such as a cookie or a session encoded URL... then write code.

Good luck!

Originally Posted by astrogeek Be sure to understand "what" the cookie is in this scheme of things and what properties it must have in order to do the job. Avoid thinking that the cookie is the important thing - it is not. A cookie, or a URL encoded with a session identifier, or a shared secret can all perform the same job, and all must be verified as non-fake on each use. All are only tokens which represent something else. The important thing is that the information they carry cannot be counterfeited and is verifiable on each use. Always remember, the cookie or other token that comes from the client can be trivially faked - never trust them! If you send a cookie which says "logged-in" and accept that as proof, then all a cracker must do is send you a cookie which says "logged-in" and you cannot tell the difference! On the other hand, if you send a cookie with a long and unique identifier which you also record in your private notebook, then when a visitor gives the cookie back to you, you only accept it if it is listed in your notebook! That is one mechanism which can make them un-fakeable. The same mechanism applies to cookies and session encoded URLs. As sundialsvcs pointed out, first learn "what" is required, and only then think about "how" to do that using some mechanism such as a cookie or a session encoded URL... then write code. Good luck!

Thanks, Astrogeek. I will keep that on mind. I will do a simple cookie first, then I will code all the functionality. If everything works fine, then I will go back on how to secure the mechanism of authentication. Anyway, first roll-out will just be on the local network.

Cookie with the PHP session-id for the mean time but it's not enough I know, hashing will be more secure.

My head is on the water right now, but still breathing fine. Thank you guys for all your insights.

Conceptually, the cookie is just a "nonce" – it could be a UUID, say – which leads you to your session-table. (Be sure to use parameters in your SQL query since a common trick is to embed a Bobby Tables attack in the session-cookie value!) You should record other supporting information such as the IP-address of the client and check for agreement. All server-side information is stored in the session-data referenced by the session-token; none is provided by the client. The client is never trustworthy.

But once again: "canned, off the shelf session-handlers" are very readily available.

Originally Posted by sundialsvcs Conceptually, the cookie is just a "nonce" – it could be a UUID, say – which leads you to your session-table. (Be sure to use parameters in your SQL query since a common trick is to embed a Bobby Tables attack in the session-cookie value!) You should record other supporting information such as the IP-address of the client and check for agreement. All server-side information is stored in the session-data referenced by the session-token; none is provided by the client. The client is never trustworthy. But once again: "canned, off the shelf session-handlers" are very readily available.

Wow, thanks for the ideas. This is gonna be exciting. The project actually also includes a hardware interface, I initially thought that this project would be a piece of cake but I slowly get into the details. I realize that I'm getting into trouble.

I repeat: there are a wide variety of "frameworks" for PHP and for every other imaginable programming language. They are not "all like WordPress!" Some simply provide the basic pieces of "what any and every web server-side application needs," specifically including session-handling and a variety of defensive measures. Don't bother to do what has already been done.

Originally Posted by sundialsvcs I repeat: there are a wide variety of "frameworks" for PHP and for every other imaginable programming language. They are not "all like WordPress!" Some simply provide the basic pieces of "what any and every web server-side application needs," specifically including session-handling and a variety of defensive measures. Don't bother to do what has already been done.

Thanks Sundialsvcs, I keep trawling the web there are actually examples on how to do this without any framework.

Framework is really good but I won't be able to fully utilize the whole framework. So, I will do it with PHP and MySQL together to check and secure session authentication.

Have you considered apache mod_auth? The security will only persist for the life of the browser session. Bookmarking a page, then closing the browser, then using the bookmark later will require re-login.

One has to manage maintaining the AuthUserFile of users and passwords, but can presume in PHP (or other cgi) code that anyone who is there has been authenticated. The apache auth works at the directory level and can be done using .htaccess files if you don't have access to httpd.conf

Thoughts?

Originally Posted by scasey Have you considered apache mod_auth? The security will only persist for the life of the browser session. Bookmarking a page, then closing the browser, then using the bookmark later will require re-login. One has to manage maintaining the AuthUserFile of users and passwords, but can presume in PHP (or other cgi) code that anyone who is there has been authenticated. The apache auth works at the directory level and can be done using .htaccess files if you don't have access to httpd.conf Thoughts?

Thanks for the idea, I think it makes sense to use Apache since the site is hosted by Apache anyway.


I will check on this, thanks again. Cheers!