Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS8196189 B2
Publication typeGrant
Application numberUS 12/813,708
Publication dateJun 5, 2012
Filing dateJun 11, 2010
Priority dateFeb 26, 2002
Also published asUS7228417, US7765584, US20030163737, US20070169181, US20100251347
Publication number12813708, 813708, US 8196189 B2, US 8196189B2, US-B2-8196189, US8196189 B2, US8196189B2
InventorsJames Roskind
Original AssigneeAol Llc
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Simple, secure login with multiple authentication providers
US 8196189 B2
Abstract
A secure distributed single-login authentication system comprises a client and a server. The client collects authentication credentials from a user and tests credentials at a variety of potential authentication servers to check where the login is valid. It combines a password with a time-varying salt and a service-specific seed in a message digesting hash, generating a first hash value. The client sends the hash value with a user name and the time-varying salt to a selected server. The server extracts the user name and looks up the user name in the server's database. If an entry is found, it retrieves the password, performing the same hash function on the combination of user name, service-specific seed, and password to generate a second hash value, comparing the values. If the values match, the user is authenticated. Thus, the system never reveals the password to authentication agents that might abuse the information.
Images(7)
Previous page
Next page
Claims(13)
1. An apparatus for distributed authentication comprising:
a plurality of participating authentication servers communicatively coupled in a network;
at least one client programmed for performing a hash operation on a group of identification elements extracted via a client to generate a first hash value and sending said first hash value to a selected authentication server;
wherein at least one of said participating authentication servers is communicatively coupled to said at least one client via a telecommunications network, each of said participating authentication server being programmed for:
performing a same hash operation on a same group of identification elements extracted via at least one participating authentication server to generate a second hash value; and
comparing said first hash value and said second hash value, and distributing a matching result of said two hash values which indicates a successful authentication to any other participating authentication servers without central control.
2. The apparatus of claim 1, wherein said group of identification elements comprises:
entered user name and password; and
a service specific seed unique to an authentication server selected from said at least one authentication server.
3. The apparatus of claim 2, wherein said group of identification elements further comprises:
a time stamp generated at said client when said user name and password were entered.
4. An apparatus for distributed authentication comprising:
at least one client programmed for:
taking and parsing an entered user name and password;
combining said password and a service specific seed unique to a selected participating authentication server;
applying a hash algorithm to said combination to generate a first hash value;
finding an address representing said selected participating authentication server; sending a data packet to said selected authentication server, said data packet comprising said user name and said first hash value; and
iterating said at least one authentication server to find a correct authentication server; and
a plurality of participating authentication servers communicatively coupled in a network; wherein
at least one of said plurality of participating authentication servers is communicatively coupled to said at least one client via said network, each of said plurality of authentication servers being programmed for:
extracting said user name and said first hash value from said data packet;
checking and retrieving said user's password from said selected participating authentication server's database;
combining said retrieved password and said service specific seed unique to said selected participating authentication server;
applying said hash algorithm to said combination to generate a second hash value;
comparing said first hash value and said second hash value, wherein a matching result of said two hash values indicates a successful authentication; and
caching said positive authentication result and distributing said positive authentication result to any other participating authentication server without central control.
5. In a computerized network comprising at least one client and a plurality of participating authentication servers communicatively coupled by said network, said client and at least one of said participating authentication servers being communicatively coupled to each other via said network, a distributed authentication system comprising:
a client
wherein said client comprises computer-readable code executing on a processing element for:
taking and parsing an entered user name and password;
means for generating a time stamp;
combining said password and a service specific seed unique to a participating authentication server selected from said plurality of participating authentication servers;
applying a hash algorithm to said combination and said time stamp to generate a first hash value;
finding an address representing said selected participating authentication server;
sending a data packet to said selected participating authentication server, said data packet comprising said user name, said time stamp, and said first hash value; and
iterating said list plurality of participating authentication servers to find a correct participating authentication server; and
wherein at least said selected participating server comprises computer-readable code executing on a processing element for:
extracting said user name, said time stamp, and said first hash value from said data packet;
checking and retrieving said user's password from said selected participating authentication server's database;
combining said time stamp, said retrieved password and said service specific seed unique to said selected participating authentication server;
applying said hash algorithm to said combination completed in said participating server portion to generate a second hash value;
comparing said first hash value and said second hash value, wherein a matching result of said two hash values indicates a successful authentication; and
means for caching said positive authentication result and distributing said positive authentication result to any participating authentication server without central control.
6. The distributed authentication system of claim 5, wherein said hash algorithm is a message digesting (MD) algorithm or its equivalent.
7. The distributed authentication system of claim 5, wherein said service specific seed is a domain name of said selected participating authentication server.
8. The distributed authentication system of claim 5, wherein said computer-readable code for finding an address representing said selected participating authentication server comprises:
computer-readable code for looking up a local mapping list; and
computer-readable code for consulting to a domain name system (DNS).
9. In a computerized network which is registered with a unique domain name, said network comprising at least one client and a plurality of participating authentication servers, said client and said authentication servers being communicatively coupled to each other via said network, each of said participating authentication servers having a fully qualified domain name (FQDN) which is a local host name with said unique domain name appended, a distributed authentication system for providing distributed authentication service, wherein a given user enters a global user identification (GUID) and a password for authentication to be carried out at a target participating authentication server, said GUID comprising a user name, a delimitation symbol, and a domain which is same as said local host name of said target authentication server, said distributed authentication system comprising:
a client,
wherein said client comprises computer-readable code executing on said client on a processing element for:
parsing an entered GUID and extracting said domain therefrom;
appending said unique domain to said domain to form a fully qualified name (FQDN) for said target authentication server;
translating said FQDN to an address representing said target participating authentication server;
generating a time stamp;
means for combining said password and a service specific seed unique to said target participating authentication server;
applying a hash algorithm to said combination and said time stamp to generate a first hash value; and
sending a data packet to said target participating authentication server,
said data packet comprising said first hash value, said user name, and said time stamp;
wherein said participating authentication server comprises computer-readable code executing on a processing element for:
extracting said first hash value, said user name, and said time stamp from said data packet received from said client;
checking and retrieving said user's password from said target participating authentication server's database;
combining said time stamp, said retrieved password, and said service specific seed unique to said target participating authentication server;
applying said hash algorithm to said combination to generate a second hash value;
comparing said first hash value and said second hash value, wherein a matching result of said two hash values indicates a successful authentication; and
caching said positive authentication result and distributing said positive authentication result to any other participating authentication server without central control.
10. distributed authentication system of claim 9, wherein said hash algorithm is a message digesting (MD) algorithm or its equivalent.
11. The distributed authentication system of claim 9, wherein said service specific seed is a domain name of said target participating authentication server.
12. The distributed authentication system of claim 9, wherein said computer-readable code for translating said FQDN comprises:
computer-readable code for looking up said FQDN from a local mapping list; and
computer-readable code for looking up said FQDN from a domain name system (DNS).
13. The distributed authentication system of claim 9, further comprising:
computer-readable code executing on a processing element for automatically mapping any unrecognized FQDN into a default authentication server which carries out authentication on said user's authentication request.
Description
CROSS REFERENCE TO RELATED APPLICATIONS

