EP2311020A1

EP2311020A1 - Method and system for securing communication sessions

Info

Publication number: EP2311020A1
Application number: EP09803357A
Authority: EP
Inventors: Samir Dilipkumar Saklikar; Subir Saha
Original assignee: Motorola Inc
Current assignee: Motorola Mobility LLC
Priority date: 2008-07-29
Filing date: 2009-07-14
Publication date: 2011-04-20
Also published as: CN102105920A; WO2010014386A1; EP2311020A4; CA2762706A1

Abstract

A mechanism for secure communication is provided, wherein a user can get authenticated by solving a captcha on a secure system. The user browser has knowledge of a unique combination between various image objects possible in the captcha and its mapping to various sub-parts of an authentic website public-key. The user solves the captcha, and the browser plugin does the rest of the part of validation of authentic website identity, as well as responding to a challenge of returning the next object.

Description

METHOD AND SYSTEM FOR SECURING COMMUNICATION

SESSIONS

Field of the Invention

ItHHH] The present invention relates to communication sessions, more particularly to securing communication sessions through authentication of web-site and remote user interactivity.

Background

!$H^ | Phishing attacks on email and internet communications have become rampant. As a primary cause of identity theft, phishing is a serious problem that must be countered. Phishing often involves fooling an internet user into clicking on a fake website, which appears to be authentic but takes the user to a phishing website. If the user accepts a public -key certificate from authentic looking website, the phisher can capture the username/password as well as sensitive user information. The user login information can be used as well by the phishing site to impersonate the user in communication with an authentic website. The phishing site can then perform a "man-in-the-middle" attack on all data passing between the user and the authentic website. User is fooled into believing that the session is secure.

|*HHH] Users have the responsibility of remembering various username/password combinations for logging into various websites. Such username/password management is particularly difficult for use with a mobile device, wherein user input is constrained with the limited device keypads. The tendency to use passwords that are relatively simple and easily remembered eases the phisher's challenge.

ItHHM] Various approaches that have been proposed for protecting against such piracy have relied upon the need for alertness and observation skills from the user. An objective is to ensure that indeed it is a human user that is entering the password. In transport layer security (TLS) protocol communication sessions, for example, the user is expected to be alert/responsive to any of various security pop-ups/alerts to verify a received certificate. However, users for the most part just click on "OK" and continue. Users are not likely to identify a received self-signed certificate as originating from a phishing site.

|$KM5| Attempts have been made by authentic websites to ensure communication with a human, rather than an automated site, by requiring a human response. These efforts can be thwarted by "man-in-the-middle" attacks. These attacks may merely relay the request for human response to the user or may include human intervention at the phishing site.

|θθ(ks] The need thus exists to develop a more effective mechanism to resist phishing attacks. Phishing targets users, rather than automated systems. Any secure solution may be proposed at the transport layer, but if users can be fooled, then Phishing succeeds. Hence, any phishing solution must cover the path between the users and computers. Such a mechanism should address the weakness of the human-computer interface. Data transmissions that are effectively un-decipherable to an automated attacker should be developed to ensure the presence of a human user. Such a mechanism can augment username/password-based authentication schemes by requiring a response from the user, wherein only the human user recipient can decipher the website data transmission and generate an appropriate response. Increased human involvement should thus provide a more secure and easier option.

Summary

[000^{^}1 Various embodiments of the invention provide a method for securing a communication session. Upon establishing a communication session with a website, a client receives a challenge from the website. The challenge includes image object information embedded with a pattern of a secure channel invariant. The data in the received challenge is linked specifically to a user associated with the client. The website is authenticated by comparing the received data pattern with an identified portion of a website public -key. The website public-key refers to a public -key of the website received during secure session establishment. The identified portion of the website public key is identified as follows. A database list at the client is searched for an image object that matches the image object information in the challenge. A set of bit positions that is mapped to the matched image object in the database list is determined and a substring i.e. a portion of the website public key corresponding to the determined bit positions is identified. If the received data pattern does not match the identified portion of the website public-key, the communication session is automatically terminated.

^MMIHi From the perspective of the website, the communication session can be made secure by ensuring that the user is also verified. Upon authenticating the website, the client transmits a response to the web site. The response includes data representing a different image object and a pattern linked thereto. This linked pattern, for example, can correspond to different bit positions of the website public -key. The response may be generated by accessing a database at the client to identify an appropriate image object and pattern data linked to the image object. The database at the client is synchronized with the website database. The website can authenticate the response by accessing the website database to compare the received response data with the data accessed.

Brief Description of the Drawings

^MMNi The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawing and in which like reference numerals refer to similar elements and in which:

I IH^ (5] Fig. 1 is a block diagram of a communication system in accordance with some embodiments. ItHH X] Fig. 2 is a block diagram of the support functionality for securing a communication session between a client site and a website in accordance with some embodiments.

