checking login security

[x[E]nOn]

when checking for user login, i usually do this like after the user has logged in with the correct username and password, i will set a SESSION or COOKIE variable like 'login' = 1;

so when i check if the user is logged in, i do this:

if($_SESSION['login'] == "1") {
 print "logged in";
}

however i began to wonder if this is secure enough? is it possible where people can fake a cookie or session by creating a similar cookie name and value to 1?

thanks.

[amojabber]

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.

[x[E]nOn]

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

[Type-O]

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.

[MikeBigg]

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.

Don't store the IP address for validation - AOL users' IP addresses may change from page request to page request.

Mike

[Type-O]

Don't store the IP address for validation - AOL users' IP addresses may change from page request to page request.

Interesting point, I'll take that into account. Haven't had sites targeting AOL users (Dutch based projects) so I haven't encountered such issues yet (I would have noticed soon enough ).

[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.

[ikeo]

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.

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.

[Findus]

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?

[Dr Livingston]

> 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.

[Jasper Bekkers]

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.

[rawkes]

Can someone explain to me what the use is for storing the user's password in the session?

[Dr Livingston]

Not sure what you are asking but it shouldn't be the password alone that you store, but a hash, which may comprise of several pieces of data,

$request -> get( 'session' ) -> set( '...', sha1( $row['hash'].$row['email'].'-'.$row['password'] ) ); // ... 

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?

[x[E]nOn]

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?

[x[E]nOn]

Not sure what you are asking but it shouldn't be the password alone that you store, but a hash, which may comprise of several pieces of data,

$request -> get( 'session' ) -> set( '...', sha1( $row['hash'].$row['email'].'-'.$row['password'] ) ); // ... 

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.