This Application is a continuation of U.S. patent application Ser. No. 11/566,648, filed Dec. 4, 2006, now U.S. Pat. No. 7,765,584 which is a continuation of U.S. patent application Ser. No. 10/291,281, now U.S. Pat. No. 7,228,417, filed Nov. 7, 2002, which is a continuation-in-part of U.S. patent application Ser. No. 10/086,104, now U.S. Pat. No. 7,260,836, filed Feb. 26, 2002, all of which are incorporated herein in their entirety by this reference thereto.

TECHNICAL FIELD

This invention relates generally to user authentication technology used in an Internet-based distributed network system. More particularly, this invention relates to a system and method for authenticating a user without exposing his password to any participant of a network with multiple-authentication providers.

BACKGROUND OF THE INVENTION

The explosive growth of the Internet is changing the ways in which we communicate, conduct business, and pursue entertainment. A few years ago, electronic commerce (E-commerce) was just an interesting concept. By 1999, however, it had become the hottest thing around. Today, not only are consumers buying an enormous volume of goods or services over the Internet, but the business-to-business E-commerce has taken off as well.

The basic cell of E-commerce is an electronic transaction, which requires a buyer or user to fill out one or more electronic forms on screen and click a button named “send”, “buy” or “submit”, etc. To complete such an electronic transaction, a user has to go through an authentication process. In other words, the user must provide the seller or service provider with some information such as his or her personal identification, contact information, or even financial information. The authentication process may take from several minutes to hours. Since each seller or service provider maintains its own authentication server and database, millions of seller and service providers might share thousands of millions of consumers or users. Some of the consumers or users might be required to go through the same or similar authentication process again and again if they have transactions with many sellers or service providers. This repetitive authentication not only wastes consumers' precious time, but also burdens the sellers or service providers because they have to expand their databases to keep detailed authentication information for a growing number of users. This situation brings forth a technical need to create a universal, unified single-login infrastructure wherein a specific user may be authenticated once for all and the authentication result is widely recognized by a large number of sellers or service providers.

In responding to that need, several approaches have been developed. For example, Microsoft Corporation has introduced a “.NET Passport” single sign-in system. With “.NET Passport”, a user doesn't need to register a member name and password at each new site he or she visits. The user may simply use his or her e-mail address and password that registered as his or her “.NET Passport” to sign in to any participating site or service. The information the user registers with “.NET Passport” is stored online, securely, in the “.NET Passport” database as the user's “.NET Passport profile.” When the user signs in to a “.NET Passport” participating site by typing his or her e-mail address and password in the “.NET Passport” sign-in box, “.NET Passport” confirms that (1) the e-mail address he or she typed is registered with “.NET Passport”, and (2) the password he or she typed is correct. “.NET Passport” then notifies the site that the user has provided valid “sign-in credentials” and he or she is given access to the participating site. Once the user signs in to one “.NET Passport” participating site during an Internet session, he or she can sign in to others simply by clicking the “.NET Passport” sign-in button on each site. Another example is America Online Inc.'s “Screen Name Service” system, which provides free service allowing anyone with a “Screen Name” to easily and securely register at a variety of Web sites. Similar to Microsoft's “.NET Passport” system, the “Screen Name Service” eliminates a user's need to remember multiple names and passwords for all the places he or she visits on the Web. With the “Screen Name Service” system, each user has a “My Profile”, which stores the user's personal information used to make registering at sites across the Web simple and secure. When the user registers at a participating Web site using the service, he or she has the opportunity to choose which fields of information stored by AOL, if any, he or she would like to share with that site. No information will be shared with any Web site without the user's explicit permission. When the user agrees to share certain information with a participating site, that information is conveyed to the Web site at which he or she is registering. Another feature is that the user is provided with a “My Site List”, which is an effective way to manage personal information because it shows the user with which sites he or she has registered with using the service. The user can view the privacy policy of a site to see how it uses information it knows about the user. The user can also decide if he or she would like to be signed into the site without being prompted and if the site should be updated with information if “My Profile” changes.

The common characteristic of these approaches is that they implement a centralized solution for authentication and authentication information management.

Undoubtedly, the centralized solution may overcome the repetitive authentication and repetitive storage problems that exist in the scattered, disorganized situation. However, the centralized solution has three major disadvantages. First, in a centralized authentication system, because all the login requests go to a central authentication server, the traffic to the server could be very heavy, the requirements for the process capability and database size could be predictably high, and the authentication process would be very slow when the number of requests is overwhelmed for the server. Second, in case the central authentication system fails, all the authentication requests would be suspended. Third, the central authentication service provider could monitor the participating sites' login rates and a site which hosts a user's login page could monitor the user's login information. This situation is surely disliked by most of the participants. Our invention disclosed in the application Ser. No. 10/086,104 filed Feb. 26, 2002 provides a solution to have each authentication carried out at one of participating servers and have the authentication result distributed and cached all over the network of the participating servers so that the authentication results cannot be centrally monitored and even a site which hosts a user's login page cannot monitor a user's login information.

