SitePoint Sponsor |
|
User Tag List
Results 1 to 15 of 15
Thread: checking login security
-
Jun 5, 2007, 21:09 #1
- Join Date
- Jan 2005
- Posts
- 204
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
checking login security
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:
Code PHP: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.
-
Jun 6, 2007, 00:06 #2
- Join Date
- Apr 2007
- Posts
- 2
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Jun 6, 2007, 00:17 #3
- Join Date
- Jan 2005
- Posts
- 204
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
if need to do a query to check the login details, isn't it going to make the site slower?
-
Jun 6, 2007, 06:29 #4
- Join Date
- Jul 2004
- Location
- NL, Rotterdam
- Posts
- 38
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Jun 6, 2007, 06:41 #5
- Join Date
- Jun 2004
- Location
- Reading, UK
- Posts
- 970
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Jun 6, 2007, 06:48 #6
- Join Date
- Jul 2004
- Location
- NL, Rotterdam
- Posts
- 38
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Jun 6, 2007, 08:41 #7
- Join Date
- Aug 2004
- Posts
- 428
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Jun 7, 2007, 15:45 #8
- Join Date
- Oct 2004
- Location
- Austin Texas
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Jun 8, 2007, 00:42 #9
- Join Date
- Jun 2004
- Location
- Norway - Oslo
- Posts
- 198
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?
-
Jun 8, 2007, 05:16 #10
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
> 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.
-
Jun 8, 2007, 07:42 #11
- Join Date
- May 2007
- Location
- The Netherlands
- Posts
- 282
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.Design patterns: trying to do Smalltalk in Java.
I blog too, you know.
-
Jun 24, 2007, 11:38 #12
- Join Date
- Oct 2006
- Location
- Surrey, UK
- Posts
- 121
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Can someone explain to me what the use is for storing the user's password in the session?
Rawkes - Standards based web design and development
-
Jun 24, 2007, 14:17 #13
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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,
PHP Code:$request -> get( 'session' ) -> set( '...', sha1( $row['hash'].$row['email'].'-'.$row['password'] ) ); // ...
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?
-
Jun 25, 2007, 19:47 #14
- Join Date
- Jan 2005
- Posts
- 204
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Jun 25, 2007, 19:52 #15
- Join Date
- Jan 2005
- Posts
- 204
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
Bookmarks