^ I ^ i Fig. 3a is an illustration, in accordance with the invention, that exemplifies captchas encoded with public -key information.

^ I Λ I Fig. 3b is an illustration, in accordance with the invention, that exemplifies captchas encoded with public -key information.

|00§ 4ϊ Fig. 4 is a protocol execution flowchart for an authentication process at a client's site.

|00i ^l Fig. 5 is a protocol execution flowchart for authentication of a user at the website in the process of Fig. 4.

|00h%ϊ Fig. 6 is a flowchart of a method for an authentication process at a client's site in accordance with an embodiment.

|00i "I Fig. 7 is a flowchart of a method for authentication of a user at a website in accordance with another embodiment.

|0(H S| Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

|tHH^] The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

Detailed Description

|002^1 However sophisticated a phishing site may be, it lacks one important link in the whole chain, i.e., the ability to verify that the information entered by the user is indeed correct. Irrespective of security solutions, there are certain tests which can be solved only by the user and not, at least not easily, by an automated phishing site. Human interactive proofs can be used to differentiate between computer and humans. A challenge-response test, involving what is known as a "captcha," can be implemented to ask a user to complete a simple test which the sending site computer can generate and grade. The captcha, for example, can include a distorted image of alphanumeric characters, which are recognizable on a display screen by the user, but not identifiable by the receiving computer. While a satisfactory completion of such test is effective for assuring that a human has been involved in formulating a response, a phishing site may circumvent this measure by having another human solve the captcha. The use of a captcha alone, therefore, will not provide the desired optimum level of security.

^H^ t s If a phisher is forced to prove knowledge of some user-specific information, for example to verify user/password, then it is effectively forced to contact the authentic website. Now the control is in the hands of the authentic website to take the next step to somehow detect and prevent the user from being subject to a phishing attack. Information must be conveyed in a manner that is somehow hidden from the phishing website, which can be in a position to pick up all information that goes through to the user. The authentic website can use a captcha as a carrier for information needed to be conveyed to the human user at the other end of the channel. Suitable characteristics of the captcha can be chosen to ensure easy solvability for users, but of sufficient difficulty for the automated phishing site. However, the phisher may simply pass on the captcha to the user and pass the user's solved results back to the authentic website.

HHlϊ.ϊ i The authentic website can avoid this scenario in accordance with the present invention by encoding sufficient information within the captcha to enable the user to detect if it is under a phishing attack. This information should not be easily duplicated or falsified by the phishing website. Secure HTTP-based sessions take place over a secure communication channel, established by mechanisms such as TLS. The advantage of such an underlying secure technology is that it is based on certain invariants which cannot be falsified once the session is setup. For example, in TLS sessions, an invariant could be the session keys which are generated. Thus, if the captcha is embedded with the session keys, which are generated by the authentic website, then the user could detect a mismatch between the captcha embedded keys and the session keys which were exposed by the phishing website at the time of establishing the secure connection. Thus, the user can identify information embedded within a captcha generated at the authentic web-site that is not only invariant (i.e. neither duplicated nor falsified) but also associated with the identity of the web-site to determine whether or not a phishing attack has occurred.

|t^«3] The public -key associated with a website is tightly coupled with the web-site's identity, as exposed within the server certificate message within a TLS handshake protocol. Though the actual identity itself might be dubious in case of a phishing website, it is still coupled with the certificate as well as the corresponding public/private keys, which would be used for secure session establishment. The website public -key cannot be falsified once it has been exposed and used at the time of secure channel establishment. At the same time, it cannot be simply duplicated from the authentic website by the phisher, as it is tightly coupled with the corresponding private key which is required for successful decryption. Thus, the website public-key can qualify as a man-in-the-middle resistant invariant of the secure channel.

