Recent Topics

1 Oct 12, 2005 16:12    

At each request:

1) check if we can get a sess_ID + a sess_key from cookies. These should be matched against the evo_sessions table. If they match, the user is logged in. We can get his ID though sess_user_ID.

Note: sess_key is currently implemented as a poor md5 hash which is flawed. This should be changed to a real random string in the range [A-Za-z0-9]. (We pass the sess_ID along because it speeds up the process; i-e: no need to make sure the sess_key is really unique, nor to index it).

2) if no sess_ID+sess_key is provided, then we need to authenticate through username and password (by the way, no md5 version of the password was ever been meant to be transfered online). If ok, we need to create the session.

OPTIONAL DEV: The session should expire after an admin/user configurable delay if no activity. that means we need to check sess_lastseen on step 1. (some people will want the session to never expire).

OPTIONAL DEV: Checking that the user agent (not in session table yet) or the IP has not changed should also be an admin/user configurable option.

OPTIONAL DEV: for augmented security we could ask for the password again after some time if a critical operation is requested. This needs a lot of work and testing though since you don't want to lose data when a user clicks on "POST" after one hour of editing and gets asked for the password again.

2 erik Jan 19, 2006 00:47

erik

I would like to do my part in making this one more popular.

All listed items are good and part of good security practice.

I was hacking around in the “Amsterdam” code and went pale when I saw how it was handled there :-(.

my vote for this one!

b2 – This forum is powered by b2evolution CMS, a complete engine for your website.