Home/ Questions/Q 3597118
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T20:04:38+00:00

I’m creating a login script for a website i’m developing, and am using PHP

  • 0

I’m creating a login script for a website i’m developing, and am using PHP sessions to authenticate users.

I’ve set the script to use HTTP only for the cookies, and to only use cookies for storing the session ID.

Basically, I’d like to know two things

1. Is there anything more I should do to make my login more secure?

and

2. The PHP Manual says that session_destroy() deletes the session data, but doesn’t unset any of the session variables. If this is the case, what is it actually destroying, and should I manually unset my session variables on logout?

Thanks for any help

EDIT:
I am using free hosting, and cannot install any Apache addons or change the php.ini file

EDIT:
I’ve read that using SSL is required to stop the session ID from being stolen, but I don’t have the ability to install OpenSSL on the server, so is there some other way I could protect the session ID?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The most important thing to remember:

    Don’t trust ANYTHING that comes back from the client

    Never assume that the information you are getting (in a form field (even hidden ones), session variables, etc.) are valid – use server-side logic to perform these checks.

    1.) Make sure your session is encrypted. If you are using PHP’s built-in sessions, the associated entropy (randomness) is relatively high, so you should be fine.

    2.) ONLY store the session id in the cookie. Any other information should simply be associated on the server using that id. I’ve seen many cases where the system engineer determines if someone is admin if the token ‘is_admin’ = true in the session. You can obviously see the problem with this.

    Some will complain that its an expensive operation, but I recommend creating a (my)SQL table for active sessions. Then, when the page is loaded, pull the associated data from the table and deal with it just as you would any other data. Some frameworks (like CodeIgnitor) do this for you by changing one configuration item.

    3.) Validate against IP – in your table, add the current IP address. If the current IP doesn’t match the one in the session, someone is probably trying to hijack. Force a logout and terminate.

    4.) Place limits on login attempts. Adding a 1 second sleep(); server side on each login is virtually unnoticeable to the user, but for an automated system, it makes it virtually impossible to brute force logins.

    5.) Watch being ‘too chatty’. In a login, you may think it’s helpful to give descriptive erros like ‘username doesn’t exist’ or ‘incorrect password’. Information like this tells a hacker that they have gotten a valid username – it makes hacking much faster.

    6.) Be less concerned about the safety of PHP and SSL and more of your own logic. Just because a website uses SSL doesn’t make it secure. SSL coupled with valid logic provides security.

    7.) If you’re SUPER concerned, you’ll want to move to a dedicated server. It’s possible that other websites hosted on your server could have access to your code/db information. They may not be taking the necessary steps to be as secure as you.

    8.) Don’t allow simultaneous sessions. This prevents a MITM (man in the middle) attack. Another advantage of the DB session approach is that you can force logouts if two clients are trying to login at the same time from different IPs. Yet another advantage to the DB approach is that it makes your system scalable (since session storage is filesystem dependent).

    9.) Use mysql_real_escape_string instead of add_slashes

    If you need more information on security with PHP, it’s a speciality of mine. Feel free to contact me.

    • 0