The invention provides a solution to guarantee the security of the distributed single-login authentication systems. In a “global single-login user name/password” situation, the user could mistakenly send his password to an unintended recipient that might abuse the information. For example, if the user attempted to type joe@aol.com but mistakenly typed joe@aol.com instead, and when he correctly entered his password and clicked login, the “aol.com” server would receive the user's password. In a “user name/password” situation, the authentication system does not know which authentication server is the correct one. It has to test a number of servers by forwarding each of the tested servers the user name and the password. Therefore, the more servers tested during the process, the more servers know the user's password. If any of the recipients abuses the information, it may cause irreparable harm to the user. This “leaking” of login information is generally unacceptable from a security perspective.

SUMMARY OF INVENTION

The invention disclosed herein comprises a system and method of providing secure single-login service with distributed multiple-authentication providers.

In the first preferred embodiment, the secure distributed authentication system comprises a client portion and a server portion. The client portion collects a user's regular user name and password and tests that user name and password at a variety of potential authentication servers to check where the login is valid. It combines the password with a time varying salt and a service-specific seed in a message-digesting (MD) hash and generates a first hash value. The client sends the hash value along with the user name and the time-varying salt to a currently selected server. The server portion extracts the user name and looks up an entry under the user name from the authentication server's database. If an entry is found, it retrieves the password and performs a same hash function on the combination of the user name, the service specific seed and the retrieved password to generate a second hash value. Then, it compares two hash values. If these two values match, the user is authenticated. In this way, the system never reveals the password to each tested authentication servers or any accidental recipient that might abuse the information. The authentication process according to the first preferred embodiment includes the following steps

    • (a) the client takes and parses an entered user name and password;
    • (b) generates a time stamp; iterates a list of authentication servers;
    • (c) iterates a list of authentication servers;
    • (d) combines the time stamp, the password and a service specific seed unique to an authentication server selected from the list;
    • (e) applies a hash algorithm to the combination to generate a first hash value;
    • (f) finds an IP address for the currently selected authentication server;
    • (g) sends a data packet to the selected authentication server, wherein the data packet includes the first hash value, the user name and the time stamp;
    • (h) extracts the first hash value, the user name and the time stamp from the data packet received from the client;
    • (i) checks whether an entry under the user name is available in the selected authentication server's database;
    • (j) if no entry under the user name is found, then returns a failure message to the client and repeats steps (b) to (g) for a next selected authentication server;
    • (k) if an entry under the user name is found, then retrieves the user's password;
    • (l) combines the time stamp, the retrieved password and the service specificseed unique to the selected authentication server;
    • (m) applies the hash algorithm to the combination from Step (l) to generate a second hash value;
    • (n) compares the first hash value and the second hash value;
    • (o) if these two hash values do not match, then returns a failure message to the client and repeats steps (b) to (g) for a next selected authentication server;
    • (p) if these two hash values do match, then returns a successful authentication message to the client; and
    • (q) when the entire list has been tested and no one authenticates the user, then results in authentication failure.

Note that Steps (a)-(g) are performed in the client software and Steps (h)-(p) are performed at each authentication service (i.e. server side software) before Step (c) iterates to the next authentication service.

In the second equally preferred embodiment, the secure distributed authentication system comprises a client portion and a server portion. The client portion collects a user's global user identification (GUID) and password. It combines the password with a time varying salt and a service specific seed in a message digesting (MO) hash and generates a first hash value. The client extracts the regular user name and the domain portion from the GUID. By looking up a local mapping list or a domain name system (DNS), the client obtains an Internet Protocol (IP) address for the authentication server identified by the domain portion. Then, it sends the hash value along with the user name and the time varying salt to the authentication server. The server portion extracts the user name and looks up an entry under the user name from the server's database. If an entry is found, it retrieves the password and performs a same hash function on the combination of the user name, the retrieved password and the service specific seed to generate a second hash value. Then, it compares two hash values. If these two values match, the user is authenticated. In this way, the system does not reveal the password to any accidental recipients. The authentication process according to the second preferred embodiment includes the following steps:

    • (a) The client parses an entered GUID and password;
    • (b) generates a time stamp;
    • (c) extracts the user name from the GUID;
    • (d) extracts the domain portion from the GUID;
    • (e) combines the password and a service specific seed unique to the target authentication server identified by the domain portion and hash the combination by mapplying a hash algorithm;
    • (f) combines the result of (e) with the time stamp to generate a first hash value;
    • (g) appends a unique domain name to the domain portion to form a fully qualified domain name (FQDN) for the target authentication server;
    • (h) looks up the FQDN from a local mapping list to obtain an IP address representing the target authentication server;
    • (i) if Step (h) fails, looks up the FQDN in a domain name system (DNS) to obtain an IP address representing the target authentication server;
    • (j) sends a data packet to the target authentication server, wherein the data packet includes the first hash value, the user name and the time stamp;
    • (k) extracts the first hash value, the user name and the time stamp from the data packet received from the client;
    • (l) checks whether an entry under the user name is available in the target authentication server's database;
    • (m) if no entry under the user name is found, then returns a failure message to the client;
    • (n) if an entry under the user name is found, then retrieves the user's password;
    • (o) combines the time stamp, the retrieved password and the service specific seed unique to the target authentication server;
    • (p) applies the hash algorithm to the combination from Step (0) to generate a second hash value;
    • (q) compares the first hash value and the second hash value;
    • (r) if these two hash values do not match, then returns a failure message to the client; and
    • (s) if the these two hash values do match, then returns a successful authentication message to the client.

The process may further include a step to automatically map an unrecognized FQDN to a default server for authentication.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an exemplary network that facilitates a distributed authentication service according to the invention;

FIG. 2 is a schematic diagram illustrating a simplified network including a client and an authentication server;

FIG. 3 is a flow chart illustrating an exemplary authentication process performed by the client portion according to the invention;