|00«4| Fig. 1 is a block diagram of a communication system in accordance with some embodiments. The communication system 100 includes a client 102, an authentic website 104 and a phishing site 106. A communication session is intended to be implemented by the client with authentic website. Such clients comprise one or more computers and workstations. It should be understood, nevertheless, that other clients such as Web-enabled hand-held devices which use the wireless access protocol, and Internet appliances fall within the scope of the present invention. The client 102 can also refer to a network browser or any other application which is capable of accessing and/or communicating with a network accessible website. Clients of all types suitably intend to access the authentic website 104 by way of the Internet 108. A website is a collection of webpages, images, videos, or other digital assets that is hosted on one or more web servers, usually accessible via the internet. By use of the term "Internet", it should be understood that the foregoing is not intended to limit the present invention to a network also known as the World Wide Web. For example, it includes intranets, extranets, Virtual Private Networks (VPNs), and the like. The phishing site 106 is an authentic looking website capable of perform a "man-in-the-middle" attack on all data passing between the client 102 and the authentic website 104.

K^lϊ5ϊ Fig. 2 is a block diagram of the support functionality for secure communication between a client and an authentic website in accordance with the present invention. Client station 110 includes processor 112 coupled with a client database 114. Client processor 112 provides the user support functions, represented by high level components like captcha rendering function 116, validation function 118, sync function 120 and session management function 122. The website station 130 includes processor 132 coupled with website database 134 and image repository 136. Website processor 132 provides website support functions, represented by captcha generating function 138, sync function 140 and session management function 142. Session management functions 122 and 142 provide secure channel communication based on TLS or the like.

jt*t&«^] Image repository 136 is populated with a varied number of image objects, with appropriate tags, that are used for generating captchas. A captcha is a challenge-response test used to ensure that the response is not generated by an automaton. The image repository may be accessed or maintained by the website support function. The object images from this repository are used in generating lists for storage in the website database 134 and client database 114. The objects of the website database image list are linked to a bit position map on a per user name basis in database 134. In the client database 114 the objects of the image list are linked to a bit position map on a per website basis if communication with a plurality of websites is contemplated. A synchronization functionality, performed by sync function 140 at the website in conjunction with the sync function 120 at the client site, provides an updated image list and bit position map 124 to the user on every successful wth login. This updating function ensures that new and different challenges would be presented to potential phishers. This information would be bootstrapped when a user registers for the website.

|002^{^}| The captcha generating function 138, generates an appropriate captcha based on the website's public -key, the username, and the user- specific image list and bit position map in database 134. The captcha rendering function 116 at the client is mapped to user browser's rendering engine. In an embodiment, the rendered captcha is displayed and a request is generated for the human user to identify the image object within the captcha as well as enter a corresponding tag data e.g. a text string. The validation function 118 performs, via access to the client database 114, various checks on the user's response.

|t^«^| Fig. 3a is an illustration, in accordance with the invention, that exemplifies captchas created by an authentic website by encoding it's own public -key information to be rendered at the client site. The captchas each contain two parts, i.e., an object image and a sub-part of the public-key of the authentic website. The exemplified house image contains therein the alphanumeric string "6d e8 73," which corresponds to bits x . . . y of the public -key.

As shown in the illustration in Fig. 3b, the exemplified car image contains therein the alphanumeric string "by 8d al," which corresponds to bits p . . . q of the public-key. Upon display of a rendered captcha at the client site, the validation function 118 may request the user to enter the text rendered in the captcha and to select an image from a list of objects that corresponds to the displayed image. Source validation occurs if the user's entries match a correlation in the client database 114. For example, for a user's entry of "house," bit positions x . . . y of the website public -key received during session establishment, correlated thereto in the client database 114, must match the text string entered by the user i.e., "eb78dal." jt&t&,M$] Fig. 4 is a protocol execution flowchart for the authentication process at the client's site. At step 50, the user requests for a session with a server of a website by initiating a link to enter the website domain. Whenever the browser initiates a secure HTTP connection, the client processor 112 stores the public-key as well as the identity exposed by the website session server in the server certificate messages. Later, if the webpage turns out to be a login page, then the client processor 112 reads the username and password entered by the user and sends the username towards the website server. Via a browser plugin, a TLS connection is established with the website server and the website transmits a public-key to the browser plugin for secure session establishment at step 52. Once the secure session establishment is complete, a login page is provided to the browser plugin at step 54. The login page is rendered at the user display and the user provides user identity information and password at step 56. At this time, only the username is transmitted by the browser plugin to the website.

