I am trying to develop a PHP login script that can start secure logins with cookies. I know you can do a lot with computers and I am asking the community for information on the security of cookies. My biggest question: Can someone create cookies spoofing an account and access the site without logging in? And what would be the most secure way of checking whether or not this user is legitimate?
-
It doesn't matter whether they create a cookie or not, its validity is all that matters. Additionally, you shouldn't store sensitive information (like password) in cookies. You can check JWT out : http://jwt.io – salep Nov 10 '15 at 14:08
-
1maybe interesting? [PHP login system: Remember Me (persistent cookie)](http://stackoverflow.com/questions/3128985/php-login-system-remember-me-persistent-cookie) – Ryan Vincent Nov 10 '15 at 14:22
2 Answers
Cookies are browser-stored, so yes, they can create cookies. What you normally do to prevent this is set a cookie for the user id, another one for the session hash (something you generated randomly when the user logged in) and check the session IP.
- 51
- 2
In my opinion using cookie over session is more secure, since at its base session identifiers are also stored in a cookie or in http requests, which are more prone to session hijacking. The way I usually do it, depending on requirements, is i store in one cookie all of the user identifiers. Something like: ID:PUBLIC_KEY:USER_DATA_SESSION_HASH_VERIFIER. Where:
ID is the user id.
PUBLIC_KEY is a random string stored in the db, which can be further secured if you regenerate it at every login, also keep in mind that it will un-validate all logins from other devices, browsers. So essentially you can only be logged in from one place at a time.
USER_DATA_SESSION_HASH_VERIFIER is a hash composed of user id, user agent, current ip address, public key, private key, mixed in between with salts ( tokens ), mixing multiple times md5 and sha1 with a final sha1 or sha256 hash.
So using the ID and PUBLIC_KEY I select the user and some data with it, like the private key, regenerate the hash, and match it with USER_DATA_SESSION_HASH_VERIFIER. keep in mind that having current ip in the hash will log out users with dynamic ip if they restart there internet connection, which will have a new ip address. Mixing the user agent in the hash will prevent other users from using your cookie on different browsers.
Now if your looking for something like session management for users like facebook has, than you can mix in a session identifier in there and store the session identifier with your unique public key for that session in the database.
ex. 1:asdfg:uss32:sha1_hash 1:GGGAS:2312:sha1_hash. this way you cant use asdfg key for the session 2312.
There may be other better practices out there but for me at the time being this seems to be a very good solution.
- 1,759
- 1
- 12
- 13