Re: Cookie authentication
On Fri, Nov 16, 2001 at 02:09:25AM +0100, Tom Bille wrote: The aim of the cookie example in the eagle book is a bit more than just authentication. Most of the answers here to use a session ID here are quite right for most purposes, but the code in the eagle book offers to store information on the client side with the security of a signature. Its NOT just authentication. This has some advantages for applications which are on more than one server, which have to use an expensive central DB lookup and/or are not connected at all, since the only thing to share is the secret. [snip] And for the academically inclined, Authen::Ticket (which I need to go back and update) is based on the Eagle book's example but different :/ It uses a PKI-like solution for ensuring authenticity of the cookies (at least someone can't just make up a cookie out of thin air). If you're using FreeBSD, I believe there's even a port for it (much to my surprise). --jim
RE: Cookie authentication
Thanks David. It hadn't dawned on me to do the cookie storing/retrieving over SSL - sometimes I need to be hit over the head with a sledgehammer to see the obvious. Without some sort of secure mechanism to transport the cookie between the browser and app all the app can be assured of is that the cookie is valid. The app cannot be 100% certain that the cookie being sent is sent by the real owner of the cookie. Generally, I would say that most applications could use any of the proposals floated on the list yesterday and today and not worry about client sessions being hijacked. Of course, if a session is hijacked - how much damage is done is a question the developer needs to ask themselves. If the risks are acceptable then what is in the Eagle book and has been discussed is OK. If the risks are not acceptable then what David suggests is the way to go. And thanks to everyone who posted. --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: David Young [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 6:30 PM To: [EMAIL PROTECTED] Subject: Re: Cookie authentication I don't think that really solves Joe's proposed problem. Joe wants to ensure that the cookie is coming back from the client he sent it to. If you generate a unique ID, someone can sniff the network, grab the cookie, and send it as their own. The Eagle book does half-heartedly suggest IP address as being a way to ensure the cookie's source, but that's not reliable in these days of proxies and NAT. The only answer, I think, is to only send the cookie over an SSL connection, so that it can not be sniffed. Remember that there is an attribute you can set on the cookie that tells the browser to only send the cookie over an SSL connection. Spend some time playing with Amazon and see how they handle cookies. They appear to have cookies that get sent over every connection which they use to personalize your web pages (not necessarily sensitive info). However, as soon as you try to purchase something or go to a sensitive area, you are asked to sign-in and sent a cookie over https. From: Perrin Harkins [EMAIL PROTECTED] Date: Thu, 15 Nov 2001 18:40:03 -0500 To: Joe Breeden [EMAIL PROTECTED], mod_perl List [EMAIL PROTECTED] Subject: Re: Cookie authentication Excuse my question if it seems dumb I'm not 100% on NAT and proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to be user for the MAC. It also suggests to use the remote IP address as one of those fields. 3 Compute the MAC via a MD5 hash and store in the clients browser. 4 On subsequent visits recompute the MAC and verify it matches the original stored MAC. How is this reliable in a situation where many similarly configured computers are behind a NAT/Proxy and one of the users try to steal someone else's session by getting their cookie/session_id info? Don't use the IP address in the cookie, just generate a unique ID of your own. I suggest using mod_unique_id. - Perrin
RE: Cookie authentication
Amazon seems to include your session id in the URL in addition to a cookie. I assume they do this to personalize when cookies are turned off and to prevent proxy caches from caching personalized pages and serving them to the wrong end-user. If you happen to type in a URL, they can revive your session from the cookie. Pretty nifty trick. - Kyle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Young Sent: Thursday, November 15, 2001 4:30 PM To: [EMAIL PROTECTED] Subject: Re: Cookie authentication I don't think that really solves Joe's proposed problem. Joe wants to ensure that the cookie is coming back from the client he sent it to. If you generate a unique ID, someone can sniff the network, grab the cookie, and send it as their own. The Eagle book does half-heartedly suggest IP address as being a way to ensure the cookie's source, but that's not reliable in these days of proxies and NAT. The only answer, I think, is to only send the cookie over an SSL connection, so that it can not be sniffed. Remember that there is an attribute you can set on the cookie that tells the browser to only send the cookie over an SSL connection. Spend some time playing with Amazon and see how they handle cookies. They appear to have cookies that get sent over every connection which they use to personalize your web pages (not necessarily sensitive info). However, as soon as you try to purchase something or go to a sensitive area, you are asked to sign-in and sent a cookie over https. From: Perrin Harkins [EMAIL PROTECTED] Date: Thu, 15 Nov 2001 18:40:03 -0500 To: Joe Breeden [EMAIL PROTECTED], mod_perl List [EMAIL PROTECTED] Subject: Re: Cookie authentication Excuse my question if it seems dumb I'm not 100% on NAT and proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to be user for the MAC. It also suggests to use the remote IP address as one of those fields. 3 Compute the MAC via a MD5 hash and store in the clients browser. 4 On subsequent visits recompute the MAC and verify it matches the original stored MAC. How is this reliable in a situation where many similarly configured computers are behind a NAT/Proxy and one of the users try to steal someone else's session by getting their cookie/session_id info? Don't use the IP address in the cookie, just generate a unique ID of your own. I suggest using mod_unique_id. - Perrin
RE: Cookie authentication
If you happen to type in a URL, they can revive your
session from the cookie. Pretty nifty trick.
This would seem to be a security hole to me. URLs appear in the logs
of the server as well as any proxy servers along the way. If the URL
contains reusuable auth info, anybody accessing any of the logs could
gain access to customer accounts.
to prevent proxy caches from caching personalized pages
and serving them to the wrong end-user.
If you want to ensure privacy, use:
$r-header_out('Cache-Control' = 'private');
If you want to turn off caching altogether, use:
$r-header_out(Pragma = 'no-cache');
Rob
Re: Cookie authentication
As I mentioned before, if you dissect what they do with cookies and when, you'll find they maintain two levels of session tracking, one for non-sensitive personalization uses and one for sensitive authentication uses. The URL session ID is likely only the former, and not exposing anything sensitive. I haven't spent a lot time seeing what they do when I disable cookies, but I do know that if I copy an URL (which contains my session ID) and send it to a friend, when that friend clicks on it, Amazon redirects to a new URL with a different session ID. From: Rob Nagler [EMAIL PROTECTED] Organization: bivio Software Artisans, Inc. http://www.bivio.net Date: Fri, 16 Nov 2001 15:22:02 -0700 To: [EMAIL PROTECTED] Subject: RE: Cookie authentication If you happen to type in a URL, they can revive your session from the cookie. Pretty nifty trick. This would seem to be a security hole to me. URLs appear in the logs of the server as well as any proxy servers along the way. If the URL contains reusuable auth info, anybody accessing any of the logs could gain access to customer accounts.
RE: Cookie authentication
If you happen to type in a URL, they can revive your session from the cookie. Pretty nifty trick. This would seem to be a security hole to me. URLs appear in the logs of the server as well as any proxy servers along the way. If the URL contains reusuable auth info, anybody accessing any of the logs could gain access to customer accounts. I disagree. The server logs are somewhat irrelevant because they should already be under access control, and they could contain anything including HTTP headers and content from post requests. As for proxies, they see the entire HTTP transaction anyway. If they aren't trusted, the data should be encrypted end-to-end with SSL. If the session-id is in the URL, an end-user cannot accidentally get a personalized page intended for somebody else. As you mentioned, you could prevent an intermediate cache from caching the page with a Cache-Control: private, but you then need to trust that the cache is HTTP/1.1 compliant. If anybody is afraid of using Amazon now, I believe David mentioned in a previous post that Amazon switches to SSL (and a new session id) whenever you deal with data they feel should be kept private. :-) - Kyle
Cookie authentication
This may seem off subject but, If you bare with me, I don't think it is. I am interested in using the cookie based system referred to in the programming the apache api book but oftend wonder this. Can you count on everyone to use cookies. It seems that some surfers are afraid of cookes are that maybe some browsers don't even handle them. I wrote a mod perl script to do member traking in my members site to see what pages were being viewed the most and used cookies also to make sure that more than one person was not using a particular username and find that some people either arn't using a browser that uses cookies or do not have them turned on. What are your thoughts on this because I thought of implementing the token cookie system but did not because I was afraid I would loose members that did not have or use this feature. Can you legimately require surfers to have cookies turned on and do you know of many sites that do this successfully without loosing members. Thanks John Michael
RE: Cookie authentication
John, We rolled out cookie authentication (Auth::Cookie)for our secured support website around Jan 2001and we never received one complaint (and our people complain about everything:) It seems you can't do anything online without having cookies turned on ( yahoo, bankone, huntington, ebay, etrade ) and I think internet users have accepted this. AlthoughMicrosoft is doing it's best to screw this up: http://abcnews.go.com/sections/scitech/TechTV/TechTV_IEflaw011109.html fix: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS01-055.asp Charles -Original Message-From: John Michael [mailto:[EMAIL PROTECTED]]Sent: Thursday, November 15, 2001 3:02 PMTo: [EMAIL PROTECTED]Subject: Cookie authentication This may seem off subject but, If you bare with me, I don't think it is. I am interested in using the cookie based system referred to in the programming the apache api book but oftend wonder this. Can you count on everyone to use cookies. It seems that some surfers are afraid of cookes are that maybe some browsers don't even handle them. I wrote a mod perl script to do member traking in my members site to see what pages were being viewed the most and used cookies also to make sure that more than one person was not using a particular username and find that some people either arn't using a browser that uses cookies or do not have them turned on. What are your thoughts on this because I thought of implementing the token cookie system but did not because I was afraid I would loose members that did not have or use this feature. Can you legimately require surfers to have cookies turned on and do you know of many sites that do this successfully without loosing members. Thanks John Michael
Re: Cookie authentication
On Thu, 15 Nov 2001, John Michael wrote: Date: Thu, 15 Nov 2001 14:02:04 -0600 From: John Michael [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Cookie authentication This may seem off subject but, If you bare with me, I don't think it is. I am interested in using the cookie based system referred to in the programming the apache api book but oftend wonder this. Can you count on everyone to use cookies. It seems that some surfers are afraid of cookes are that maybe some browsers don't even handle them. I wrote a mod perl script to do member traking in my members site to see what pages were being viewed the most and used cookies also to make sure that more than one person was not using a particular username and find that some people either arn't using a browser that uses cookies or do not have them turned on. What are your thoughts on this because I thought of implementing the token cookie system but did not because I was afraid I would loose members that did not have or use this feature. Can you legimately require surfers to have cookies turned on and do you know of many sites that do this successfully without loosing members. Thanks John Michael John, For what might be called premium services, I believe it is justified to require user's to accept cookies. I've used cookie-based authentication on several sites that offer some special to the user, like a private view of data or something else that requires they identify themselves. That being the *only* thing I've ever required of users (e.g, I *never* require something like JavaScript, only using it to enhance the UI but always with alternatives), I think it's OK. If they don't want to use cookies, they don't have to use the service I'm providing. That being said, some people might not accept frivolous cookies myself just for reading a web page, but I'd imagine most don't even monitor such things. ky
Re: Cookie authentication
Hello, CDIt seems you can't do anything online without having cookies turned on CD(yahoo, bankone, huntington, ebay, etrade ) and I think internet users CDhave accepted this. Not those clever European governmental folks, though. http://www.vnunet.com/News/107416 http://news.zdnet.co.uk/story/0,,t269-s2099128,00.html http://news.bbc.co.uk/hi/english/sci/tech/newsid_1653000/1653907.stm http://www.cnn.com/2001/TECH/internet/11/14/eu.spam.cookies.idg/ Methinks there is a need to write a transparent store cookies on URL module. I seem to recall at least one major Apache module having an option to use URL-based authentication instead of cookie-based... but I can't seem to find that from a cursory perusal of CPAN. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Cookie authentication
I seem to recall at least one major Apache module having an option to use URL-based authentication instead of cookie-based... but I can't seem to find that from a cursory perusal of CPAN. Apache::ASP does this. - Perrin
RE: Cookie authentication
Before I read an article about the European Union POV of cookies I hadn't really thought of myself as someone who would violate basic human rights. I guess this goes to show that one has to be ever vigilant in today's society. The resolution banning cookies did not pass the EU Parliament, this time. A ban on unsolicited SMS messages like those sent via a cell phone was approved (http://www.cnn.com/2001/TECH/internet/11/14/eu.spam.cookies.idg/index.html) . We use cookies to track session state here and have had no complaints. I don't think it is wrong to require the use of cookies. Of course to make everyone happy you could backup cookies with some sort of non-cookie based state management, like a URL encoded sessionid or a hidden form field passed in every page. Like everything, your mileage will vary with any implementation you choose to use. --Joe Breeden --- If it compiles - Ship It! -Original Message- From: Andrew Ho [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 2:17 PM To: Charles Day Cc: John Michael; mod_perl List Subject: Re: Cookie authentication Hello, CDIt seems you can't do anything online without having cookies turned on CD(yahoo, bankone, huntington, ebay, etrade ) and I think internet users CDhave accepted this. Not those clever European governmental folks, though. http://www.vnunet.com/News/107416 http://news.zdnet.co.uk/story/0,,t269-s2099128,00.html http://news.bbc.co.uk/hi/english/sci/tech/newsid_1653000/1653907.stm http://www.cnn.com/2001/TECH/internet/11/14/eu.spam.cookies.idg/ Methinks there is a need to write a transparent store cookies on URL module. I seem to recall at least one major Apache module having an option to use URL-based authentication instead of cookie-based... but I can't seem to find that from a cursory perusal of CPAN. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Cookie authentication
On 15 Nov 2001, at 12:16, Andrew Ho wrote: CDIt seems you can't do anything online without having cookies turned on CD(yahoo, bankone, huntington, ebay, etrade ) and I think internet users CDhave accepted this. Methinks there is a need to write a transparent store cookies on URL module. I seem to recall at least one major Apache module having an option to use URL-based authentication instead of cookie-based... but I can't seem to find that from a cursory perusal of CPAN. http://perl.apache.org/guide/modules.html#Apache_Session_Maintain_sessi I used Apache::Session and HTML::Template to embed the session_id in the url in a recent job site.I planned this before I built the site (all templates built according to the plan :). No problems there. There were no static pages. I find cookies are used when one has a site static/dynamic pages. How do you keep a user if they click to a static page? I don't know. But one should always check if a user has cookies turned on. I recall an internal site I did for FedEx a few years back and I used cookies for it as it was before my mod_perl use. Well it turned out that the vice-president had cookies turned off. He was not a customer we wanted to ignore:) Peter A government that robs Peter to pay Paul can always depend upon the support of Paul. -- George Bernard Shaw
RE: Cookie authentication
Here we insert a session id on all requests, with Apache::Session whether the request is for a static or dynamic page and have a TransHandler to strip the session id and insert it into %ENV which seems to work for us. With this approach we don't necessarily need cookies, but verifying if a user is who the session was originally assigned to without a cookie is really impossible. At least to me with the limited amount of brain time I have put into it. Using some algorithm consisting of the end-users IP and some random number is OK until users behind the same NAT device try to steal each others session. Using the cookie is a way to verify that a user is the owner of the session id. I hope this doesn't sound like the ramblings of a mad man, but in general I think SESSION cookies are ok and you should feel ok using them. I hope this helps a little. --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 4:25 PM To: mod_perl List Subject: Re: Cookie authentication On 15 Nov 2001, at 12:16, Andrew Ho wrote: CDIt seems you can't do anything online without having cookies turned on CD(yahoo, bankone, huntington, ebay, etrade ) and I think internet users CDhave accepted this. Methinks there is a need to write a transparent store cookies on URL module. I seem to recall at least one major Apache module having an option to use URL-based authentication instead of cookie-based... but I can't seem to find that from a cursory perusal of CPAN. http://perl.apache.org/guide/modules.html#Apache_Session_Maint ain_sessi I used Apache::Session and HTML::Template to embed the session_id in the url in a recent job site.I planned this before I built the site (all templates built according to the plan :). No problems there. There were no static pages. I find cookies are used when one has a site static/dynamic pages. How do you keep a user if they click to a static page? I don't know. But one should always check if a user has cookies turned on. I recall an internal site I did for FedEx a few years back and I used cookies for it as it was before my mod_perl use. Well it turned out that the vice-president had cookies turned off. He was not a customer we wanted to ignore:) Peter A government that robs Peter to pay Paul can always depend upon the support of Paul. -- George Bernard Shaw
Re: Cookie authentication
Here we insert a session id on all requests, with Apache::Session whether the request is for a static or dynamic page and have a TransHandler to strip the session id and insert it into %ENV which seems to work for us. With this approach we don't necessarily need cookies, but verifying if a user is who the session was originally assigned to without a cookie is really impossible. At least to me with the limited amount of brain time I have put into it. Using some algorithm consisting of the end-users IP and some random number is OK until users behind the same NAT device try to steal each others session. Using the cookie is a way to verify that a user is the owner of the session id. Cookies are very easy to fake and modify on the client side. If you want to verify that a user is returning a session ID you sent him without modifying it you should use a MAC, like the ticket access stuff in the Eagle book. - Perrin
Re: Cookie authentication
At 02:02 PM 11/15/01 -0600, John Michael wrote: This may seem off subject but, If you bare with me, I don't think it is. I am interested in using the cookie based system referred to in the programming the apache api book but oftend wonder this. Can you count on everyone to use cookies. Sometime back I wrote a module based on Apache::AuthCookie called Apache::AuthCookieURL that uses cookies, or falls back to munged URLs if cookies were not enabled. It's on CPAN. I wrote it for a site where people come in from public libraries. The requirement was that it had to do sessions even if cookies were disabled (as it was common for the public libraries to have cookies disabled). It's been a while since I looked at it. I had added a way to disable the authen requirement for areas of the site (or everywhere), so it could be used just for dealing with sessions. Do be careful about session hijacking. Bill Moseley mailto:[EMAIL PROTECTED]
Re: Cookie authentication
Thanks. I did not know that you could verify that someone has cookies turned on. Can you point me to where i can find out how to do this? Is there a variable that you can check? JM - Original Message - From: [EMAIL PROTECTED] To: mod_perl List [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 4:24 PM Subject: Re: Cookie authentication On 15 Nov 2001, at 12:16, Andrew Ho wrote: CDIt seems you can't do anything online without having cookies turned on CD(yahoo, bankone, huntington, ebay, etrade ) and I think internet users CDhave accepted this. Methinks there is a need to write a transparent store cookies on URL module. I seem to recall at least one major Apache module having an option to use URL-based authentication instead of cookie-based... but I can't seem to find that from a cursory perusal of CPAN. http://perl.apache.org/guide/modules.html#Apache_Session_Maintain_sessi I used Apache::Session and HTML::Template to embed the session_id in the url in a recent job site.I planned this before I built the site (all templates built according to the plan :). No problems there. There were no static pages. I find cookies are used when one has a site static/dynamic pages. How do you keep a user if they click to a static page? I don't know. But one should always check if a user has cookies turned on. I recall an internal site I did for FedEx a few years back and I used cookies for it as it was before my mod_perl use. Well it turned out that the vice-president had cookies turned off. He was not a customer we wanted to ignore:) Peter A government that robs Peter to pay Paul can always depend upon the support of Paul. -- George Bernard Shaw
RE: Cookie authentication
See it always pays to read the Eagle book several times - in this case pages 213-218. Excuse my question if it seems dumb I'm not 100% on NAT and proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to be user for the MAC. It also suggests to use the remote IP address as one of those fields. 3 Compute the MAC via a MD5 hash and store in the clients browser. 4 On subsequent visits recompute the MAC and verify it matches the original stored MAC. How is this reliable in a situation where many similarly configured computers are behind a NAT/Proxy and one of the users try to steal someone else's session by getting their cookie/session_id info? Thanks for the help, --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 4:52 PM To: Joe Breeden; mod_perl List Subject: Re: Cookie authentication Here we insert a session id on all requests, with Apache::Session whether the request is for a static or dynamic page and have a TransHandler to strip the session id and insert it into %ENV which seems to work for us. With this approach we don't necessarily need cookies, but verifying if a user is who the session was originally assigned to without a cookie is really impossible. At least to me with the limited amount of brain time I have put into it. Using some algorithm consisting of the end-users IP and some random number is OK until users behind the same NAT device try to steal each others session. Using the cookie is a way to verify that a user is the owner of the session id. Cookies are very easy to fake and modify on the client side. If you want to verify that a user is returning a session ID you sent him without modifying it you should use a MAC, like the ticket access stuff in the Eagle book. - Perrin
Re: Cookie authentication
At 05:20 PM 11/15/01 -0600, John Michael wrote: Thanks. I did not know that you could verify that someone has cookies turned on. Can you point me to where i can find out how to do this? Is there a variable that you can check? You set a cookie and do a redirect (if you need the cookie right away). If it comes back with a cookie then they are enabled. Bill Moseley mailto:[EMAIL PROTECTED]
Re: Cookie authentication
Excuse my question if it seems dumb I'm not 100% on NAT and proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to be user for the MAC. It also suggests to use the remote IP address as one of those fields. 3 Compute the MAC via a MD5 hash and store in the clients browser. 4 On subsequent visits recompute the MAC and verify it matches the original stored MAC. How is this reliable in a situation where many similarly configured computers are behind a NAT/Proxy and one of the users try to steal someone else's session by getting their cookie/session_id info? Don't use the IP address in the cookie, just generate a unique ID of your own. I suggest using mod_unique_id. - Perrin
Re: Cookie authentication
I don't think that really solves Joe's proposed problem. Joe wants to ensure that the cookie is coming back from the client he sent it to. If you generate a unique ID, someone can sniff the network, grab the cookie, and send it as their own. The Eagle book does half-heartedly suggest IP address as being a way to ensure the cookie's source, but that's not reliable in these days of proxies and NAT. The only answer, I think, is to only send the cookie over an SSL connection, so that it can not be sniffed. Remember that there is an attribute you can set on the cookie that tells the browser to only send the cookie over an SSL connection. Spend some time playing with Amazon and see how they handle cookies. They appear to have cookies that get sent over every connection which they use to personalize your web pages (not necessarily sensitive info). However, as soon as you try to purchase something or go to a sensitive area, you are asked to sign-in and sent a cookie over https. From: Perrin Harkins [EMAIL PROTECTED] Date: Thu, 15 Nov 2001 18:40:03 -0500 To: Joe Breeden [EMAIL PROTECTED], mod_perl List [EMAIL PROTECTED] Subject: Re: Cookie authentication Excuse my question if it seems dumb I'm not 100% on NAT and proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to be user for the MAC. It also suggests to use the remote IP address as one of those fields. 3 Compute the MAC via a MD5 hash and store in the clients browser. 4 On subsequent visits recompute the MAC and verify it matches the original stored MAC. How is this reliable in a situation where many similarly configured computers are behind a NAT/Proxy and one of the users try to steal someone else's session by getting their cookie/session_id info? Don't use the IP address in the cookie, just generate a unique ID of your own. I suggest using mod_unique_id. - Perrin
Re: Cookie authentication
The aim of the cookie example in the eagle book is a bit more than just authentication. Most of the answers here to use a session ID here are quite right for most purposes, but the code in the eagle book offers to store information on the client side with the security of a signature. Its NOT just authentication. This has some advantages for applications which are on more than one server, which have to use an expensive central DB lookup and/or are not connected at all, since the only thing to share is the secret. This is quite perfect of a decentral intranet. In my last project i did a LARGE single sign on implementation over loads of applications which used those cookies for authentication and for getting the DN and preferred language out of the cookie, all w/o any need of further DB lookups or LDAP requests. Since the logic is quite simple its also possible to parse/check the cookie in tomcat or any other web application and leave the logon to a central server. The secret is then shared over an https connection. By rotating the secret one gets a certain level of security (and automated logout). More or less the eagle book offers the full implementation of a single sign on solution with some nice features already implemented, missing is the secret rotation with more than one secret and some intelligent caching of it (just retrieve anew on a failed signature check e.g. which is in some other cookie module on CPAN?). What its not in my opinion is a simple authentication, its to complicated for that. A simple session ID suffices - and with session IDs there are all those nice things to play as putting them into the DNS, doing some url rewriting with mod_rewrite or just putting them in every URL automagically with some class. I did not know that you could verify that someone has cookies turned on. Can you point me to where i can find out how to do this? Is there a variable that you can check? The ticketlogin example in the eagle book does this by setting a redirect_url cookie before redirecting you to the login page, if this cookie is missing there the - sorry youve no cookies please enable them - page is shown. [EMAIL PROTECTED]
