[plug] Cookies

[Bret Busby]

The mailing list has various ISP's, website developers, and security
people.

I have complained to a company, about the use of cookies in the website,
as the website is such that it requires cookies to be enabled, to use
the website. Access to the website, is password protected, and, using
the website, involves travelling from web page to web page, and can
involve ten, or, tens of web pages, in a login session.

I avoid allowing cookies.

I have accessed a bank password-protected, 128-bit encrypted, website,
involving travelling between web pages (uses javascript, I believe, with
the security feature being provided by an applet), which has no need for
cookies. This facility works with Netscape 4.x, with 40 bit encryption
capability provided by the earlier versions (from 4.08 onward).

The response that I got from this company, most of which response
appears below, indicates that the use of cookies, is the only efficient
way to allow password-protected website access for e-commerce.

I know that the way that TWIG is setup, it uses cookies, in its
password-protected access.

I want to know what people on the list think about the proposition that
the only efficient way to allow password-protected access to an
e-commerce website, is via the use of cookies.

Thanks in anticipation, and, I apologise in advance, if anyone thinks
this is too far off-topic.
 
-- 

Bret Busby

......................................
"So once you do know what the question actually is, you'll know what the
answer means."
 - Deep Thought, Chapter 28 of The Hitchhiker's Guide to the Galaxy
 - Douglas Adams, 1988 
......................................
Cookies are used to identify a user and a session over the sessionless
nature of http (Web browsing). Without identification for every server
request the only way to maintain session based information is one of the
following three methods
     HTTP Header information (Authentication challenge/response).  As
used
     in the previous version of the website.  
     For this to be secured, all interactions with the server
     must use SSL as the usersname and password are transferred in EVERY
     click.  This has obvious performance issues:  for example using
40bit
     encryption this makes all conversations between the browser and the
     server 8 times larger.(1 byte in encrypted into 40bits=8bytes). 
Very
     few sites continue to use this method.
     URL re-writing - used by a number of sites. Some sites even revert
to
     this if the users don't accept cookies.  This method allows for
users
     that don't use cookies however it has serious security implications
     for both the server and the users.  This method writes the session
ID
     into the URL, meaning that session ID is immediately available in
     plain text, whether the request is in SSL or not.  Other security
     implications are that URL's are cached by proxy servers and on
     individual computers, thereby relying on the security of 3rd party
     computers (the proxy) to secure the users information.  Other
     inconveniences of this method include bookmarking. Users are unable
to
     bookmark pages that use URL re-writing as the sessionid will be
stored
     in the URL, and subsequent re-loads mostly result in invalid
session
     errors.
     Cookies.  There are 2 types of cookies, a) persistent (stored
     physically on the users computer and available in later sessions)
and
     b) session based (removed/lost when the browser is closed). Cookies
     are not stored in proxies.  Well written sites also do not include
     sensitive information in the cookies.  This website uses session
based
     cookies, which are not stored on the local system but kept in the
     memory of the currently running browser.  This provides the most
     convenient method of identifying a returning visitor (remember http
is
     sessionless so going to a home page and then clicking a link
indicates
     2 visits to the site for the server).

In the past, cookies were perceived as a security threat. This was
mostly
founded by skeptics, and particularly aimed towards corporations such as
Microsoft, whose programs have access to the hard drive.  It is a simple
matter for one of these programs to locate persistent cookies, and read
the
file contents, and then send the details via registration and other
processes.  Some facts about cookies:
        Browsers will only send cookies back to the site that sent them
        originally.
        Servers cannot request cookies to be sent to them, they can only
        accept what the browser sends.

The advent of session based cookies (such as those used by this website)
means that
many of these previous security concerns, are no longer a problem and
many
browsers such as Internet Explorer 5.0+ allow users to specify which
types
of cookies they will or will not accept.  As session based cookies are
not
stored on the users hard drive, they are not available to any malicious
programs that may be on a users computer.

This web site sends 2 session based cookies, neither cookie contains
sensitive information. One cookie contains a token used by the system
called serverName, to identify how requests from the user should be
processed, and the other called sessionid, contains a randomly generated
string to identify a unique session on the site.  To break into a users
session, BOTH cookies would be required to match in their unique
combination, and neither cookie is valid more than 30 minutes after a
user
has last used the site. (this website's sessions time out after 30
minutes for added
security).

Most modern technology e-commerce sites use cookies for the same purpose
as
this website, some of these sites still use persistent cookies not
session based
cookies, some examples of these are:
     Amazon.com - uses persistent cookies for user identification and
     sessions that don't time out.
     CDNow.com -- uses persistent cookies for user identification and
     sessions that don't time out.
     Greengrocer.com.au - uses persistent cookies for sessions.
     dstore.com.au - uses persistent cookies for sessions that don't
time
     out.
     wishlist.com.au - uses both persistent cookies for sessions and
     session based cookies for session information.
     kmart.com.au - uses persistent cookies for sessions that don't time
     out.

As you can see from the list above most e-commerce site use cookies. If
you
use Internet explorer and remove all the cookies from your cookie
directory, then modify your securtiy settings to prompt for all cookies
(both session based and persistent) you can see that not only do all
these
sites use cookies, but they often use a large number of cookies that are
persistent.
......................................