The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I believe it's better practice to store the user id and password hash or similiar in a session or cookie, and then on each page you would query the database with the given information to see if the user actually exists.

Yes, it will make things slower. If a scenario is likely to occur where during it's login-session a user will be removed or it's access rights change, then it is useful to keep checking.

To limit the risk of session highjacking you could also store the remote-ip in the session and destroy the session when the ip doesn't match. But then if your client's webserver suddenly gets moved behind two load-balancing proxies, stuff goes wrong...

Also store a last activity timestamp so that you can destroy a login-session after some inactivity and don't have to worry about how long a session gets stored on the server or an attacker that tries to revive an old session on a different computer.

if need to do a query to check the login details, isn't it going to make the site slower?

Will you be access the database for other things for the page? If so, then one extra query isn't going to make much difference.

To avoid users faking cookies, you could encrypt the data in the cookie and include either creation time or expire time (or both) in the data. Decrypt the data and checking it is still within the valid time.

where is my bad *** programmer avatar

best method to use is serialize and unserialize the user object
if you can return an object instanceof User then he's a valid user and you also have his current credentials including activity since he first logged in.

I call this my authorization object and have Authorization::getInstance() unserializes from session. throws exception if the user isn't logged in.

function inside authorization private function save()
moves object to a serialized session. used only when modification to authorization or user object is affected . else it remains the same as when the user first logged in.

The problem with this is as above ... no?
If some user attribute changes (say I delete a user), because the user object is being serialized and unserialized (stored in a session var probably) ... then the user could be valid for quite a bit before the session goes away.

My suggestion is to store the user id in session, hash the already hashed password, hash a randomly generated number, cocatenate all of the above as a string and store as a token in the session and in the db.
Then on each page request you just pull the userid and the session token and search the db for the combination, if none is found then the
- user's session has gone away
- or the user has logged in from a different computer.

You'd also make sure that a user edit or change would force a change of the token.

Originally Posted by leblanc

best method to use is serialize and unserialize the user object
if you can return an object instanceof User then he's a valid user and you also have his current credentials including activity since he first logged in.

I call this my authorization object and have Authorization::getInstance() unserializes from session. throws exception if the user isn't logged in.

function inside authorization private function save()
moves object to a serialized session. used only when modification to authorization or user object is affected . else it remains the same as when the user first logged in.

On some fairly decent traffic sites i've not even once seen the simple method that threadstarter suggests actually being a security problem.
Perfection is rarely the perfect solution for a problem as we all know, which brings me to ask, do people overdo security for apps that will never need such high security?
Or do you actually have hands on experience pointing to the simpler methods in this case actually not being secure enough?

> do people overdo security for apps that will never need such high security?

Regardless of the application, or the environment the application is used in, you can never overdo security from my point of view. It's better in any regard to go way out of your way to be secure, or at least to the point that you can determine that you can't be more secure.

You shouldn't take any chance with security on any level; When you do, this is how someone somewhere will find a hole and gain access, so believe me when I say don't just stop development of an applications security once it's finished, as it's a continual ongoing process.

1. As long as you don't store any credentials (even "logged in") in a cookie you should be fine.
2. You also don't want to store user credentials in you session, because we al know what shared hosts are like.
3. If you have a security hole, dub it plugin architecture and you'd be fine
4. You don't need to query the database every time to make sure the user is authenticated. However, the permissions a user has should remain in the database because you don't want them in a public place (cookie or /tmp).

So as long as you protect yourself from session hijacking you should be fine with the example above.

When I create a new user, I put a randomly generated 12 character hash in the database row for that user, and use it along with email and password (which is MD5 anyway) to create a hash.

It's that hash that is stored in the session; Pretty much secure since the 12 character hash is unknown (it's unique). If you were paranoid, I suppose you could put an expiry period on the hash and have it regenerated, but it makes no real difference to the login process.

1. As long as you don't store any credentials (even "logged in") in a cookie you should be fine.
2. You also don't want to store user credentials in you session, because we al know what shared hosts are like.
3. If you have a security hole, dub it plugin architecture and you'd be fine
4. You don't need to query the database every time to make sure the user is authenticated. However, the permissions a user has should remain in the database because you don't want them in a public place (cookie or /tmp).

So as long as you protect yourself from session hijacking you should be fine with the example above.

i am not too sure how session hijacking works. i am on a shared host but how would this affect my sessions?

When I create a new user, I put a randomly generated 12 character hash in the database row for that user, and use it along with email and password (which is MD5 anyway) to create a hash.

It's that hash that is stored in the session; Pretty much secure since the 12 character hash is unknown (it's unique). If you were paranoid, I suppose you could put an expiry period on the hash and have it regenerated, but it makes no real difference to the login process.

Does that help?

i am not storing the password in the session because i thought that is redundant since the user has logged in. however, this wouldn't allow me to do authentication on every page since the the password is not in the sessions. moreover, my concern was doing authentication on every page may slow down the page as there may be many people access the same page at a time and a large number of queries ran were actually to authenticate the users sounds funny to me.

it was recently that i began to think what happens if someone was able to change the values in the session? since the only session variable i have is the user's id, if someone could change the value of the userid in the session, he could immitate any users on the site and escape from logging in the true credentials.