Interesting little project Lawrence! I am a fan of quick solutions for quick projects. So this looks interesting. Nice README as well.
A couple of items I would like to point out to really bring the tool up to par:
5.5 is EOL, 5.6 EOL's within 90 days. Please do not support EOL versions. While it might work, active support for dead version is counter to best practice.
Composer is the PHP's eco-systems package manager, might want to consider adding your class as a PHP package to elevate it's visibility within the community.
Form data handling is whole inadequate; I did not see one line of logic validating the $_POST data before processing.
I like the concept but it needs some work before being ready for public consumption. If you would like some pointers feel free to DM me.
I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
I agree in learning by doing and I am advocate of doing so, but not to publish my learning as stuff ready for production use.
This is a very nice code exercise to help the developer understanding the very basics of authentication, but should never be used in production, neither present as a secure solution to be used.
Regarding the code it can be reviewed to improve the developer understanding on the PHP language. We can help with that by open issues pointing out where the code can be improved.
I am open to help in review the code but only if the Readme clear states that the project is not suitable for production use.
I like Composer but I don't think this little project should be added to big projects as a default solution. The main goal of this is to provide a fast, temporary solution until the dev implements a proper authentication system, if he wants to.
My use case is: I have some little personal projects that I added to my public web server, but I don't want to leave it open to everyone, nor implement an authentication system for every little project or page I put online. So I came up with this generic and small solution.
So, about supporting 5.5, I agreed completely with you. It's old and unsecure, but I want to allow the users still using 5.5 to use this project. This works in 7, though.
About the validation, you are right. I did not added any input validation on purpose because I do not check it against a database, so no sql injection. I don't write any data to any file. On authentication I just write the username to the session if the password match. So, if you could tell me about the existence of any other point of failure, I can improve this code. Thank you.
ps. I should limit the username and password size, at least! I will do it. Done.
Regarding Composer, your view is understandable. I can understand the need to have a stand-in solution until a solution is implemented.
For you use case the stated use case that makes sense.
Per support of 5.5, if we (class / package providers) do not provide motivation to our users to upgrade; who will? Project Managers? Sales? Marketing? IMO, the role of technologist evangelist is squarely in the realm of the owner of the logic.
Not validating user input opens a large risk to RCE (remote code execution). Passing logic to the server via the form field. When the interpreter process the value the value is code, so the interpreter executes it. A basic step would be to us PHP's filter input function (php.net/manual/en/function.filter-...) as a start.
I am aware of RCE. Most these types of attack relies in exec() or eval(). RCE could be done in case of buffer overflow, however this type of exploitation take advantage of bugs in functions that manipulate strings, like crypt() or serialize(). It's valid to mention that this script doesn't perform any string manipulation except hashing the user input password.
So, about the security issues, If an old version of PHP (like 5.5) is used, it's security problems could be exploited to do a buffer overflow attack, or some kind of session attack.
Well, your insights really helped me. If I want to support 5.5, I should minimize the possible attacks that could be made. I will Now the script validates the username and password to only accept ASCII printable characters.
I want to state that I am relying totally in the PHP's capacity to protect his own session data, so any ideas to improve this script, without forgetting it's main goal, are welcome.
Thanks David.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting little project Lawrence! I am a fan of quick solutions for quick projects. So this looks interesting. Nice README as well.
A couple of items I would like to point out to really bring the tool up to par:
I like the concept but it needs some work before being ready for public consumption. If you would like some pointers feel free to DM me.
Keep posting, we only learn through doing.
I agree in learning by doing and I am advocate of doing so, but not to publish my learning as stuff ready for production use.
This is a very nice code exercise to help the developer understanding the very basics of authentication, but should never be used in production, neither present as a secure solution to be used.
Regarding the code it can be reviewed to improve the developer understanding on the PHP language. We can help with that by open issues pointing out where the code can be improved.
I am open to help in review the code but only if the Readme clear states that the project is not suitable for production use.
Hi David!
I like Composer but I don't think this little project should be added to big projects as a default solution. The main goal of this is to provide a fast, temporary solution until the dev implements a proper authentication system, if he wants to.
My use case is: I have some little personal projects that I added to my public web server, but I don't want to leave it open to everyone, nor implement an authentication system for every little project or page I put online. So I came up with this generic and small solution.
So, about supporting 5.5, I agreed completely with you. It's old and unsecure, but I want to allow the users still using 5.5 to use this project. This works in 7, though.
About the validation, you are right. I did not added any input validation on purpose because I do not check it against a database, so no sql injection. I don't write any data to any file. On authentication I just write the username to the session if the password match. So, if you could tell me about the existence of any other point of failure, I can improve this code. Thank you.
ps.
I should limit the username and password size, at least! I will do it.Done.Regarding Composer, your view is understandable. I can understand the need to have a stand-in solution until a solution is implemented.
For you use case the stated use case that makes sense.
Per support of 5.5, if we (class / package providers) do not provide motivation to our users to upgrade; who will? Project Managers? Sales? Marketing? IMO, the role of technologist evangelist is squarely in the realm of the owner of the logic.
Also, stats say what you want them to. seld.be/notes/php-versions-stats-2... (PHP 5 < 22%).
Not validating user input opens a large risk to RCE (remote code execution). Passing logic to the server via the form field. When the interpreter process the value the value is code, so the interpreter executes it. A basic step would be to us PHP's filter input function (php.net/manual/en/function.filter-...) as a start.
I am aware of RCE. Most these types of attack relies in exec() or eval(). RCE could be done in case of buffer overflow, however this type of exploitation take advantage of bugs in functions that manipulate strings, like crypt() or serialize(). It's valid to mention that this script doesn't perform any string manipulation except hashing the user input password.
So, about the security issues, If an old version of PHP (like 5.5) is used, it's security problems could be exploited to do a buffer overflow attack, or some kind of session attack.
Well, your insights really helped me. If I want to support 5.5, I should minimize the possible attacks that could be made.
I willNow the script validates the username and password to only accept ASCII printable characters.I want to state that I am relying totally in the PHP's capacity to protect his own session data, so any ideas to improve this script, without forgetting it's main goal, are welcome.
Thanks David.