|003 ? I A captcha is generated by the website at step 58 and transmitted to the client site. The website searches in the database 134 to find the corresponding image list and bit position map for the username. The captcha generation is based on a suitable image from the image list for the user and a sub-part of the public -key at the corresponding bit position indices for the image object. I IH^ « ] The captcha is rendered to the user at step 60, who solves it by identifying the object as well as entering the encoded substring of the website public -key. The client processor 112 validates that the object belongs to the list of objects, which are currently associated with the particular website. Additionally, the processor uses the bit position map to index into the public-key (exposed at the time of TLS session establishment) and extracts the sub-part. It further checks that the string entered by the user (viz. the one contained in the captcha) matches this sub- part. If the browser plugin is assured of these checks, then it can safely assume that it is securely connected with the correct website. The secure connection is thus verified at the client site at step 61.

H^lV^s> If the browser has determined that one or more check has failed, i.e., user's identification of object and string, it shows a phishing- related error message to the user and terminates the session at step 62.

|(H^4| If the client processor 112 is assured of the authenticity of the web-site in step 61, it can safely send the user's password over the TLS connection towards the authentic website at step 63. The website can verify the user password to authenticate the user and provide a login success page at step 64. It may also send a new image list and bit position map, which would be used for the next login attempt.

|OOΛS] For successful mutual identification, it is also necessary to convince the authentic website that the captcha has indeed been reached and solved by the intended user. Any captcha provides an implicit challenge mechanism, wherein the user may be asked to respond with the information which is encoded within the captcha. However, this does not guarantee that the captcha is actually solved by it's intended recipient user. For example, a phishing automaton could take assistance of a human user to solve a captcha. This loophole can be solved, by defining additional semantics in the form of an implicit challenge within the captcha. In the public -key- embedded graphic captcha scheme described herein, the implicit challenge can be defined to mean "return the type of the image object, which corresponds to the xth sub-part after the sub-part of the public -key, which was encoded within the captcha." This would require the human-assisted phisher to guess the image list for the user as well as the bit position map. On the other hand, an authentic user's system can easily look up the image list and bit position map to respond to the challenge.

K^^>ϊ Fig. 5 is a protocol execution flowchart for authentication of the user at the authentic website in the process described with respect to Fig. 4. The second protocol execution flow describes a two-way authentication mechanism, wherein the user password is not required. In this figure, additional steps are provided between the points marked "A" and "B" in Fig. 4. In this scenario, instead of using the password to prove it's authenticity, the client processor 112 uses it's knowledge about the image list and bit position map to indicate that indeed it is representative of an authentic user. The client processor 112 does so by identifying and returning an image object tag, which corresponds to the exemplified xth sub-part before or after the sub-part that was embedded within the captcha, at step 70. Of course, this information would be returned over the secure TLS connection towards the authentic website, as verified by the one-way authentication protocol flow of Fig. 4. At step 72 the website confirms the match between the received object tag and sub-part string with its image list in database 134 and informs the client of a successful login. The website can send to the user a new image list and bit position map, which would be used for the next login attempt.

|5M3^"i The USF needs to be implemented within the User's Browser, so that it has access to the Public Key, exposed by the website at the time of TLS session establishment. Additionally, it also needs to have easy CAPTCHA rendering capability and User Input capability which are available within any standard browser. Thus, it is most effectively implemented as a Browser Plugin. Additionally, it needs to implement a local security mechanism (for e.g. a global Username/Password or linked to Biometric Authentication offered by newer personal computers) to ensure secure access to the Image List and Bit Position Map database. Otherwise, anyone using the User's Browser would be able to authenticate themselves as the User to the website.

^CHX^ Fig. 6 is a flowchart of a method for an authentication process at a client's site in accordance with an embodiment. At step 610, a challenge including an image object information embedded with a pattern of a secure channel invariant, is received at a client from a website. The secure channel invariant refers to a public -key of the website received during establishment of the communication session. The received data is linked specifically to a user associated with the client. At step 620 the website is authenticated by comparing the received data pattern with an identified portion of a website public-key. The portion of the website public -key is identified by searching the database at the client for an image object that matches the image object information in the challenge. Examples of image object information include an image of a house, car, tree etc. If an image object match is found, a set of bit positions that is mapped to the matched image object is determined and a substring of the website public-key corresponding to the determined bit positions is identified. If the received pattern matches the identified portion of the website public -key at step 630, then a password indication is sent to the website at step 640. In an embodiment, the password indication is a response that includes tag data representing an image object and a data pattern linked to the image object. The image object in the transmitted response is different from the image object information in the received challenge. The image object is identified from the database at the client and a data pattern is correlated with the identified object image. The data pattern is a substring of the website public key which is different from the substring of the public -key identified at step 620. If the received pattern does not match an identified portion of the website public key at step 630, the communication session is terminated at step 650.

