At 09:53 AM 4/20/00 +0530, Differentiated Software Solutions Pvt. Ltd. wrote:
>Hi,
>
>Persitent cookies was the dilemna I was in.
>
>I also found that there are persistent and non-persistent cookies. I wrote
>some test Javascript programs and found out that we can have cookies which
>die after the browser exits. Would this be a good option.
>Another nagging doubt. Is this the way the world implements security with
>CGI or am I missing something ??
The idea that the cookie actually dies with an exiting browser is not
guaranteed. If you are relying on the client-side for your security, this
can be spoofed. I could write an HTTP client the conceivably keeps the
cookie alive and persistent and ignores the expiry info the server sends
with the cookie.
You should be expiring the sessions themselves through a cron job or some
dynamic checking mechanism anyway.
There are many ways to do CGI security. They all have their ups and downs.
Cookies with expiring sessions is one way. Digital Client certificates is
another.... Normal username/password Basic auth is another ...
Really depends on what you want to do and what tradeoffs you want.
Later,
Gunther
>Thanks a lot for informing me about this news group. I'll keep tabs on this
>group.
>
>Murali
>-----Original Message-----
>From: Jeff Beard <[EMAIL PROTECTED]>
>To: Differentiated Software Solutions Pvt. Ltd. <[EMAIL PROTECTED]>;
>[EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Date: 20 April 2000 10:55
>Subject: Re: Implementing security in CGI
>
>
> >This is a question for comp.infosystems.www.authoring.cgi.
> >
> >But since I'm here...
> >
> >I would check for the cookie every time a request is made. If you use
> >Apache::Session there will be a separate session data store from the user
> >data. Which is probably what you really want. Apache::Session will allow
> >you to associate whatever data you like with the session id within it's own
> >schema.
> >
> >If the browser is closed, the cookie will remain. You can have a logout
> >feature but there will always be a significant percentage of users that
> >won't bother. So limit the life of the cookie with the time value and
> >periodically cull stale sessions on the server.
> >
> >--Jeff
> >
> >
> >At 05:21 PM 4/19/00, Differentiated Software Solutions Pvt. Ltd. wrote:
> >>Hi,
> >>
> >>My question is much more basic than that. I wanted to validate my design
> >>ideas on a programmatic security.
> >>I would like somebody to go through the following and tell me that I'm on
> >>the right track.
> >>
> >>The idea I had was, at the time of login, I generate the session id which
>I
> >>write to the cookie.
> >>I have also tied to this session_id the user's login profile.
> >>Every other screen checks for the cookie's existence and reads back the
> >>session_id and gets the user's profile. I hope I'm right till then.
> >>When the user signs out then we can delete the tied file.
> >>Now any person who has access to the same browser will still have to login
> >>to get to the inner pages.
> >>
> >>If the browser is killed without sign-out from the system, even then
>there's
> >>no problem.
> >>Next person who gets access to the browser and tries to access any inner
> >>page will not be able to, because the cookie with the session-id does not
> >>exist.
> >>
> >>Am I right ??? Please help.
> >>
> >>Thanks,
> >>
> >>Murali
> >>
> >>-----Original Message-----
> >>From: Gunther Birznieks <[EMAIL PROTECTED]>
> >>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> >>Date: 19 April 2000 18:44
> >>Subject: Re: Implementing security in CGI
> >>
> >>
> >> >Apache::Session could be useful. But the session key that is generated
>is
> >> >arguable not necessarily the most secure that it could be. But it is
>pretty
> >> >good.
> >> >
> >> >I'm probably opening up a can of worms by saying this.
> >> >
> >> >The MD5 hash itself is relatively secure as hashes go (although SHA hash
> >> >space could be better). But you are relying on underlying system
>variables
> >> >to determine what is put into MD5 hashing in the first place -- and this
> >> >data is not necessarily the most random-- process ID, time, memory
>address
> >> >of the created hash, etc... Are a bit deterministic. rand() might be
>good
> >> >if it is on a system that plugs natively into a good entropy generator
>on
> >> >that machine.
> >> >
> >> >To get a better key, you probably end up spending more time pulling
> >> >relatively random data sources together so key generation itself would
>be
> >> >slow-- a computational tradeoff. Depends on how "secure" you really want
>to
> >> >be. For most situations, Apache::Session's key generator will work
>fine.
> >> >
> >> >It also depends how long you intend the sessions to be active. Will they
> >> >become a "token" that is used in lieu of authentication once the user
>has
> >> >entered a username and password or issued a digital client certificate
>to
> >> >your web site? Or will it be used after the user registers for a month+
>to
> >> >allow them to get back into your site without remember a password.
> >> >
> >> >-- Gunther
> >> >
> >> >At 01:34 PM 4/19/00 +0530, Differentiated Software Solutions Pvt. Ltd.
> >>wrote:
> >> >>Hi,
> >> >>
> >> >>We are having a site which is programmed with perl/CGI.
> >> >>To enter the site we have a login and password.
> >> >>After which some reports are displayed.
> >> >>
> >> >>I know that using cookies it is possible to secure the site.
> >> >>Can somebody guide me on how to design and implement a cookie based
> >> >>security. Sites and books on same will be greatly appreciated.
> >> >>
> >> >>Would Apache::Session be useful for this ??
> >> >>
> >> >>Thanks for the help,
> >> >>
> >> >>Murali
> >> >>
> >> >>Differentiated Software Solutions Pvt. Ltd.,
> >> >>176, Gr. Floor, 6th Main
> >> >>2nd Block RT Nagar
> >> >>Bangalore - 560 032
> >> >>India
> >> >>Ph: 91 80 3431470
> >> >>email : diffs+AEA-vsnl.com
> >> >>http://www.diffs-india.com
> >> >>
> >> >>Differentiated Software Solutions Pvt. Ltd.,
> >> >>176, Gr. Floor, 6th Main
> >> >>2nd Block RT Nagar
> >> >>Bangalore - 560 032
> >> >>India
> >> >>Ph: 91 80 3431470
> >> >>email : diffs+AEA-vsnl.com
> >> >>http://www.diffs-india.com
> >> >
> >> >__________________________________________________
> >> >Gunther Birznieks ([EMAIL PROTECTED])
> >> >Extropia - The Web Technology Company
> >> >http://www.extropia.com/
> >
> >
> >
> >Jeff Beard
> >_______________________________
> >Web: www.cyberxape.com
> >Phone: 303.443.9339
> >Location: Boulder, CO, USA
> >
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
