QuickAuthPHP – One script for web authentication. Multi-user. No database required.

Goal

Sometimes you have a small web application that you want to keep private, but don't have time to implement a proper database authentication system, nor .htaccess is suitable for your needs (or you hate native browser authentication, like me). If this is true for you, QuickAuthPHP is a super fast solution.

Project website

github.com/llagerlof/QuickAuthPHP

What it does?

• Add a single login form to any webpage on your server.
• You can have multiple logins and passwords.

Goodies

• One single script easy to configure and install.
• Non obstrusive. You only need to require_once() the script in your web pages.
• No dependencies.
• No need to change HTML, Javascript or CSS in your pages.
• Secure.

What will you need?

• A working web server with PHP 5.5 or above (preferably 7.x).
• The file auth.php.

Comments

[David J Eddy]

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.

Keep posting, we only learn through doing.

[Paulo Renato]

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.

[Lawrence Lagerlof]

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.

[David J Eddy]

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.

[Lawrence Lagerlof]

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.

[Paulo Renato]

Bear in mind that what I am gonna say is not a personal attack to the developer and author of this post.

Please don't use this type of approach if you take security seriously and you don't want to have a huge GDPR fine for a data breach of your users Personal Identifiable Information(PII).

Authenticating users must be done by following OWASP recommendations.

I strongly recommend the use of OAUTH 2.0 and OpendID for authenticating a user and lots of battled tested packages exist to provide this functionality.

[Lawrence Lagerlof]

Listen to this guy.