|003°| Fig. 7 is a flowchart of a method for authentication of a user at a website in accordance with another embodiment. At step 710 a communication is received by a website from a client. The communication includes a request for a session with the website along with a information identifying the user. At step 720, a user solvable challenge including an image object representation embedded with a pattern of a secure channel invariant is generated. The generated challenge is linked specifically to the user based on the received user identity information. At step 730, the generated challenge is transmitted to the client for solving by the user. At step 740, a response comprising tag data representing an image object and a data pattern linked thereto is received from the client. The image object of the received response is different from the image object of the transmitted challenge. At step 750 the user is authenticated by comparing the data pattern in the received response with an identified portion of the secure channel invariant. If the data pattern matches the identified portion of the secure channel invariant at step 760, then a response authenticating the user is transmitted to the client at step 770. If the data pattern does not match the identified portion of the secure channel invariant at step 760, then the user is invalidated at step 780.

^sKMM In this disclosure there are shown and described only preferred embodiments of the invention and but a few examples of its versatility. It is to be understood that the invention is capable of use in various other combinations and environments and is capable of changes or modifications within the scope of the inventive concept as expressed herein. ItHMt] For example, the user support function should be implemented within the user's browser, so that it has access to the public -key, exposed by the website at the time of TLS session establishment. Additionally, easy captcha rendering capability and user input capability are available within any standard browser. Thus, while the invention is most effectively implemented by use of a browser plugin, equivalent processor functionality is not precluded.

^MU ^ i Additionally, a local security mechanism, for example a global username/password or link to biometric authentication offered by newer personal computers, can be implemented to ensure secure access to the image list and bit position map database. This provision would prevent anyone other than the user from using the user's browser would to authenticate himself as the user to the website.

!$KU^ The invention is also applicable to communications in which users login to their accounts from a public computer. In such a case, the browser plugin could be appropriately modified to read the database from a removable storage device such as a pen-drive. While the browser on the public computer could be compromised to make a local copy of the user- specific image list and bit position map, which would enable a human- assisted attack, this security risk is not any different nor more severe than a similarly compromised browser which logs the user key presses to extract the username/password for existing authentication mechanisms. In either case, it is important that the user's browser is trustworthy. |tHM 4] Typically, when users register for the first time with a website, they are sent a confirmation email to one of their existing email addresses. The websites use this as a rudimentary check against automata-triggered login. The initial image list and bit position map can be suitably formatted in a XML format and sent within this email. The users would be required to copy this XML into their browser's plugin.

|tHM§] As a more general approach, the XML version of the image list and bit position map could be sent as a hidden parameter using inline XML within the HTML page which is rendered to the user. The browser plugin would implement the additional parsing logic to read and store it. This mechanism also has the advantage that it can be used uniformly after initial user registration at the website, as well as after every successful login.

|tHUδ| The website could also offer a hyperlink to enable the user to trigger creation of and receive a new image list and bit position map. Such a user controlled remapping enables the user to have the flexibility in choosing the right time for renewing the database. For example, when a user has accessed the website from a public computer, the user can later trigger a remap when accessing from the user's personal computer. As a result, if any public -key-embedded captcha related data were compromised at the public computer, it is essentially nullified via the generation of a new image list and bit position map.

|$I$I4^™| If the user is attacked due to access from a public computer, then a backup mechanism is needed to recover the right to the username. With such a mechanism, the user support function within the user's trusted system, e.g., personal computer, would need to collect and store the various captcha-based challenges that it receives over a period of time. In case of an identity attack, the user could present all of the stored challenges to the authentic website to stake it's claim to a particular username/password. The website would check whether the captchas are indeed valid by determining whether they contained the correct image and corresponding sub-part of the public -key, at those respective time-instances, as per its history of various image lists and bit position maps for the username. If sufficiently satisfied, the website can consider the proposing user support function to be a valid representative of the user and generate a new and valid image list and bit position map for the user.