FIG. 4 is schematic diagram illustrating an exemplary domain name system, from which a client may obtain the IP address of an authentication server in case it fails to obtain the IP address from a local mapping list;

FIG. 5 is a table diagram illustrating an IP address database associated with the domain name server in the network; and

FIG. 6 is a flow chart illustrating an exemplary authentication process performed in the server portion according to the invention.

DETAILED DESCRIPTION

FIG. 1 is a block diagram illustrating an exemplary network 100, which provides distributed authentication service among a global authentication federation. The MCN network includes at least one client, e.g. client 101, and a number of authentication servers, e.g. servers 111-113, which are communicatively connected via the Internet 105.

Each client may include a browser 103 which displays an HTML file. The HTML facilitates a number of functions, which are typically implemented in JavaScript. Alternatively, the client may be implemented as a standalone application for managing the authentication process.

Each authentication server represents a participant of the global authentication federation and has an associated database, e.g. DB 01-DB 03, which caches its registered users' information and any authentication token from other participating authentication servers. The clients and the authentication servers can access a local domain name server, which is one of many domain name servers coupled in a domain name system (DNS).

The distributed authentication system embodied in the MCN network 100 according to the invention includes a client portion, which runs on a client device, and a server portion, which runs on a participating server of the global authentication federation.

FIG. 2 is a schematic diagram illustrating a simplified MCN network including a client 101 and an authentication server 111. Typically, the client 101 includes (1) a user interface 121 a, which enables a user to login by entering his user ID and password; (2) a central control piece 122 a, which implements client logic controlling the authentication process complying with the client portion of the authentication system; and (3) a message digest algorithm computing engine 123 a, which performs a oneway hash function.

The authentication server 111 includes (1) an input/output 121 b, which is used to receive requests and send back replies; (2) a controller 122 b, which implements the server's logic controlling the authentication process complying with the server portion of the authentication system; and (3) a message digest algorithm computing engine 123 b, which performs the same one-way hash function as that performed in the client portion. In addition, the server 111 is communicatively coupled to a database DB 01, which maintains its registered users' detail information including their passwords.

The hash function performed by the hash engines 123 a and 123 b is a mathematical function that maps values from a larger domain into a smaller range; in particular, they apply such a function to a password combined with certain seeds such as a time-specific seed or/and service-specific seed. The hash process is a one-way process, in which the hash engine applies a cryptographically secure hash algorithm to a combination of various parameters and generates a hash value. It is almost impossible to reverse the process and deduce the password.

The hash engines 123 a and 123 b may take advantage of an operation known as message digesting (MD). An MD algorithm takes as input a message of arbitrary length and produces as output a 128-bit fingerprint or message digest of the input. It is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given pre-specified target message digest. There are a number of message digesting algorithms available for use, some of which are provided by Rivest, Shamir and Associates (RSA). RSA message digesting algorithms have different versions such as MD2, MD4 and MD5. Other algorithms, such as Secure Hash Algorithm (SHA) which is a NIST standard, are also available in the marketplace.

The MD5 algorithm is usually used in digital signature application, where a large file must be compressed in a secure manner before being encrypted with a secret key under a public crypto-system such as RSA. For details about MD5 algorithm, see R. Rivest, The MD5 Message-Digest Algorithm, RFC 1321, MIT Laboratory for Computer Science and RSA Data Security, Inc.

Although an MD5 or its equivalent is preferably used in the embodiments described below, MD2 and MD4 digesting algorithm or other functionally equivalent algorithms can also be used in the scheme of the invention.

Process Performed by the Client Portion

In one preferred embodiment, the client portion of the authentication system takes the user's regular user name and password and maintain a mapping list of the fully qualified domain names (FQDN) for all MCN participants and their Internet Protocol (IP) addresses.

FIG. 3 is a flow chart illustrating an exemplary authentication process 300 performed by the client portion according to the invention. The process includes the steps of:

    • Step 301. The client 101 takes and parses the user name and password entered by a user in the login page.
    • Step 302. Generates a time varying salt such as a time stamp.
    • Step 303. Iterates a list of authentication servers from 1 to n to select the right authentication server.
    • Step 304. Combines the user's password with a service-specific seed unique to a currently selected authentication server to construct a “keyed one-way hash” of the password by applying a message-digesting algorithm.
    • Step 305. Combines the “keyed one-way hash” with the time stamp to compute a more secure hash value (the first hash value).

Note that the combination of the password with the service-specific seed makes it impossible to deduce what hash would be passed as authentication to other services. Furthermore, the combination of the time stamp and the “keyed one-way hash” makes the hash value (message digest) dynamic. In other words, the hash value is only valid for this current session. When the user logs on at a different time, the hash value will be different.

    • Step 306. Sends the user name, the time stamp and the hash value to the currently selected authentication server using one or more data packets as carrier.
    • Step 307. Receives a result of authentication from the authentication server. If the authentication is successful, proceeds to Step 308. If it is unsuccessful, proceeds to Step 309.
    • Step 308. Returns a successful authentication result to the client.
    • Step 309. Checks if there is an untested server in the list. If yes, then repeats steps 302-306 for a next authentication server selected from the remaining servers in the list.
    • Step 310. If no, returns an authentication failure message to the client.
      In a situation where the client portion of the authentication system keeps an updated list of MCN participants but fails to keep updated IP addresses for each participant, the client 101 may start a Domain Name System (DNS) lookup process to obtain the IP address of the currently selected authentication server. FIG. 4 illustrates an exemplary domain name system 200 incorporated in a global network. A domain name system (DNS) is a general-purpose, replicated, distributed data query service for looking up host Internet Protocol (IP) addresses based on host names. It is hierarchical, consisting of domains, sub-domains, sites, and hosts. Unique names are formed from smallest to largest, and are of the form “user@host.site.subdomain.domain”, where host and site are often optional.

On the Internet, domain names typically end with a suffix denoting the type of site. For example, “.COM” for commercial sites and “.ORG” for organizations. A name resolution client, such as the client 101 in FIG. 1 and FIG. 2, can be configured to search for host information in the following order: first in the local/etc/hosts file, second in network information service (NIS), and third in DNS. This sequencing of naming services is sometimes called name service switching. DNS can be queried interactively using command nslookup.

