Re: Identifying clients

This is slightly off topic for the question, but this line got me thinking.

"If a client attempts to run the application with an unknown or expired session id, the client ip is placed a penalty box for a timeout (no login allowed during the timeout)."

A good example of a harmless visit to the penalty box is the user who is using the app and goes off to lunch. He returns to his browser and tries to use the app, sending his ip to the box because of an expired session. He refreshes or hits the back button, sending him to the box for 8 more seconds or maybe more depending on how many times he tries to use it. Why not just send the expired users straight to the login screen with no penalty at first (maybe a zero second penalty) and then see what they do? Just a suggestion.

-----------------------------------
Washizu
Odd Man In: Guns and Game Theory

Comment on Re: Identifying clients

Replies are listed 'Best First'.
Re^2: Identifying clients by Firefly258 (Beadle) on Dec 07, 2006 at 04:45 UTC
The algorithm ought to treat unknown or expired session IDs as invalid and proceed to authenticate the user before generating a new, unique, valid session ID for the new session. This way there'd be no need to involve a potentially irritating time-out problem. A timeout should probably be used after repetetive failures to authenticate the user properly. Also, by the very definition of a session, a session ought to expire after a certain period of inactivity, otherwise one could just do away with the need for sessions IDs to identify a "session" as a period of continuous involvement with the application and we could term the ID as a client ID instead as there'd be little or no variance. `perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er`	[reply] [d/l]
Re^3: Identifying clients by ruzam (Curate) on Dec 07, 2006 at 18:14 UTC
The flaw (or feature) in the current design is that the session entries are cleared as soon as they expire. So if a user tries to continue with an expired session id, the application has no reference to be able to say if the session is simply expired or it's a malicious attempt to steal someone's session. That's the line of thinking that started the whole ip blocking plan. Since I can't rely on the ip I don't think there's anything I can do to prevent a session attack so there's not much point blocking or timing anything ip or session related. About the only thing I think I can do at this point is penalty box the user id after a failed login. At least then I can slow down a password attack, while not affecting an already logged in user.	[reply]
Re^4: Identifying clients by Firefly258 (Beadle) on Dec 08, 2006 at 20:56 UTC
The flaw (or feature) in the current design is that the session entries are cleared as soon as they expire. So if a user tries to continue with an expired session id,... Consider this ID as invalid and indeed expired, then authenticate him/her again to generate a new session ID. About the only thing I think I can do at this point is penalty box the user id after a failed login. But consider a threshold, a number of tries before taking punitive action, a user might mistakenly enter his/her password quite repeatedly with no malicious intent at all, and you don't want to tick a user off at this sesnsitive time. `perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er`	[reply] [d/l]
Re^2: Identifying clients by ruzam (Curate) on Dec 07, 2006 at 17:59 UTC
That's exactly what triggered the problem. The first penalty is a mere 4 seconds (barely time for the user to read it and realize the session timed out), and always redirects back to the login page. It's the repeated failures that grow the timeout, and with many users under the same IP, they all get hit regardless of session status. Determining a first time session expire (vs repeated session attempts) isn't built into the design yet. It's a work in progress...	[reply]