Claims

WHAT IS CLAIMED IS:

1. A method for securing a communication session, the method comprising: receiving at a client from a website a challenge including an image object information embedded with a pattern of a secure channel invariant, the received data linked specifically to a user associated with the client; and authenticating the website by comparing the received data pattern with an identified portion of a website public -key.

2. The method as recited in claim 1, wherein the website public -key is received from the website during establishment of the communication session.

3. The method as recited in claim 2, wherein identifying the portion of the website public key comprises: searching for an image object in a database list at the client that matches the image object information in the challenge; determining a set of bit positions that is mapped to the matched image object in the database list; identifying a substring of the website public key corresponding to the determined bit positions.

4. The method as recited in claim 1, further comprising: terminating the communication session if the received data pattern does not match the identified portion of the website public key.

5. The method as recited in claim 1, further comprising: providing a password indication to the website if the received data pattern matches the identified portion of the website public key.

6. The method as recited in claim 1 , further comprising: transmitting a response to the website if the received data pattern matches the identified portion of the website public key, the response comprising tag data representing an image object and a data pattern linked thereto, the image object of the transmitted response being different from the image object of the received challenge.

7. The method as recited in claim 6, wherein the step of transmitting a response comprises: identifying an object image for transmission in response to the data received from the website; and correlating a data pattern with the identified object image.

8. The method as recited in claim 7, wherein the correlated data pattern is a substring of the website public -key different from the substring of the public-key identified in the authenticating step.

9. A method for securing a communication session, the method comprising: receiving a communication at a website from a client; generating a user solvable challenge including an image object representation embedded with a pattern of a secure channel invariant, the generated challenge linked specifically to a user associated with the client; transmitting the generated challenge to the client for solving by the user; receiving from the client, a response comprising tag data representing an image object and a data pattern linked thereto, wherein the image object of the received response is different from the image object of the transmitted challenge; and authenticating the user by comparing the data pattern in the response with an identified portion of the secure channel invariant.

10. The method as recited in claim 9, wherein the received communication includes user identity information.

11. The method of claim 10, wherein the generated challenge is linked specifically to the user based on the received user identity information.

12. The method as recited in claim 9, wherein the pattern of the secure channel invariant is a substring of the website public-key.

13. A computer-readable storage element having computer readable code stored thereon that when executed causes a client to perform the following: receiving from a website a challenge including an image object information embedded with a pattern of a secure channel invariant, the received data linked specifically to a user associated with the client; and authenticating the website by comparing the received data pattern with an identified portion of a website public -key.

14. A client system for authenticating a communication session with a website, the system comprising: a processor and a database; wherein the database comprises at least one record correlated with a website, the record containing tag data representing different types of image objects, each linked to a specific set of bit positions that correspond to a substring of a website public-key; and the processor is configured to: access the database upon receiving a user solvable challenge from the website; and determine whether the received challenge includes data that corresponds to a substring of the website public -key.

15. The system as recited in claim 14, wherein the processor is further configured to transmit a response to the website if the received challenge includes data that corresponds to a substring of the website public -key, the response comprising tag data representing a second image object and a substring of the public- key linked to the second image object.

16. The system as recited in claim 15, wherein the processor is configured to: render the received user solvable challenge; accept user input data pertaining to the solved challenge; search the database list for tag data of an image object that matches the user input data; determine a set of bit positions that are mapped to the matched image object in the database list; identify a substring of the website public key at corresponding bit positions; and authenticate the website if the received challenge includes data that corresponds to a substring of the website public key.

17. A system for securing communication sessions, the system comprising: a website comprising a processor and a database; wherein the processor is configured to generate a public -key; and the database comprises records corresponding to specific remote communication users, each record correlating different types of image objects with specific substrings of the public -key.

18. The system as recited in claim 17, wherein the processor is configured to transmit, in response to receiving a communication from one of the users, data accessed from the database, the accessed data including a specific type of image object information and substring of the website public -key linked thereto.

19. The system as recited in claim 18, wherein the processor is further configured to receive a response to the transmitted data from the user by, identifying a record in the database that contains a second specific type of image object information linked with a different substring of the public -key; and determining if the received response comprises data representing the second specific type of image object information and data matching the different substring of the public -key.

20. The system as recited in claim 19, wherein the processor is further configured to terminate communication if the determination indicates a non-match.