The MCN network 100 illustrated in FIG. 1 is registered under a unique domain name, for example MCN.ORG, in the central location of the DNS 200. The MCN network 100 requires each participant to register its authentication server as an individual machine under the MCN domain. In other words, the host names of the authentication servers share a common suffix. For example, AOL, as a participant host, registers its authentication server as AOL.COM.MCN.ORG under the unique domain MCN.ORG. The domain name server DNS 06 associated with the MCN network 100 just treats each participant authentication server as a host machine. For example, it treats AOL.COM.MCN.ORG as the host name of AOL Authentication Server 101.

FIG.5 illustrates a database DB 16 associated with the domain name server DNS 06. The database maintains a list of fully qualified domain names (FQDN) for the registered authentication servers. A FQDN consists of its local hostname and its domain name, including a top-level domain. For example, AOL.COM.MCN.ORG is a FQDN, in which AOL.COM is a host name, MCN.ORG is a domain name, and .COM is a top-level domain name. Each of FQDN has a unique IP address, which was installed in the database DB 06 when a commercial participant of the federation registered its authentication server under the domain MCN.ORG.

When the IP address for the currently selected authentication server 111 is returned, the client 101 sends the secure hash value along with the user name and the time stamp to the currently selected authentication server 111. If the currently-selected authentication server cannot authenticate the user, then the controller selects another candidate authentication server in the list and repeats the process as described above until the correct authentication server authenticates the user or all authentication servers fail to authenticate the user.

In an equally preferred embodiment, a user is required to input his global user identification (GUID) and password for authentication. A GUID is in a universal name space format, for example, an email address format. Hence any given GUID consists of two portions separated by a delimitation symbol, such as @. The first portion is the user's user name, and the second portion is a domain name indicating the domain of a server, such as AOL.COM, with which the user registered. For example, an AOL-registered user with a user name “joe” should enter his GUID joe@AOL.COM and his password secret911 for authentication by AOL Authentication Server 111, which is registered as AOL.COM.MCN.ORG under the domain MCN.ORG.

Referring back to FIG. 4, assuming the user enters his GUID and password from a page 201 hosted by ZYX.COM. Once the user gets logged in, the client portion of the authentication system parses the user's GUID joe@AOL.COM and extracts the domain portion AOL.COM from the GUID. Then, it appends the MCN domain name as a suffix to the domain portion. As a result, a FQDN AOL.eOM.MCN.ORG is formed.

The client portion of the authentication system first looks up a local domain name server DNS 05 to find location of the authentication server with a FQDN AGL.COM.MCN.ORG. After if fails in DNS 05, it populates the lookup request to its upper level DNS 02. After it fails in DNS 02, it populates the lookup request to the top DNS 01, where it locates the DNS 03 for the “.ORG” network. It further locates the DNS 06 for the MCN network 100 and eventually locates AOL.COM.MCN.ORG. In responding to the lookup request, the DNS returns a unique IP address for AOL.COM.MCN.ORG to the client 101. This unique IP address is automatically cached in the DNS along the returning route, i.e., DNS 06 -7DNS 03 -7DNS 01 DNS 5 02 -7DNS 05. Note that the critical point is that the DNS lookup is distributed and cached, and as a result, the DNS lookups cannot be centrally-monitored by any participant of the federation.

The distributed authentication system embodied in the MCN network 100 may include a default server 114 with a FQDN DEFAULT.MCN.ORG. If the DNS lookup totally fails, i.e. the domain included in the lookup request sent by the client device 101 is not recognized by the DNS 200, a DNS resolver in the central location of the DNS 200 can automatically map the unrecognized domain to the def.ault server 114. The default server 114 takes responsibility to authenticate the user by performing a hash process as described below (Process Performed By The Server Portion). The end result is that all possible MCN 10's are automatically distributed to the appropriate servers.

In another situation, all participants are not registered in a specific domain.

Instead, each participating authentication server is registered with a standard server name in its main server's domain. For example, AOL Authentication Server 111 has a FQDN AUTH.AOL.COM, USPTO's authentication server has a FQDN AUTH.USPTO.GOV, etc. In other words, the host names of these authentication servers share a common prefix but they reside in different domains. When the user gets logged in, the authentication system first parses and extracts the domain portion of the GUID. Then, it either checks a local mapping list or looks up the DNS 200 or performs both local list checkup and DNS lookup to locate the IP address for the target authentication server. If the IP address for the target authentication server is not found, the system may map the authentication request to the default server 114 as described above.

The DNS lookup process and the hash process can be performed sequentially or simultaneously. As soon as both the IP address and the hash value are available, the client sends the time stamp, the user's user name, and the hash value to the authentication server 111 for authentication. In the second preferred embodiment, because the authentication server is clearly identified by the GUID entered by the user, the authentication system does not need to iterate a list of authentication servers to find the correct one. It is slightly inconvenient for the user to type in his GUID, but the authentication process is much faster. In practice, the schemes in the first preferred embodiment and the second preferred embodiment can be combined. In other words, the authentication system can take either a regular user name such as “joe” or a GUID such as “joe@aol.com”.

Process Performed by the Server Portion

When the authentication server 111 receives the authentication request from the client 101 in its I/O block 121 b, it passes the request to the controller 122 a. The controller 122 a extracts the hash value, the user name and the time stamp from the received data packet or packets, and looks up the server's database DB 01 to check whether there is an entry for the user. If it finds an entry for the user, it retrieves the user's password stored in the database DB 01. Then, the controller combines the time stamp with the server's service seed and the retrieved password in the same specific logic order used in the client portion. It then passes the combination to the message digest computing engine 123 b, which applies the same algorithm as used in the message-digest computing engine 123 a, to the combination to generate a hash value. The controller 122 b compares the resulted hash value with the received hash value from the client 101. If two hash values match, then the authentication is successful; otherwise, the server returns a failure message to the client.

