Creating a secure login script in PHP and MySQL without HTTPS

Question

Question

Is this post on WikiHow a good reference to create a secure login script in PHP and MySQL? In the warnings section, the author(s) emphasizes that the code only can be used with HTTPS. I am not able to use HTTPS, but need to implement a relatively secure login script in PHP and MySQL, and was therefore wondering if the script could be implemented for an HTTP connection as well.

Solved

A third party solution is the best solution to create a secure login script in PHP and MySQL. By utilizing a PHP framework (e.g. Symfony, uLogin) or external parties (e.g. Facebook, Google), the need to create an entirely new working login script plus authorization (the Remember-Me functionality) can be avoided. If others have done thorough research and gained experience to create login functionalities, it is much safer and easier to use their work.

Answer 1

Although you could create a login system yourself, it is strongly recommended to let external parties do it for you.

It takes a lot of experience to get it right, and it is so often done wrong.

Although the tutorial looks okay to me, there are just so many factors that to consider, and it also seems to be semi-old. PHP 5.5 offers password_hash and password_verify, which I would recommend over what your page suggests.

So if you have to make your own system; consider making use of the above-mentioned functions, if you're restricted to lower php versions, there are backports up to version 5.3.7 available.

If you don't have to make your own system, make use of external parties (Google, Facebook) to handle the logging in for you, or make use of a framework that has authentication support.

So in the general gist of it: Don't try to do it yourself, make use of what other people offer which years of experience in it. As it is incredibly difficult to get it right.

Answer 2

This script securely encrypts the user's entered password in their browser and clears the plaintext password field prior to the form's submission, so the password can't be read by any third-party. To that extent, the script can be used safely over HTTP.

However, the rest of the form's data - user's name, email address, etc. - is not sent securely, so a third-party (e.g. man in the middle) could identify the user just by reading his/her (non-encrypted) personally-identifiable information being sent by the form. Not only does this leave your users vulnerable, but insecure handling of users data can leave your employer/client open to legal risk in case the data is ever sniffed/hacked/stolen.

There's also the real risk that a man-in-the-middle could intercept the transmitted data and modify it undetected before it's received by the server hosting your script. HTTPS/SSL not only protects passwords but also ensures that no data is tampered with.

As Zarthus mentioned, best course of action is to go with a third-party solution, especially if you can't offer HTTPS for yours.