Page 1 of 1
Check if logged
Posted: Wed Oct 19, 2005 12:10 pm
by Skara
Alright, here's the problem I'm having... I looked over what's-his-name's tutorial on challenge/response logging in, and ok, that's great. But now what would be the best method for checking if someone is still logged in? At the moment, all I can figure is to store a hashed/encrypted version of their password in their session/cookies, then checking it before doing anything that needs logging in. That seems a pretty dumb way to do it to me, though. Should I use a challenge/response method for the checking as well? And if so, how would I go about it?
e.g.
if (is_logged()) { //...
Posted: Wed Oct 19, 2005 6:14 pm
by Ambush Commander
Session IDs should be sufficient. There's a chance that the cookie containing it could be intercepted, but nothing's sacred.
You might be talking about "remember me", in that case, I'd suggest decoupling it from passwords and instead issue randomly generated tokens, stored in the database with expiration dates.
Posted: Thu Oct 20, 2005 3:04 am
by Maugrim_The_Reaper
All you really need is some SESSION flag that can be looked for. Say the user logs in - you set up a var say $_SESSION['authenticated'] = 1. You can check that this is set on every page request. If a login fails, or this is not set (new visitor) set it to 0.
You can also do a bit more. SESSION can also store the username and/or user ID (depends). The Database can store the session ID (from session_id() function). On a request you can validate a user:
a) check that $_SESSION['authenticated'] == 1
b) use the SESSION data to look up the user on the database (if exists or not)
c) ensure the session_id() value matches the session ID stored to database for that user. (remember this will not agree once session has expired - so it will force a new login)
You can look through this forum for other ideas to secure sessions, e.g. session ID regeneration etc.
Posted: Thu Oct 20, 2005 6:57 pm
by Skara
Well, it just doesn't look secure to me. For a session flag, all someone would have to know is what variables to set and what the other person's username is. Voila, logged in.
I suppose the session_id() value would be the hook, though. I think I'll generate a random value and use that, though.
Thanks.
Posted: Thu Oct 20, 2005 7:01 pm
by Ambush Commander
A user cannot arbitrarily set SESSION variables like he can for COOKIE, GET, POST (aka the REQUEST variables).
Posted: Fri Oct 21, 2005 4:59 pm
by Skara
well, no, not session variables, but cookies he can. I've got the option to stay logged in.
unchecked => sessions
checked => cookies
Posted: Fri Oct 21, 2005 7:10 pm
by Jenk
sessions are more secure than cookies.
Cookies are client, sessions are server.
Posted: Sat Oct 22, 2005 1:24 am
by Sequalit
Maugrim_The_Reaper <=----- what he said.
Posted: Sat Oct 22, 2005 4:25 am
by Maugrim_The_Reaper
If you mean a "remember me" feature I'll be honest. They can make a system less secure. There are ways of limiting the security risk so I would suggest searching this forum for the term.
Posted: Sat Oct 22, 2005 10:16 am
by John Cartwright
They can make a system less secure.
you mean
They will make a system less secure.

Posted: Sat Oct 22, 2005 11:42 am
by Ambush Commander
My personal view on the matter is that unless you're doing commercial applications (and most of the time not even there) it is a fair and balanced trade off between usability and security. You should require reauthentication before sensitive/money-related application parts are executed, but say for Wikipedia, remember me works perfectly.
Posted: Sun Oct 23, 2005 5:20 am
by AGISB
The only way to know exatly what state the user is in is to update a timestamp every time a user interacts with the page. If he hasnt interacted in a given time log them out.