Once the user is successfully authenticated, the authentication server returns an authentication token to the client and distributes the authentication result to other participating servers of the federation. The authentication token is cached in the client device. When the user sends request to any other participant servers, the authentication token is automatically attached. The attached authentication token is recognized by any participating server of the federation and is automatically cached in the participating server's database when the participating server receives the authentication token. In this way, the user's detailed authentication information is stored only in one participant server's authentication database, but the authentication token is distributed all over the participants' authentication databases. Because an authentication server does not need to store every user's detailed authentication information, its authentication database can be relatively small in size.

FIG. 6 is a flow chart illustrating an exemplary authentication process 400 performed in the server portion according to the invention. The process includes the steps of:

    • Step 401. The authentication server receives an authentication request carried by one or more data packets from the client. The authentication request includes the user name, the time stamp and the hash value.
    • Step 402. Extracts the hash value, the user name and the time stamp from the data packet or packets.
    • Step 403. Looks up its database to find an entry based on the user name. If the server finds an entry for the user, proceeds to Step 405; otherwise the system proceeds to step 404.
    • Step 404. Returns an authentication failure message to the client and the authentication process continues on the client portion.
    • Step 405. If the server finds an entry for the user, retrieves the user's password from the database.
    • Step 406. Combines the user name, the password and the server's service seed.
    • Step 407. Applies the hash algorithm to the combination.
    • Step 408. Compare the hash value from Step 407 (the second hash value) with the hash value received from the client (the first hash value). If two hash values don't match, proceeds to Step 404.
    • Step 409. If two hash values do match, returns a successful authentication message to the client.

Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention.

