PHP Secure Login Tips And Tricks

Every website on the internet faces a similar threat, hackers. Every single website can be a target of a hacker if security measures aren't implemented properly especially when it comes to login pages where our most sensitive data are being held. Hence, there is a need to better understand how well your login page has been implemented to be considered as really secure. In this article, you will get a list of PHP secure login tips and tricks that will definitely help you decide on your secure rating of your login page.

Length Of your username and password

Both your username and password should be at least 6-8 characters long. A longer combination of username or password will make brute force attack or any other password cracking algorithm longer to crack. This can really help your network administrator to detect an attack before the attack penetrates through your login page.

Encrypt your password

We all know that encryption is necessary in term of any password. But i would still like to stress such importance. We are very dependent on encryption algorithms such as MD5 or SHA-1. However, these two algorithms are no longer that secure as compared to the older days. On Wednesday, February 16, 2005 SHA-1 has been broken by three china researchers. Although it is more towards collision attack rather than pre-image one we can assure one thing is that SHA-1 can be broken. You can read more about it on Bruce Schneier article. On the other hand, you can find MANY MD5 cracker online nowadays through Google. eg. md5crack.com. But similarly they are all collision attacks.  Wiki explains MD5 vulnerability in a way you will be discouraged from using it. It is time to encrypt your users password using SHA-2 such as sha256, sha384, sha512 or better. If you are using PHP 5.12 or above, there is a new function, hash that supports SHA-2.

17 thoughts on “PHP Secure Login Tips And Tricks

  1. You wrote:
    $hashed_password = HashMe($password, $salt);
    $sqlquery = 'INSERT INTO `usertable` ("username", "password", "salt") VALUES ("'.$username.'", "'.$password.'", "'.$salt.'") WHERE 1';

    is that ok? or rather should be:

    $sqlquery = 'INSERT INTO `usertable` ("username", "password", "salt") VALUES ("'.$username.'", "'.$hashed_password.'", "'.$salt.'") WHERE 1';

  2. Hi Clay,
    i think the code in "Utilize IP" sections is overdone. All the $_SERVER['HTTP_*'] variables is ok, but the port checking is not good. If the user has no proxy, the @fsockopen() will be called EVERY request. That is not accecptable.
    Maybe checking with @fsockopen() on _first_ request and only if remote port is in_array($_SERVER['REMOTE_PORT'],..).
    And i do not think simply keeping proxy users from my site is the right aim.
    I need to go over a proxy too sometimes and many AOL users (and from other ISPs) have a proxy in front of them they dont know.
    Not letting them on my site would be false.

    Regards, Julius.

  3. Hi Julius,
    the aim of using IP is to strengthen your login system. I agree with you that everyone who has a valid username and password should be able to access the system. The aim of that code will only run if an IP address was not detected, so it won't keep running upon every request. Actually, i think i left that bit out. Just to add to the point where Julius has mention, for proxy users it is hard to block them since it will mean blocking all users of a proxy server. Furthermore, for company users who shared the same IP address, blocking that IP might also mean blocking the whole building. But it really depend on how security paranoid are you. However, using IP together with session can still help ensure the right users who are logging in. And Cookies should also be used together to prevent session hijack and CSRF(ah! i forget this one too)

    hi fefe?
    auto logout if idle for 15minutes is excellent protection against CSRF attacks. (forgot about this too!)

    Clay

  4. If there is no ssl possible for whatever reason, you can use javascript to encrypt the password with SHA 512 or SHA 256 so you do not have to send plain login data in most cases over the net.

    If Javascript is not available you can still fall back nicely to "normal login".

  5. Hi Clay,

    thanks for the tutorial. I ever used md5() and will now change to hash().

    Can you check your example code with the insert statement again?
    I was wondering what construct $password$hashed_password would be. A php or mysql feature i have missed? Then i read the comments and got an idea.

    You have changed the code example and the editor inserted the tag, right?

    First i thought, it could be a feature of mysql to parse out this tag and its value within a select statement, then i realized, that it would stand in php context, not in mysql insert context...

    greets
    matthew

  6. ah! Yes Matt! It was meant to have deleted slash on the $password but the program parse the whole tag out instead. Let me change that! Thanks 🙂

  7. I would suggest a better method would be to completely block the account for a user if there are 3 failures regardless of the period of time.

    Granted numerous failed attempts over a short period of time (talking seconds here) could be a bot but really... makes no difference, just block the -beep- account and be done with it.

    Leave it to the user to contact you to confirm they are who they say they are to reopen it, but remember to send an email to alert the user to there account being blocked due to multiple failed logins.

  8. @Les: You can do that, definitely. But it really depends on how critical your website security required to be. A social site will not required such paranoid action while a bank site portal will definitely needs this. Nonetheless, its a individual decision. Like @Julius mentioned in the comment you might just be blocking an entire proxy users if not careful.

  9. @Abhinav: Thanks for the question! However, i was wondering how was the string input by the user be known when the JavaScript has encrypted with hash algorithm before sending out to the server? The man-in-the-middle will only be able to capture data that has encrypted and not plain text. That's what i was thinking previously when @Oliver made that statement. Can you share your thoughts? 🙂

Comments are closed.