WO2006052601A2 - Authenticating a login - Google Patents

Authenticating a login Download PDF

Info

Publication number
WO2006052601A2
WO2006052601A2 PCT/US2005/039656 US2005039656W WO2006052601A2 WO 2006052601 A2 WO2006052601 A2 WO 2006052601A2 US 2005039656 W US2005039656 W US 2005039656W WO 2006052601 A2 WO2006052601 A2 WO 2006052601A2
Authority
WO
WIPO (PCT)
Prior art keywords
user
login
private
token
obtaining
Prior art date
Application number
PCT/US2005/039656
Other languages
French (fr)
Other versions
WO2006052601A3 (en
Inventor
Alexandre Bronstein
Alon Waksman
Original Assignee
Astav, Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Astav, Inc filed Critical Astav, Inc
Priority to EP05815985A priority Critical patent/EP1813048A4/en
Publication of WO2006052601A2 publication Critical patent/WO2006052601A2/en
Publication of WO2006052601A3 publication Critical patent/WO2006052601A3/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/42—User authentication using separate channels for security data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the present invention relates to the field of computer-related services. More particularly, this invention relates to authenticating a login.
  • Computer systems may store a variety of valuable information.
  • a computer system used for financial services may store a variety of confidential data pertaining to a financial institution as well as confidential data pertaining to clients of the financial institution.
  • a computer system used to provide an on-line retail service may store a variety of confidential data pertaining to customers of the on-line retail service, e.g. names, addresses, credit card numbers, etc.
  • a computer system may employ a login process that enables authentic users of the computer system to gain access to the computer system while preventing unauthorized parties from gaining access to the computer system.
  • a computer system used in an on- line banking service may employ a login process that enables account holders to access their accounts on ⁇ line.
  • a computer system may authenticate a login by prompting a user for a username and a password and then determining whether the password is the correct password for that username.
  • Authenticating logins using passwords may require that users memorize relatively complex passwords and/or change passwords relatively frequently in order to prevent an unscrupulous party from wrongfully gaining access to accounts by guessing or stealing passwords .
  • the burdens of memorizing complex passwords and/or memorizing new passwords relatively frequently may increase user frustration and dissuade users from employing computer- based services.
  • the present techniques include authenticating a login by determining whether an appropriate token is stored on a client system that originates the login, authenticating a login by communicating with a user via a secondary communication channel, and authenticating a login by engaging in a private question/private answer dialogue with a user.
  • Figures Ia-Ib illustrate a method for by authenticating a login by determining whether an appropriate token is stored on a client system that originates the login;
  • Figures 2a-2b illustrate generating an appropriate token during creation of a user account on a computer system
  • Figure 3 shows an embodiment of a client system that includes additional mechanisms for handling tokens
  • Figure 4 illustrates a method for authenticating a login by communicating with a user via a secondary communication channel
  • Figure 5 illustrates creation of a user account in an embodiment that uses a secondary communication channel to authenticate a login
  • Figures 6a-6b illustrate a method for authenticating a login by engaging in a private question/private answer dialogue with a user
  • Figure 7 illustrates creation of a user account in an embodiment that employs a private question/private answer dialogue.
  • Figures Ia-Ib illustrate a method for authenticating a login to a computer system 10 by determining whether an appropriate token is stored on a client system 12 that originates the login.
  • the computer system 10 generates a login page 60 that enables a user of the client system 12 to enter a username in a login username field 50.
  • the computer system 10 obtains the username via the login page 60 and uses the username to locate an entry in a data store 40 that corresponds to the username entered in the login page 60.
  • the user entered USER-A into the login username field 50 and the computer system 10 matches to the entry 42 that also holds the username USER-A.
  • the computer system 10 authenticates the login by verifying whether a token TOKEN-A specified in the entry 42 is stored on the client system 12.
  • the computer system 10 may verify the token by obtaining it in a cookie from the client system 12.
  • the computer system 10 may read the token from a file on the client system 12.
  • the computer system 10 decrypts the token obtained from the client system 12 if appropriate.
  • the login is authentic only if the token TOKEN-A from the entry 42 is stored on the client system 12.
  • the computer system 10 authenticates the login by comparing a password entered by a user into the login page 60 to a password contained in the entry 42 and verifying whether a token TOKEN-A from the entry 42 is stored on the client system 12. The login is authentic only if the password entered into the login page 60 matches the password contained in the entry 42 and the token TOKEN-A from the entry 42 is stored on the client system 12.
  • Figures 2a-2b illustrate generating an appropriate token during creation of a user account on the computer system 10.
  • the computer system 10 generates a web page 30 that enables a user of the client system 12 to register by entering the username USER-A in a username field 20 and an optional password PASSWORD-A in a password field 22 for the new user account.
  • the computer system 10 obtains the username USER-A and the password PASSWORD-A via the web page 30 and stores the username USER-A and the password PASSWORD-A in the entry 42 in the data store 40 that is allocated to the new user account.
  • the computer system 10 generates the token TOKEN-A in response to the username and the optional password entered into the web page 30.
  • the token TOKEN-A may be generated in a manner that prevents theft.
  • the TOKEN-A may be an encrypted version of the username
  • the computer system 10 transfers the token TOKEN-A to the client system 12 in a message 24 and the client system 12 stores the token TOKEN-A internally in a manner that enables the computer system 10 to read the token TOKEN-A from the client system 12.
  • the token TOKEN-A may be stored in a cookie on the client system 12. Alternatively, the token TOKEN-A may be stored in a file on the client system 12.
  • the computer system 10 also stores the token TOKEN-A in the data store 40 in the entry 42 of the new user account for use in authenticating subsequent logins.
  • the computer system 10 communicates with the client system 12 via a network using web protocols.
  • the client system 12 may be embodied as a desktop computer, a laptop computer, a PDA or other handheld device, etc.
  • the client system 12 includes a browser application that is capable of handling cookies using web protocols, including cookies that carry a token between the client system 12 and the computer system 10.
  • the client system 12 includes a display for rendering web pages to a user and a user input mechanism, e.g. keyboard, for obtaining inputs from a user.
  • the client system 12 includes a communication mechanism for communicating with the computer system 10 using Internet protocols.
  • FIG. 3 shows an embodiment of the client system 12 that includes additional mechanisms for handling tokens.
  • the client system 12 includes an access task 70 that stores and retrieves tokens from a store 72.
  • the access task 70 may be downloaded from the computer system 10 to the client system 12 when the user of the client system 12 creates an account with the computer system 10.
  • the access task 70 may be downloaded from the computer system 10 to the client system 12 when the user of the client system 12 creates an account with the computer system 10.
  • the access task 70 once installed and running on the client system 12 enables the computer system 10 to store a token in the store 72 and to retrieve a token from the store 72.
  • the access task 70 may use an HTTP command to communicate the token with the computer system 10.
  • the store 72 may be a file in persistent memory, e.g. on disk, of the client system 12.
  • Figure 4 illustrates a method for authenticating a login to the computer system 10 by communicating via a secondary communication channel 84 between the computer system 10 and a user of the client system 12.
  • the computer system 10 generates a login page 160 that enables a user of the client system 12 to enter a username in a login username field 150.
  • the computer system 10 obtains the login username via the login page 160 and uses the login username to locate an entry in the data store 40. For example, if the user entered USER-A into the login username field 150 then the computer system 10 matches the USER-A to the entry 42.
  • the computer system 10 authenticates the login by performing a communication via the secondary communication channel 84 to a destination DESTINATION-A specified in the entry 42.
  • the secondary communication channel 84 is a telephone call to a telephone number specified by the destination DESTINATION-A in the entry 42.
  • the computer system 10 prompts for a validation input via the telephone call.
  • the login is authentic only if the appropriate validation input is provided via the telephone call.
  • the computer system 10 may prompt for entry of a password via the key pad of the telephone 82.
  • the password may be a password originally registered by the user of the client system 12 or some other password.
  • the computer system 10 may prompt for entry of a yes/no input, voice or via keypad, to a question such as "Is it OK to grant access to your user account at this time?"
  • the secondary communication channel 84 is an email message to an email address specified by the destination DESTINATION-A in the entry 42.
  • the email message may prompt the user to enter a validation input via a return email message.
  • the secondary communication channel 84 may be any communication channel between the computer system 10 and a user of the computer system 12 other than the communication channel used to initiate the login. For example, if the login is initiated via a network using http then the secondary communication channel 84 may be any communication channel other than the http login session.
  • Figure 5 illustrates creation of a user account on the computer system 10 in an embodiment that uses a secondary communication channel to authenticate a login.
  • the computer system 10 generates a web page 100 that enables a user of the client system 12 to enter a username USER-A in a username field 90 and a destination
  • DESTINATION-A e.g. a telephone number, email address, etc.
  • a destination field 94 for the new user account e.g. a telephone number, email address, etc.
  • the user of the client system 12 enters a number for their telephone 82.
  • the computer system 10 obtains the username USER-A and the telephone number DESTINATION-A via the web page 100 and stores the username USER-A and the password PASSWORD-A and the telephone number DESTINATION-A in the entry 42 that is allocated to the new user account for later use in authenticating logins.
  • the computer system 10 uses a telephony subsystem 80 to place a telephone call to the telephone 82 in one embodiment.
  • Figures 6a-6b illustrate a method for authenticating a login to the computer system 10 by engaging in a private question/private answer dialogue with a user.
  • the computer system 10 generates a login page 260 that enables a user of the client system 12 to enter a username in a login username field 262.
  • the computer system 10 obtains the login username via the login page 260 and uses the login username to locate an entry in the data store 40. For example, if the user entered USER-A into the login username field 262 then the computer system 10 matches the USER-A to the entry 42.
  • the computer system 10 obtains a private memory MEM-A and a private question QUESTION-A from the entry 42 and presents the private memory MEM-A in a field 264 of the login page 260 and presents the private question QUESTION-A in a field 266 of the login page 260.
  • the user of the client system 12 enters an answer to the private question presented in the field 266 into an input field 268 of the login page 260.
  • the computer system 10 authenticates the login by comparing the answer entered into the input field 268 to the answer ANSWER-A from the entry 42. The login is authentic only if the answer from the input field 268 matches the answer ANSWER-A from the entry 42.
  • Figure 7 illustrates creation of a user account on the computer system 10 in an embodiment that employs a private question/private answer dialogue.
  • the computer system 10 generates a web page 210 that enables a user of the client system 12 to enter the username USER-A in a username field 200 and the private memory MEM-A in a private memory field 202 and the private question QUESTION-A in a private question field 204 and the private answer ANSWER-A to the private question QUESTION-A in a private answer field 206 for the new user account.
  • the computer system 10 obtains the username USER-A and the private memory MEM-A and the private question QUESTION-A and the private answer ANSWER-A via the web page 210 and stores the information in the entry 42 that is allocated to the new user account.
  • the computer system 10 may store the obtained username USER-A and the private memory MEM- A and the private question QUESTION-A and the private answer ANSWER-A on the client system 12 in a cookie or a file as described above with respect to the token TOKEN- A.
  • the computer system 10 may encrypt the information before storing it.
  • the private memory MEM-A may be a sentence, e.g. a character string representing a sentence typed by the user of the client system 12, or a digitized audio sample of a sentence spoken by the user of the client system 12, or an audio sample or an image sample, e.g. a picture or other image provided by the user of the client system 12 to name a few examples.
  • a sentence e.g. a character string representing a sentence typed by the user of the client system 12, or a digitized audio sample of a sentence spoken by the user of the client system 12, or an audio sample or an image sample, e.g. a picture or other image provided by the user of the client system 12 to name a few examples.
  • the user of the client system 12 may select the private memory MEM-A so that it is memorable and private to themselves, i.e. not generally known by others. For example, the sentence "My trip to the Italian Alps last summer” would be memorable to a user having visited the Italian Alps last summer and would be private to the user if the trip was not generally known by others.
  • the user may select the private question QUESTION-A such that it pertains to the private memory MEM-A.
  • the private memory of "My trip to Italy last summer” may correspond to a private question of "Who drove you to the airport for that trip last summer?"
  • a private memory/private question combination according to the present teachings may lessen the memorization burden on a user in comparison to memorizing a password.
  • the computer system 10 may authenticate a login by verifying a token on the client system 12 and employing a private memory/private question dialogue with the user of the client system 12.

Abstract

Techniques for authenticating a login that avoid the imposition of memorization burdens on users of a computer system. The present techniques include determining whether an appropriate token is stored on a client system that originates the login, authenticating a login by communicating with a user via a secondary communication channel, and authenticating a login by engaging in a private question/private answer dialogue with a user.

Description

AUTHENTICATING A LOGIN
Technical Field
The present invention relates to the field of computer-related services. More particularly, this invention relates to authenticating a login.
Background Art
Computer systems may store a variety of valuable information. For example, a computer system used for financial services may store a variety of confidential data pertaining to a financial institution as well as confidential data pertaining to clients of the financial institution. Similarly, a computer system used to provide an on-line retail service may store a variety of confidential data pertaining to customers of the on-line retail service, e.g. names, addresses, credit card numbers, etc.
A computer system may employ a login process that enables authentic users of the computer system to gain access to the computer system while preventing unauthorized parties from gaining access to the computer system. For example, a computer system used in an on- line banking service may employ a login process that enables account holders to access their accounts on¬ line.
A computer system may authenticate a login by prompting a user for a username and a password and then determining whether the password is the correct password for that username. Authenticating logins using passwords may require that users memorize relatively complex passwords and/or change passwords relatively frequently in order to prevent an unscrupulous party from wrongfully gaining access to accounts by guessing or stealing passwords . Unfortunately, the burdens of memorizing complex passwords and/or memorizing new passwords relatively frequently may increase user frustration and dissuade users from employing computer- based services.
DISCLOSURE OF THE INVENTION
Techniques are disclosed for authenticating a login that avoid the imposition of memorization burdens on users of a computer system. The present techniques include authenticating a login by determining whether an appropriate token is stored on a client system that originates the login, authenticating a login by communicating with a user via a secondary communication channel, and authenticating a login by engaging in a private question/private answer dialogue with a user.
Other features and advantages of the present invention will be apparent from the detailed description that follows.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is described with respect to particular exemplary embodiments thereof and reference is accordingly made to the drawings in which:
Figures Ia-Ib illustrate a method for by authenticating a login by determining whether an appropriate token is stored on a client system that originates the login;
Figures 2a-2b illustrate generating an appropriate token during creation of a user account on a computer system;
Figure 3 shows an embodiment of a client system that includes additional mechanisms for handling tokens;
Figure 4 illustrates a method for authenticating a login by communicating with a user via a secondary communication channel;
Figure 5 illustrates creation of a user account in an embodiment that uses a secondary communication channel to authenticate a login;
Figures 6a-6b illustrate a method for authenticating a login by engaging in a private question/private answer dialogue with a user;
Figure 7 illustrates creation of a user account in an embodiment that employs a private question/private answer dialogue.
MODES FOR CARRYING OUT THE INVENTION
Figures Ia-Ib illustrate a method for authenticating a login to a computer system 10 by determining whether an appropriate token is stored on a client system 12 that originates the login. The computer system 10 generates a login page 60 that enables a user of the client system 12 to enter a username in a login username field 50. The computer system 10 obtains the username via the login page 60 and uses the username to locate an entry in a data store 40 that corresponds to the username entered in the login page 60. In the example shown, the user entered USER-A into the login username field 50 and the computer system 10 matches to the entry 42 that also holds the username USER-A.
In one embodiment, the computer system 10 authenticates the login by verifying whether a token TOKEN-A specified in the entry 42 is stored on the client system 12. The computer system 10 may verify the token by obtaining it in a cookie from the client system 12. Alternatively, the computer system 10 may read the token from a file on the client system 12. The computer system 10 decrypts the token obtained from the client system 12 if appropriate. The login is authentic only if the token TOKEN-A from the entry 42 is stored on the client system 12.
In another embodiment, the computer system 10 authenticates the login by comparing a password entered by a user into the login page 60 to a password contained in the entry 42 and verifying whether a token TOKEN-A from the entry 42 is stored on the client system 12. The login is authentic only if the password entered into the login page 60 matches the password contained in the entry 42 and the token TOKEN-A from the entry 42 is stored on the client system 12.
Figures 2a-2b illustrate generating an appropriate token during creation of a user account on the computer system 10. The computer system 10 generates a web page 30 that enables a user of the client system 12 to register by entering the username USER-A in a username field 20 and an optional password PASSWORD-A in a password field 22 for the new user account. The computer system 10 obtains the username USER-A and the password PASSWORD-A via the web page 30 and stores the username USER-A and the password PASSWORD-A in the entry 42 in the data store 40 that is allocated to the new user account.
The computer system 10 generates the token TOKEN-A in response to the username and the optional password entered into the web page 30. The token TOKEN-A may be generated in a manner that prevents theft. For example, the TOKEN-A may be an encrypted version of the username
USER-A with a key that is private to the computer system 10. The computer system 10 transfers the token TOKEN-A to the client system 12 in a message 24 and the client system 12 stores the token TOKEN-A internally in a manner that enables the computer system 10 to read the token TOKEN-A from the client system 12. The token TOKEN-A may be stored in a cookie on the client system 12. Alternatively, the token TOKEN-A may be stored in a file on the client system 12. The computer system 10 also stores the token TOKEN-A in the data store 40 in the entry 42 of the new user account for use in authenticating subsequent logins.
In one embodiment, the computer system 10 communicates with the client system 12 via a network using web protocols. The client system 12 may be embodied as a desktop computer, a laptop computer, a PDA or other handheld device, etc. The client system 12 includes a browser application that is capable of handling cookies using web protocols, including cookies that carry a token between the client system 12 and the computer system 10. The client system 12 includes a display for rendering web pages to a user and a user input mechanism, e.g. keyboard, for obtaining inputs from a user. The client system 12 includes a communication mechanism for communicating with the computer system 10 using Internet protocols.
Figure 3 shows an embodiment of the client system 12 that includes additional mechanisms for handling tokens. In this embodiment, the client system 12 includes an access task 70 that stores and retrieves tokens from a store 72. The access task 70 may be downloaded from the computer system 10 to the client system 12 when the user of the client system 12 creates an account with the computer system 10. The access task
70 once installed and running on the client system 12 enables the computer system 10 to store a token in the store 72 and to retrieve a token from the store 72. For example, the access task 70 may use an HTTP command to communicate the token with the computer system 10. The store 72 may be a file in persistent memory, e.g. on disk, of the client system 12.
Figure 4 illustrates a method for authenticating a login to the computer system 10 by communicating via a secondary communication channel 84 between the computer system 10 and a user of the client system 12. The computer system 10 generates a login page 160 that enables a user of the client system 12 to enter a username in a login username field 150. The computer system 10 obtains the login username via the login page 160 and uses the login username to locate an entry in the data store 40. For example, if the user entered USER-A into the login username field 150 then the computer system 10 matches the USER-A to the entry 42.
The computer system 10 authenticates the login by performing a communication via the secondary communication channel 84 to a destination DESTINATION-A specified in the entry 42.
In one embodiment, the secondary communication channel 84 is a telephone call to a telephone number specified by the destination DESTINATION-A in the entry 42. The computer system 10 prompts for a validation input via the telephone call. The login is authentic only if the appropriate validation input is provided via the telephone call. For example, the computer system 10 may prompt for entry of a password via the key pad of the telephone 82. The password may be a password originally registered by the user of the client system 12 or some other password. In another example, the computer system 10 may prompt for entry of a yes/no input, voice or via keypad, to a question such as "Is it OK to grant access to your user account at this time?"
In another embodiment, the secondary communication channel 84 is an email message to an email address specified by the destination DESTINATION-A in the entry 42. The email message may prompt the user to enter a validation input via a return email message.
The secondary communication channel 84 may be any communication channel between the computer system 10 and a user of the computer system 12 other than the communication channel used to initiate the login. For example, if the login is initiated via a network using http then the secondary communication channel 84 may be any communication channel other than the http login session.
Figure 5 illustrates creation of a user account on the computer system 10 in an embodiment that uses a secondary communication channel to authenticate a login. The computer system 10 generates a web page 100 that enables a user of the client system 12 to enter a username USER-A in a username field 90 and a destination
DESTINATION-A, e.g. a telephone number, email address, etc., in a destination field 94 for the new user account. In this example, the user of the client system 12 enters a number for their telephone 82. The computer system 10 obtains the username USER-A and the telephone number DESTINATION-A via the web page 100 and stores the username USER-A and the password PASSWORD-A and the telephone number DESTINATION-A in the entry 42 that is allocated to the new user account for later use in authenticating logins. The computer system 10 uses a telephony subsystem 80 to place a telephone call to the telephone 82 in one embodiment.
Figures 6a-6b illustrate a method for authenticating a login to the computer system 10 by engaging in a private question/private answer dialogue with a user. The computer system 10 generates a login page 260 that enables a user of the client system 12 to enter a username in a login username field 262. The computer system 10 obtains the login username via the login page 260 and uses the login username to locate an entry in the data store 40. For example, if the user entered USER-A into the login username field 262 then the computer system 10 matches the USER-A to the entry 42.
The computer system 10 obtains a private memory MEM-A and a private question QUESTION-A from the entry 42 and presents the private memory MEM-A in a field 264 of the login page 260 and presents the private question QUESTION-A in a field 266 of the login page 260. In response, the user of the client system 12 enters an answer to the private question presented in the field 266 into an input field 268 of the login page 260. The computer system 10 authenticates the login by comparing the answer entered into the input field 268 to the answer ANSWER-A from the entry 42. The login is authentic only if the answer from the input field 268 matches the answer ANSWER-A from the entry 42.
Figure 7 illustrates creation of a user account on the computer system 10 in an embodiment that employs a private question/private answer dialogue. The computer system 10 generates a web page 210 that enables a user of the client system 12 to enter the username USER-A in a username field 200 and the private memory MEM-A in a private memory field 202 and the private question QUESTION-A in a private question field 204 and the private answer ANSWER-A to the private question QUESTION-A in a private answer field 206 for the new user account.
In one embodiment, the computer system 10 obtains the username USER-A and the private memory MEM-A and the private question QUESTION-A and the private answer ANSWER-A via the web page 210 and stores the information in the entry 42 that is allocated to the new user account. Alternatively, the computer system 10 may store the obtained username USER-A and the private memory MEM- A and the private question QUESTION-A and the private answer ANSWER-A on the client system 12 in a cookie or a file as described above with respect to the token TOKEN- A. The computer system 10 may encrypt the information before storing it.
The private memory MEM-A may be a sentence, e.g. a character string representing a sentence typed by the user of the client system 12, or a digitized audio sample of a sentence spoken by the user of the client system 12, or an audio sample or an image sample, e.g. a picture or other image provided by the user of the client system 12 to name a few examples.
The user of the client system 12 may select the private memory MEM-A so that it is memorable and private to themselves, i.e. not generally known by others. For example, the sentence "My trip to the Italian Alps last summer" would be memorable to a user having visited the Italian Alps last summer and would be private to the user if the trip was not generally known by others.
The user may select the private question QUESTION-A such that it pertains to the private memory MEM-A. For example, the private memory of "My trip to Italy last summer" may correspond to a private question of "Who drove you to the airport for that trip last summer?" A private memory/private question combination according to the present teachings may lessen the memorization burden on a user in comparison to memorizing a password.
The techniques described above for authenticating a login may be combined in any manner. For example, the computer system 10 may authenticate a login by verifying a token on the client system 12 and employing a private memory/private question dialogue with the user of the client system 12.
The foregoing detailed description of the present invention is provided for the purposes of illustration and is not intended to be exhaustive or to limit the invention to the precise embodiment disclosed. Accordingly, the scope of the present invention is defined by the appended claims.

Claims

CLAIMSWhat is claimed is:
1. A method for authenticating a login, comprising: obtaining a username for the login from a user; verifying the login by determining whether a token corresponding to the username is stored on a client system of the user.
2. The method of claim 1, further comprising registering the user by obtaining the username from the user and generating the token in response to the username and storing the token on the client system.
3. The method of claim 2, wherein registering further comprises obtaining a password from the user and wherein verifying includes obtaining a password for the login from the user and determining whether the password obtained from the user for the login corresponds to the password obtained from the user when registering.
4. The method of claim 2, wherein storing the token on the client system includes storing the token in a cookie.
5. The method of claim 2, wherein storing the token on the client system includes storing the token in a file.
6. The method of claim 2, wherein storing the token on the client system includes encrypting the token.
7. A method for authenticating a login, comprising: obtaining a username for the login from a user via a first communication channel; verifying the login by communicating with the user via a secondary communication channel.
8. The method of claim 7, wherein communicating comprises placing a telephone call .
9. The method of claim 8, wherein verifying the login comprises obtaining an input from the user via the telephone call .
10. The method of claim 7, wherein communicating comprises sending an email message.
11. A method for authenticating a login, comprising: obtaining a username for the login from a user; presenting a private question associated with the username to the user and obtaining an answer to the private question from the user; verifying the login by determining whether the answer is correct.
12. The method of claim 11, further comprising registering the user by obtaining the username and a set of information pertaining to the private question from the user.
13. The method of claim 12, wherein obtaining a set of information pertaining to the private question includes obtaining a private memory.
14. The method of claim 13, wherein obtaining a set of information pertaining to the private question includes obtaining the private question such that the private question pertains to the private memory.
15. The method of claim 12, wherein obtaining a set of information pertaining to the private question includes obtaining a private answer to the private question.
16. The method of claim 15, wherein determining whether the answer is correct includes determining whether the answer matches the private answer.
PCT/US2005/039656 2004-11-03 2005-11-02 Authenticating a login WO2006052601A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05815985A EP1813048A4 (en) 2004-11-03 2005-11-02 Authenticating a login

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/980,910 2004-11-03
US10/980,910 US8171303B2 (en) 2004-11-03 2004-11-03 Authenticating a login

Publications (2)

Publication Number Publication Date
WO2006052601A2 true WO2006052601A2 (en) 2006-05-18
WO2006052601A3 WO2006052601A3 (en) 2007-06-21

Family

ID=36263557

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/039656 WO2006052601A2 (en) 2004-11-03 2005-11-02 Authenticating a login

Country Status (3)

Country Link
US (1) US8171303B2 (en)
EP (1) EP1813048A4 (en)
WO (1) WO2006052601A2 (en)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9762576B2 (en) 2006-11-16 2017-09-12 Phonefactor, Inc. Enhanced multi factor authentication
US8365258B2 (en) * 2006-11-16 2013-01-29 Phonefactor, Inc. Multi factor authentication
DE102007004957A1 (en) * 2007-01-26 2008-07-31 Vodafone Holding Gmbh Authenticate two transaction partners involved in a transaction
US8020195B2 (en) * 2007-03-30 2011-09-13 Citrix Systems, Inc. Systems and methods for user login
US10778417B2 (en) * 2007-09-27 2020-09-15 Clevx, Llc Self-encrypting module with embedded wireless user authentication
US10181055B2 (en) * 2007-09-27 2019-01-15 Clevx, Llc Data security system with encryption
US11190936B2 (en) 2007-09-27 2021-11-30 Clevx, Llc Wireless authentication system
US8756660B2 (en) * 2008-04-17 2014-06-17 Microsoft Corporation Enabling two-factor authentication for terminal services
CN103581120B (en) 2012-07-24 2018-04-20 阿里巴巴集团控股有限公司 A kind of method and apparatus for identifying consumer's risk
US20190056828A1 (en) * 2012-09-06 2019-02-21 Google Inc. User interface transitions
US8572398B1 (en) 2013-02-13 2013-10-29 Daniel Duncan Systems and methods for identifying biometric information as trusted and authenticating persons using trusted biometric information
US8914645B2 (en) 2013-02-13 2014-12-16 Daniel Duncan Systems and methods for identifying biometric information as trusted and authenticating persons using trusted biometric information
US9143506B2 (en) 2013-02-13 2015-09-22 Daniel Duncan Systems and methods for identifying biometric information as trusted and authenticating persons using trusted biometric information
US10250590B2 (en) 2015-08-31 2019-04-02 Samsung Electronics Co., Ltd. Multi-factor device registration for establishing secure communication
CN105245541B (en) 2015-10-28 2020-02-18 腾讯科技（深圳）有限公司 Authentication method, equipment and system
US10129210B2 (en) 2015-12-30 2018-11-13 Go Daddy Operating Company, LLC Registrant defined limitations on a control panel for a registered tertiary domain
US10387854B2 (en) 2015-12-30 2019-08-20 Go Daddy Operating Company, LLC Registering a tertiary domain with revenue sharing
US10009288B2 (en) * 2015-12-30 2018-06-26 Go Daddy Operating Company, LLC Registrant defined prerequisites for registering a tertiary domain

Family Cites Families (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2674710B1 (en) * 1991-03-27 1994-11-04 France Telecom METHOD AND SYSTEM FOR PROCESSING PREECHOS OF AN AUDIO-DIGITAL SIGNAL ENCODED BY FREQUENTIAL TRANSFORM.
US5311594A (en) 1993-03-26 1994-05-10 At&T Bell Laboratories Fraud protection for card transactions
US5907597A (en) * 1994-08-05 1999-05-25 Smart Tone Authentication, Inc. Method and system for the secure communication of data
US5774869A (en) * 1995-06-06 1998-06-30 Interactive Media Works, Llc Method for providing sponsor paid internet access and simultaneous sponsor promotion
US5991617A (en) * 1996-03-29 1999-11-23 Authentix Network, Inc. Method for preventing cellular telephone fraud
GB9811446D0 (en) * 1998-05-29 1998-07-22 Int Computers Ltd Authentication device
US6671672B1 (en) * 1999-03-30 2003-12-30 Nuance Communications Voice authentication system having cognitive recall mechanism for password verification
US6226752B1 (en) * 1999-05-11 2001-05-01 Sun Microsystems, Inc. Method and apparatus for authenticating users
US7194437B1 (en) 1999-05-14 2007-03-20 Amazon.Com, Inc. Computer-based funds transfer system
US7058817B1 (en) * 1999-07-02 2006-06-06 The Chase Manhattan Bank System and method for single sign on process for websites with multiple applications and services
US6584505B1 (en) 1999-07-08 2003-06-24 Microsoft Corporation Authenticating access to a network server without communicating login information through the network server
US6934858B2 (en) * 1999-12-15 2005-08-23 Authentify, Inc. System and method of using the public switched telephone network in providing authentication or authorization for online transactions
US7216361B1 (en) * 2000-05-19 2007-05-08 Aol Llc, A Delaware Limited Liability Company Adaptive multi-tier authentication system
FI115355B (en) * 2000-06-22 2005-04-15 Icl Invia Oyj Arrangement for the authentication and authentication of a secure system user
WO2002001376A1 (en) * 2000-06-28 2002-01-03 Yozan Inc. Host computer, mobile communication device, program, and recording medium
US6871063B1 (en) * 2000-06-30 2005-03-22 Intel Corporation Method and apparatus for controlling access to a computer system
US20020099648A1 (en) 2000-09-19 2002-07-25 Devoe Dana L. Method of reducing fraud in credit card and other E-business
JP2002215582A (en) * 2000-12-28 2002-08-02 Morgan Stanley Dean Witter Japan Ltd Method and device for authentication
US7243369B2 (en) 2001-08-06 2007-07-10 Sun Microsystems, Inc. Uniform resource locator access management and control system and method
US7100054B2 (en) * 2001-08-09 2006-08-29 American Power Conversion Computer network security system
US7373515B2 (en) * 2001-10-09 2008-05-13 Wireless Key Identification Systems, Inc. Multi-factor authentication system
US6693530B1 (en) 2001-10-16 2004-02-17 At&T Corp. Home security administration platform
US7149296B2 (en) 2001-12-17 2006-12-12 International Business Machines Corporation Providing account usage fraud protection
US7707108B2 (en) 2002-01-31 2010-04-27 International Business Machines Corporation Detection of unauthorized account transactions
US7318234B1 (en) * 2002-02-19 2008-01-08 Microsoft Corporation Request persistence during session authentication
US7308579B2 (en) 2002-03-15 2007-12-11 Noel Abela Method and system for internationally providing trusted universal identification over a global communications network
US20030182214A1 (en) 2002-03-20 2003-09-25 Taylor Michael K. Fraud detection and security system for financial institutions
US7292680B1 (en) * 2002-03-21 2007-11-06 At&T Bls Intellectual Property, Inc. Automated passcode recovery in an interactive voice response system
US7225464B2 (en) * 2002-04-03 2007-05-29 Yodlee.Com, Inc. Method for verifying the identity of a user for session authentication purposes during Web navigation
US7149899B2 (en) * 2002-04-25 2006-12-12 Intertrust Technologies Corp. Establishing a secure channel with a human user
US7100049B2 (en) 2002-05-10 2006-08-29 Rsa Security Inc. Method and apparatus for authentication of users and web sites
US7383572B2 (en) * 2002-05-24 2008-06-03 Authentify, Inc. Use of public switched telephone network for authentication and authorization in on-line transactions
US7237118B2 (en) * 2002-12-05 2007-06-26 Microsoft Corporation Methods and systems for authentication of a user for sub-locations of a network location
US7853984B2 (en) * 2002-12-11 2010-12-14 Authorize.Net Llc Methods and systems for authentication
US7360694B2 (en) * 2003-01-23 2008-04-22 Mastercard International Incorporated System and method for secure telephone and computer transactions using voice authentication
US6871288B2 (en) 2003-02-21 2005-03-22 Ronald K. Russikoff Computerized password verification system and method for ATM transactions
US9240891B2 (en) * 2003-06-11 2016-01-19 Symantec Corporation Hybrid authentication
US7841940B2 (en) * 2003-07-14 2010-11-30 Astav, Inc Human test based on human conceptual capabilities
US7721329B2 (en) * 2003-11-18 2010-05-18 Aol Inc. Method and apparatus for trust-based, fine-grained rate limiting of network requests
US7430758B2 (en) * 2004-02-05 2008-09-30 Microsoft Corporation Prompt authentication
US20050228782A1 (en) * 2004-04-07 2005-10-13 Alexandre Bronstein Authenticating a web site with user-provided indicators
WO2005107137A2 (en) 2004-04-23 2005-11-10 Passmark Security, Inc. Method and apparatus for authenticating users using two or more factors
US20050273626A1 (en) * 2004-06-02 2005-12-08 Steven Pearson System and method for portable authentication
US7779457B2 (en) 2004-06-09 2010-08-17 Identifid, Inc Identity verification system
US7676834B2 (en) * 2004-07-15 2010-03-09 Anakam L.L.C. System and method for blocking unauthorized network log in using stolen password
US7467401B2 (en) * 2004-08-12 2008-12-16 Avatier Corporation User authentication without prior user enrollment
US7467411B2 (en) * 2004-08-27 2008-12-16 Astav, Inc. Protecting a service provider from abuse
US20060131385A1 (en) 2004-12-16 2006-06-22 Kim Mike I Conditional transaction notification and implied approval system
US20060271457A1 (en) 2005-05-26 2006-11-30 Romain Martin R Identity theft monitoring and prevention

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of EP1813048A4 *

Also Published As

Publication number Publication date
EP1813048A4 (en) 2010-12-29
WO2006052601A3 (en) 2007-06-21
US20060095788A1 (en) 2006-05-04
EP1813048A2 (en) 2007-08-01
US8171303B2 (en) 2012-05-01

Similar Documents

Publication Publication Date Title
EP1813048A2 (en) Authenticating a login
US7676829B1 (en) Multiple credentials in a distributed system
US7730321B2 (en) System and method for authentication of users and communications received from computer systems
EP1625690B1 (en) Method and apparatus for authentication of users and web sites
US9323918B2 (en) Methods, systems, and computer program products for recovering a password using user-selected third party authorization
KR100786551B1 (en) Method for registering and certificating user of one time password by a plurality of mode and computer-readable recording medium where program executing the same method is recorded
US9191375B2 (en) System and method for accessing integrated applications in a single sign-on enabled enterprise solution
US8954745B2 (en) Method and apparatus for generating one-time passwords
EP1766839B1 (en) System and method for blocking unauthorized network log in using stolen password
US8731197B2 (en) Secure randomized input
US8438620B2 (en) Portable device for clearing access
EP1719283B1 (en) Method and apparatus for authentication of users and communications received from computer systems
US20060015358A1 (en) Third party authentication of an electronic transaction
US20020087892A1 (en) Authentication method and device
US20110047605A1 (en) System And Method For Authenticating A User To A Computer System
WO2008095011A2 (en) Methods and systems for authentication of a user
EP1046976B1 (en) Method and apparatus for enabling a user to authenticate a system prior to providing any user-privileged information
JP2001331447A (en) Computer system for transmitting mail including password safely in terms of security
SE531800C2 (en) login System

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2005815985

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005815985

Country of ref document: EP