Accordingly, the invention should only be limited by the Claims included below.

Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5210795Jan 10, 1992May 11, 1993Digital Equipment CorporationSecure user authentication from personal computer
US5349642Nov 3, 1992Sep 20, 1994Novell, Inc.Method and apparatus for authentication of client server communication
US5581616Jun 7, 1995Dec 3, 1996Next Software, Inc.Method and apparatus for digital signature authentication
US5633931Jun 30, 1995May 27, 1997Novell, Inc.Method and apparatus for calculating message signatures in advance
US5659616Jul 16, 1996Aug 19, 1997Certco, LlcMethod for securely using digital signatures in a commercial cryptographic system
US5684951Mar 20, 1996Nov 4, 1997Synopsys, Inc.Method and system for user authorization over a multi-user computer system
US5768373May 6, 1996Jun 16, 1998Symantec CorporationMethod for providing a secure non-reusable one-time password
US5774552Dec 13, 1995Jun 30, 1998Ncr CorporationMethod and apparatus for retrieving X.509 certificates from an X.500 directory
US5781724 *Nov 1, 1996Jul 14, 1998Novell, Inc.Method and system for integrating additional functionality into a login system
US5799088Dec 1, 1994Aug 25, 1998Raike; William MichaelNon-deterministic public key encrypton system
US5805703Nov 27, 1996Sep 8, 1998Next Software, Inc.Method and apparatus for digital signature authentication
US5815665Apr 3, 1996Sep 29, 1998Microsoft CorporationSystem and method for providing trusted brokering services over a distributed network
US5841865Apr 11, 1997Nov 24, 1998Certco LlcEnhanced cryptographic system and method with key escrow feature
US5841871Nov 18, 1996Nov 24, 1998Bull S.A.Method for authenticating a user working in a distributed environment in the client/server mode
US5867665Mar 24, 1997Feb 2, 1999Pfn, IncDomain communications server
US5870562Mar 24, 1997Feb 9, 1999Pfn, Inc.Universal domain routing and publication control system
US5872849Feb 19, 1997Feb 16, 1999Certco LlcEnhanced cryptographic system and method with key escrow feature
US5892828Oct 23, 1996Apr 6, 1999Novell, Inc.User presence verification with single password across applications
US5974453Oct 8, 1997Oct 26, 1999Intel CorporationMethod and apparatus for translating a static identifier including a telephone number into a dynamically assigned network address
US5995624Mar 10, 1997Nov 30, 1999The Pacid GroupBilateral authentication and information encryption token system and method
US6009177Feb 19, 1997Dec 28, 1999Certco LlcEnhanced cryptographic system and method with key escrow feature
US6023724Sep 26, 1997Feb 8, 20003Com CorporationApparatus and methods for use therein for an ISDN LAN modem that displays fault information to local hosts through interception of host DNS request messages
US6026430Mar 24, 1997Feb 15, 2000Butman; Ronald A.Dynamic client registry apparatus and method
US6049610Sep 9, 1998Apr 11, 2000Next Software, Inc.Method and apparatus for digital signature authentication
US6085321Aug 14, 1998Jul 4, 2000Omnipoint CorporationUnique digital signature
US6091835Feb 17, 1998Jul 18, 2000Penop LimitedMethod and system for transcribing electronic affirmations
US6094659Sep 26, 1997Jul 25, 20003Com CorporationWeb server for use in a LAN modem
US6094721Oct 31, 1997Jul 25, 2000International Business Machines CorporationMethod and apparatus for password based authentication in a distributed system
US6108330Sep 26, 1997Aug 22, 20003Com CorporationApparatus and methods for use therein for an ISDN LAN modem that selects among a plurality of DNS servers for responding to a DNS query
US6108703May 19, 1999Aug 22, 2000Massachusetts Institute Of TechnologyGlobal hosting system
US6144657Nov 6, 1997Nov 7, 2000Sun Microsystems, Inc.Remote device connection to a network
US6157636Sep 16, 1997Dec 5, 2000Bell Atlantic Network Services, Inc.Network session management with gateway-directory services and authorization control
US6161181Mar 6, 1998Dec 12, 2000Deloitte & Touche Usa LlpSecure electronic transactions using a trusted intermediary
US6178455Apr 11, 1997Jan 23, 2001Scientific-Atlanta, Inc.Router which dynamically requests a set of logical network addresses and assigns addresses in the set to hosts connected to the router
US6178511Apr 30, 1998Jan 23, 2001International Business Machines CorporationCoordinating user target logons in a single sign-on (SSO) environment
US6185316Nov 12, 1997Feb 6, 2001Unisys CorporationSelf-authentication apparatus and method
US6185598Feb 10, 1998Feb 6, 2001Digital Island, Inc.Optimized network resource location
US6189096Aug 6, 1998Feb 13, 2001Kyberpass CorporationUser authentification using a virtual private key
US6199052Mar 6, 1998Mar 6, 2001Deloitte & Touche Usa LlpSecure electronic transactions using a trusted intermediary with archive and verification request services
US6208656Apr 11, 1997Mar 27, 2001Scientific-Atlanta, Inc.Methods for dynamically assigning link addresses and logical network addresses
US6212635Jul 14, 1998Apr 3, 2001David C. ReardonNetwork security system allowing access and modification to a security subsystem after initial installation when a master token is in place
US6233234Jun 3, 1997May 15, 2001Bell Atlantic Network Services, Inc.Secure LAN/internet telephony
US6233458Feb 24, 1999May 15, 2001Nokia Telecommunications OyRe-routing procedure
US6249523Apr 11, 1997Jun 19, 2001Scientific-Atlanta, Inc.Router for which a logical network address which is not unique to the gateway address in default routing table entries
US6259789Dec 12, 1997Jul 10, 2001Safecourier Software, Inc.Computer implemented secret object key block cipher encryption and digital signature device and method
US6275944Apr 30, 1998Aug 14, 2001International Business Machines CorporationMethod and system for single sign on using configuration directives with respect to target types
US6282295Oct 28, 1997Aug 28, 2001Adam Lucas YoungAuto-recoverable and auto-certifiable cryptostem using zero-knowledge proofs for key escrow in general exponential ciphers
US6285760Apr 6, 2000Sep 4, 2001Next Software, Inc.Method and apparatus for digital signature authentication
US6289010Jan 27, 1998Sep 11, 2001Bell Atlantic Network Services, Inc.Inbound gateway authorization processing for inter-carrier internet telephony
US6289039Jun 14, 2000Sep 11, 2001Linex Technologies, Inc.Spread-spectrum communications utilizing variable throughput reduction
US6298383 *Jan 4, 1999Oct 2, 2001Cisco Technology, Inc.Integration of authentication authorization and accounting service and proxy service
US6298445Apr 30, 1998Oct 2, 2001Netect, Ltd.Computer security
US6304915May 17, 1999Oct 16, 2001Hewlett-Packard CompanySystem, method and article of manufacture for a gateway system architecture with system administration information accessible from a browser
US6307935Jul 18, 1997Oct 23, 2001Apple Computer, Inc.Method and apparatus for fast elliptic encryption with direct embedding
US6421768May 4, 1999Jul 16, 2002First Data CorporationMethod and system for authentication and single sign on using cryptographically assured cookies in a distributed computer environment
US6601175 *Mar 16, 1999Jul 29, 2003International Business Machines CorporationMethod and system for providing limited-life machine-specific passwords for data processing systems
US6662300Jun 29, 1999Dec 9, 2003International Business Machines CorporationSecure password provision
US6732101Jun 15, 2000May 4, 2004Zix CorporationSecure message forwarding system detecting user's preferences including security preferences
US6819766Mar 22, 2000Nov 16, 2004International Business Machines CorporationMethod and system for managing keys for encrypted data
US6826698Sep 15, 2000Nov 30, 2004Networks Associates Technology, Inc.System, method and computer program product for rule based network security policies
US6959336Apr 7, 2001Oct 25, 2005Secure Data In Motion, Inc.Method and system of federated authentication service for interacting between agent and client and communicating with other components of the system to choose an appropriate mechanism for the subject from among the plurality of authentication mechanisms wherein the subject is selected from humans, client applications and applets
US6996718Aug 11, 2000Feb 7, 2006At&T Corp.System and method for providing access to multiple user accounts via a common password
US7024690Apr 28, 2000Apr 4, 20063Com CorporationProtected mutual authentication over an unsecured wireless communication channel
US7137006Sep 22, 2000Nov 14, 2006Citicorp Development Center, Inc.Method and system for single sign-on user access to multiple web servers
US7392390 *Dec 11, 2002Jun 24, 2008Valve CorporationMethod and system for binding kerberos-style authenticators to single clients
US7500106 *Oct 22, 2004Mar 3, 2009Siemens AktiengesellschaftMethod for identifying, authenticating and authorizing a user of protected data
US7502860 *Mar 14, 2002Mar 10, 2009Cisco Technology, Inc.Method and apparatus for client-side flow control in a transport protocol
US7669233 *Feb 25, 2005Feb 23, 2010Metavante CorporationMethods and systems for secure transmission of identification information over public networks
US7810147 *Dec 1, 2006Oct 5, 2010Emc CorporationDetecting and preventing replay in authentication systems
US8005965 *Jun 30, 2001Aug 23, 2011International Business Machines CorporationMethod and system for secure server-based session management using single-use HTTP cookies
US8024306 *May 16, 2007Sep 20, 2011International Business Machines CorporationHash-based access to resources in a data processing network
US20010049787 *May 16, 2001Dec 6, 2001Ikuya MorikawaSystem and method for distributed group management
US20020184507May 31, 2001Dec 5, 2002Proact Technologies Corp.Centralized single sign-on method and system for a client-server environment
US20030131266Jan 7, 2002Jul 10, 2003International Business Machines CorporationGenerating and maintaining encrypted passwords
US20030135507Jan 17, 2002Jul 17, 2003International Business Machines CorporationSystem and method for managing and securing meta data using central repository
US20050015457 *May 21, 2004Jan 20, 2005International Business Machines CorporationSystem, method and program product for authenticating an e-mail and/or attachment
US20090147958Dec 8, 2007Jun 11, 2009International Business Machines CorporationDynamic, Selective Obfuscation of Information for Multi-Party Transmission
US20110131415 *Nov 30, 2009Jun 2, 2011James Paul SchneiderMultifactor username based authentication
US20110145581 *Dec 14, 2009Jun 16, 2011Verizon Patent And Licensing, Inc.Media playback across devices
USRE37178Sep 20, 1996May 15, 2001Novell, Inc.Method and apparatus for authentication of client server communication
EP0667998A1Nov 2, 1993Aug 23, 1995Novell, Inc.Method and apparatus for authentication of client server communication
EP0739560A1Jan 13, 1995Oct 30, 1996Certco, LlcCryptographic system and method with key escrow feature
EP0938217A2Feb 19, 1999Aug 25, 1999Kabushiki Kaisha ToshibaMobile IP communication scheme using dynamic address allocation protocol
EP0940959A1Mar 4, 1998Sep 8, 1999Sony International (Europe) GmbHEstablishing connections between remote devices with a hypertext transfer protocol
EP1076279A1Aug 13, 1999Feb 14, 2001Hewlett-Packard CompanyComputer platforms and their methods of operation
EP1081914A2Apr 20, 2000Mar 7, 2001Sun Microsystems, Inc.Single sign-on for network system that includes multiple separately-controlled restricted access resources
EP1089516A2Sep 20, 2000Apr 4, 2001Citicorp Development Center, Inc.Method and system for single sign-on user access to multiple web servers
Non-Patent Citations
Reference
1A Flexible Distributed Authorization Protocol; Jonathan T. Troslte, and B. Clifford Neuman, 1996.
2A Security Architecture for Computational Grids; Ian Foster, Carl Kesselman, Gene Tsudik, and Steven Tuecke, Nov. 1998.
3A Study of One-Time Password System Based on Message Digest; Liu Yuyan, and Luo Junzhou; 5th International Conference for Young Computer Scientists; 1999.
4Better Login Protocols for Computer Networks; D. de Waleffe, and J.J. Quisquarter; Computer Security an Industrial Cryptography; May 1991.
5Efficient Kerberized Multicast in a Practical Distributed Setting; Giovanni Di Crescenzo, Aug. 2001.
6Homburg, et al.; "Unifying Internet Services Using Distributed Shared Objects"; 1996; Faculty of Math and Computer Science, vrije Universiteit.
7Kim, et al.; "Implementing a Secure Login Environment: A Case Study of Using a Secure Network Layer Protocol"; Jun. 1995; Dept. of Computer Science, Univ. of Arizona.
8Krypto Knight Authentication and Key Distribution System; Refik Molva, Gene Tsudik, Els Van Herreweghen, and Stefano Zatti; Aug. 24, 1993.
9McDaniel, et al.; "Scalable Key Distribution Hierarchy"; Mar. 1998; Univ. of Michigan.
10Message Digest 5 and the Authentication in IPv6; Wang Gui-Zhu, Li Jin-Sheng, and Hong Pei-Lin; Mini-Micro System; Jan. 2001.
11On Selectable Collisionful Hash Functions; S. Bakhtiari, R. Safavi-Naini, and J. Pieprzyk, 1996.
12One-Way Hash Functions; B. Schneier; Dr. Dobb's Journal; Sep. 1991.
13Password Files; T.J. Pope; Dr. Dobb's Journal; Jan. 1996.
14RFC 1423-Privacy Enhancement for Internet electronic Mail; Part III: Algorithms, Modes, and Identifiers; D. Balenson; Feb. 1993.
15RFC 1423—Privacy Enhancement for Internet electronic Mail; Part III: Algorithms, Modes, and Identifiers; D. Balenson; Feb. 1993.
16Schuba, et al.; "Addressing Weaknesses in the Domain Name System Protocol"; Aug. 1993; Coast Laboratory, Dept. of Computer Sciences, Purdue University.
17Schuba, et al.; "Countering Abuse of Name-Based Authentication"; 1996; Coast Laboratory, Dept. of Computer Sciences, Purdue University.
18Secure Data Collection With Updates; S. Loureiro, R. Molva, and A. Pannetrat; Electronic Commerce Research; Feb.-Mar. 2001.
19Secure Electronic Payment Systems, Secure Electronic Transactions (SET); Burton Filstrup, Oct. 2001.
20Sesame V2 Public Key and Authorisation Extensions to Kerberos; P,V. McMahon, Feb. 1995.
21Sign on to Streamlined Security; J.R. Vacca; Datamation; Sep. 15, 1994.
22The MD4 Message Digest Algorithm; B.S, Kaliski Jr.; Advances in Cryptology; 1991.
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US8359392 *Jul 9, 2008Jan 22, 2013Gregor ZebicSystem and method for securely communicating on-demand content from closed network to dedicated devices, and for compiling content usage data in closed network securely communicating content to dedicated devices
US20090222740 *May 13, 2009Sep 3, 2009Computer Associates Think, Inc.System and method for synchronizing login processes
US20100241753 *Jul 9, 2008Sep 23, 2010Gregor GarbajsSystem and Method For Securely Communicating On-Demand Content From Closed Network to Dedicated Devices, and For Compiling Content Usage Data in Closed Network Securely Communicating Content to Dedicated Devices
US20130152193 *Dec 7, 2012Jun 13, 2013Pei-An ChengMethod for authentication with dynamic and random passwords
Classifications
U.S. Classification726/5, 709/219, 726/10, 709/224, 380/255, 713/155, 726/2, 709/225, 726/3, 726/6, 713/175, 713/154, 726/4, 726/21, 380/277, 713/157
International ClassificationH04L29/12, H04L29/06
Cooperative ClassificationH04L9/3226, H04L9/3236, H04L63/083, H04L61/1511, G06F2221/2151, H04L9/3271, G06F21/31, H04L29/12066, H04L2463/102, H04L63/0815
European ClassificationH04L9/32R, G06F21/31, H04L63/08D, H04L63/08B
Legal Events
DateCodeEventDescription
Jul 3, 2012ASAssignment
Effective date: 20120614
Owner name: FACEBOOK, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AOL INC.;REEL/FRAME:028487/0304
Oct 3, 2011ASAssignment
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AOL LLC;REEL/FRAME:027006/0801
Effective date: 20091204
Owner name: AOL INC., VIRGINIA