Viewed   88 times

What are some guidelines for maintaining responsible session security with PHP? There's information all over the web and it's about time it all landed in one place!



There are a couple of things to do in order to keep your session secure:

  1. Use SSL when authenticating users or performing sensitive operations.
  2. Regenerate the session id whenever the security level changes (such as logging in). You can even regenerate the session id every request if you wish.
  3. Have sessions time out
  4. Don't use register globals
  5. Store authentication details on the server. That is, don't send details such as username in the cookie.
  6. Check the $_SERVER['HTTP_USER_AGENT']. This adds a small barrier to session hijacking. You can also check the IP address. But this causes problems for users that have changing IP address due to load balancing on multiple internet connections etc (which is the case in our environment here).
  7. Lock down access to the sessions on the file system or use custom session handling
  8. For sensitive operations consider requiring logged in users to provide their authenication details again
Monday, December 5, 2022

Random salts have a tremendous benefit. If all accounts in the system use the same salt, an attacker can brute-force calculate hashes for that salt and break into all accounts with just one computational run. If they use different salts per account, brute-force only gets you into one account.

Wednesday, September 7, 2022

No, unless:

  • The attacker had access to the storage of the session variables (usually the filesystem of the server, but could also be e.g. a database)
  • The attacker intercepted a session cookie of a more privileged user.
  • The attacker successful fixated the session of a more privileged user (see session fixation attacks).
Sunday, December 25, 2022

If the man in the middle can hijack the session ID, then he should have absolutely no problem in sending the same user agent, so I don't think this will get you anywhere. This is security by obscurity.

If you want real protection, use HTTPS.

Sunday, December 4, 2022

A few things here:

  1. You aren't really encrypting it, you're hashing it. Easy thing for newbies to confuse, but just wanted to get that out of the way.

  2. Don't use MD5, it's just not a very secure hash. Use one of the SHA variants instead if possible.

  3. Don't just hash the password, you'll want to "salt" it too. Basicly this involves adding a random string to the password before you hash it, and storing that random string somewhere where you can retrieve it later (so that you can validate the hash when the user enters their password). This helps prevent against pre-computed dictionary attacks.

As for generating the password, I think you are on the right track - I would just generate it when they create their account, email it to them, then hash it and store the hashed (and a random salt) on the user record in the DB.

Friday, August 19, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :