A lot of people will use sessions with some type of MD5 hash of the user information and password as well (in cookies or urls) this way it makes it way harder to fake sessions, and yes sessions can be faked depending on how they are implemented. Many session handlers forget that a substantial portion of the internet (AOL many other ISPS) connect though transparent proxies which makes the originating IP almost worthless in the session state.
-Waswas
| [reply] |
Is this dangerous enough to warrent the speed hit of checking name and pass every time on a site where security is not key (ie I don't use https)?
Thanks,
Max
| [reply] |
Are you providing the sessions or are you using a 3rd party product or are you using perl modules to do it? It really depends why the site is password protected to begin with. If you have no need for security but just have logins to change the look and feel of a site then I would say no. If you have parts of the site that contain personal information or information that is _private_ then I would say it might make sense to deal with the overhead of doing so. The devil is in the details -- what makes sense for one site may not make any for the next.
-Waswas
| [reply] |
What I've done in the past is to generate a fairly unique base64 string (20 digits or so) and send the user a cookie with that string when they first log in.
I figure the chance that another user guessing that is low and if they were snooping the line, well, they'd have the password anyway, so why bother with a more elaborate setup?
I then check the cookie every request and expire the cookie after a time-out of say 1/2hr or whatever (usually user alterable).
I do this over the built-in password checking because, well, I wanted to figure out how and prefer the little login boxes over the pop-up style =)
Of course, these were all in the name of seeing if I could do it, so I didn't consult the all-mightly CPAN before re-engineering the wheel.
-Ducky
| [reply] |
Session ID's can be faked, there is no doubt about it. All one has to do is change the value in the cookie (if using cookies) or the parameter value. It really is a no brainer to fake.
Now the good news. What is not so easy to do is to determine how the session id is created. Depending on the level of security you want, you may have the session id changed every time a user views a page, or change it for every session.
To do my session stuff, i use MD5 and a combination of various things including an arbitrary string, with the session id lasting as long as a session (a user is logged in). I dont really need the security to change the session id each time a page is viewed.
Each time a logs in you give them a session key, either in a cookie, or html parameter somewhere, then and save it server side in a database against the user_[id|name].
You have the overhead of making a call to the database each time, however there are many things that can be done to tune this access, depending on the level of performance you require, ie caching the db in memory, using placeholders in you DBI (if you're using DBI), using mod_perl to create persistant connections (again, if you're using DBI) etc etc. | [reply]
[d/l] |
