Key-based secure network user states

Details Key-based secure network user states Key-based secure network user states

2001-10-31

2003-07-29

Peeso, Thomas R. (Department: 2132)

Electrical computers and digital processing systems: support

Multiple computer communication using cryptography

Protection at a particular protocol layer

C713S168000

Reexamination Certificate

active

06601169

ABSTRACT:

FIELD OF INVENTION
The present invention relates to key-based secure network user states.
BACKGROUND OF THE INVENTION
Computer networks, such as the Internet, are well known in the art, and may be based on the HTTP protocol. Because HTTP is a stateless, or non-persistent, protocol, it is not possible for such servers to differentiate between visits by a specific user unless the server can somehow mark the user to create a state or logical nexus between the server and the user. Thus, each visit by an Internet user to a website is unique, in that the website does not generally know the identity of the user and/or other information about the user, with the exception of a few details such as browser type, IP address, etc. It should be noted, however, that when a user has a fixed IP address, the user's identity or information about the user may be known by logical relation to a database. But, since the majority of Internet users are assigned dynamic IP addresses each time they connect to the Internet, reliance on a user's IP address to create a state is problematic since their IP addresses may change each time a user connects to the Internet.
To remedy the problem of HTTP's stateless nature, cookies have been introduced for the specific purpose of creating states. They may be temporary, in which case they are stored only in memory; or persistent, in which case they are stored in a file, typically on a hard drive, for period of time measured by an expiration date field of a cookie. A cookie may be thought of as a data structure stored in the memory or on the storage device of a user's computer, with the cookie containing data, such as the user's identity and/or other information about the user for the purpose of creating a state between the web server and the user. Thus, when a user visits a particular website, a cookie stored on a user's computer may be sent from the user's computer over the Internet to the web server, which then extracts the data from the cookie, processes the data and therewith creates a state. For example, a user's name may be stored in a cookie and when that user visits a particular website, the data contained in the cookie may be sent to the server and used to identify the user.
More specifically and typically, when a user first visits an Internet website, a web server associated with the website may send a cookie to the user, which is then stored in the memory or on the hard drive of a user's computer, in conjunction with the user's Internet browser software. When the user subsequently visits the website, the cookie may be sent back to the server so that the user's identity and/or other information about the user that is stored in the cookie may be known to the server via the data contained in the cookie, such that a state between the user and the web server is created.
However, the use of cookies has created a significant problem relating to user privacy. Because these cookies are stored on a user's computer, especially when on a hard drive, other servers may potentially access the cookies of other servers and extract and read the user's identity and/or other information about the user that is stored in those cookies. Such extracting and reading is considered by many as an invasion of the user's privacy.
An attempted solution to protect the privacy of Internet users is provided in RFC 2109, HTTP STATE MANAGEMENT MECHANISM, having a publication date of February, 1997. This solution involves a domain restriction on reading and writing cookies, which must be implemented in conjunction with a user's particular browser software for effectuation. For example, a web server associated with the domain thissite.com may write a cookie having the domain value .thissite.com. According to the domain restriction, this cookie may only be read by a server within the specified domain and related sub-domains. For example, while the servers at thissite.com, L1.thissite.com, L2.L1.thissite.com, etc. may read the cookie having the domain value .thissite.com, the servers othersite.com, L1.othersite.com, L2.L1.othersite.com may not read the cookie having the domain value .thissite.com. While this methodology appears adequate on its face, practically it is not. It suffers from at least four deficiencies.
A first problem is that this methodology requires software vendors producing browser software to implement this domain restriction. While mainstream vendors may attempt to comply, other smaller vendors may not. Thus, failed compliance may create a hole through which a user's privacy may be invaded via the unauthorized access of cookies despite the existence of a domain restriction.
A second problem is that despite attempted compliance, one or more bugs or exploits in the browser software may exist and be exploited; thus, also creating a hole through which a user's privacy may be invaded. For example, as identified in the article, COOKIE EXPLOIT, published by COOKIE CENTRAL™ on Dec. 14, 1998, such a bug did exist and a hole was potentially created and exploited. The bug allowed cookies to be shared between unrelated domains, despite the domain restriction implemented by some if not all cookie-based Internet browser applications. Basically, by concatenating an ellipsis (“ . . . ”) at the end of the domain value set in a cookie, other unrelated servers were able to read those cookies. Such a domain value may be “.thissite.com . . . ” According to this article, at the time of publication all mainstream Internet browser applications were vulnerable to this exploit. Indeed, the article goes on to assert that the most popular Internet browser applications, INTERNET EXPLORER and NETSCAPE, were known to be vulnerable on the WINDOWS, MAC and LINUX platforms. Thus, the domain restriction was nullified and servers participating in the exploitation of this bug were able to access cookies from domains outside their own domain, which is exactly what the domain restriction of RFC 2109 was intended to prevent. Thus, the privacy of Internet users benefiting from the use of cookies was unequivocally subject to invasion.
A third problem is that the cookies stored on a user's hard drive may be viewed by a person who is physically using the user's computer. The location and naming of cookie files stored on a user's hard drive are generally known or discoverable by those skilled in the art. For example, it is well known in the art that the browser software application NETSCAPE™ that is developed and distributed by NETSCAPE COMMUNICATIONS CORPORATION™ generally stores cookies in a user directory in a single file named “cookie.txt”. One physically using a user's computer may open such a file with a simple text editor and directly view and/or print the data contained in all cookies present, which is clearly an invasion of the user's privacy.
A fourth problem is that under certain conditions servers may directly read cookie files outside the domain restriction set in the cookies. It is generally known in the art that where a user's Internet browser software is configured to enable JAVA script, specific files having a known name (such as, “cookies.txt”) may be directly accessed, read and transmitted to some location over the Internet by a “virus” embedded within such JAVA script. Additionally, a devious program may also contain such a virus that can do the same. Many Internet users download and run executable programs from the Internet knowingly and unknowingly risking the infection of a virus; and therefore, this risk is present and real. The location of cookie files are generally known or discoverable to those ordinarily skilled in the art. Indeed, such a virus may execute a “directory” command to obtain the names of files and directories on a hard drive; for example, a directory listing of files and directories in the “c:\windows\Temporary Internet Files” directory or “c:\Program Files\Netscape\Users” directory. The former may produce cookie files produced by INTERNET

Affiliated with

Also associated with

Rating

Key-based secure network user states does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Key-based secure network user states, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Key-based secure network user states will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3010648