Home/ Questions/Q 6633975
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T22:52:33+00:00

Ok, yes, I’ve read the other Qs regarding this topic, but I have several

  • 0

Ok, yes, I’ve read the other Qs regarding this topic, but I have several questions more and some Qs were several years old.

Anyways, I’m building an admin cp for an insurance company that contains sensitive client info. Such as passwords, social security numbers, and drivers #.

First Q:
What’s more secure, php sessions or cookies? From my understanding of cookies, you can strict them to http only and SSL. Don’t know if you can do the same with php sessions. Seems also that php sessions are just quick cookies. Cookies seem more flexible and just as reliable. FYI, I’m using Cookies with http and SSL only. Is there a good reason to use php sessions in MY case?

Second Q:
My sessions/login work like this:
* Passwords are salted and hashed
* Sessions are 32 random chars long
* Sessions are validated when user enters correct pw and are tied to the user’s IP
* When a user logs in, the session id and user’s password are stored in 2 separate cookies

If the sessions are validated via user pw and tied to the user’s IP, can I just have the session Cookie and remove the pw cookie? since I think it’s kinda redundant since you can only get a session id if you enter the correct PW. I rather have the session id expose in a cookie than the pw (though it’s still salted and hashed).

Appreciate it if my two Qs can be answered. Additional security advice is welcomed 😀

Note: Sessions are tied to IP because it increases security greatly. I rather have my users a bit inconvenienced in having to enter their pw when their IP changes when we have SSNs and Driver License #s in our db. Only 3-5 users will have access to the system too.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team
    • Do not ever store the user’s password in a cookie, in no form of representation.
    • Regenerate the session ID often
    • Use strong hashes (no MD5) like SHA512 (consider also stretching the hash)
    • Sensitive data should be on the server-sided session store:
      • Cookies are sent along every request to the cookies domain, hence increasing the chances of being intercepted greatly. Server sided session data is only outputted when needed.
    • Pass along a session-tied identifier to each sensitive request as an auth token to avoid CSRF
    • Do not directly bind the session to an IP. Two people using the same AP or private ISP have the same IP and sessions could be mixed up.
    • SSL is not magical. Don’t relay on it too much.
    • 0