WO2007038283A2

WO2007038283A2 - Web page approval and authentication application incorporating multi-factor user authentication component

Info

Publication number: WO2007038283A2
Application number: PCT/US2006/037002
Authority: WO
Inventors: James N. Stickley Iii; Joseph E. Breaux Iii
Original assignee: Tracesecurity, Inc.
Priority date: 2005-09-23
Filing date: 2006-09-21
Publication date: 2007-04-05
Also published as: WO2007038283A3

Abstract

A computerized process comprising providing at least one approval database comprised of data representing one or more domain names or one or more internet protocol addresses, or both, associated with an approved Web page instance; comparing (a) one or more domain names or one or more internet protocol addresses, or both, associated with a browser-accessed Web page instance against (b) data in the approval database to determine the answer to the question of whether each of the one or more domain names, if any, and each of the one or more internet protocol addresses, if any, associated with the browser- accessed Web page instance matches any domain name or internet protocol address in the approval database; and generating an approval result indicative of the answer to the question posed for the one or more domain names, if any, and the one or more internet protocol addresses, if any, associated with the browser- accessed Web page instance,.to thereby enable display of the approval result to a user of the browser.

Description

WEB PAGE APPROVAL AND AUTHENTICATION APPLICATION

INCORPORATING MULTI-FACTOR USER AUTHENTICATION COMPONENT

TECHNICAL FIELD

[0001] The present invention relates to computers and software, and more particularly to methods and systems for assessing and/or verifying the authenticity of electronic communication and communication systems implemented over computer networks.

BACKGROUND

[0002] In its present state, the Internet includes numerous fraudulent or malevolent Web sites developed by malicious persons or organizations. The purpose of these Web sites is to deceive one or more Internet users into thinking the Web sites are owned by another, usually a trusted person or entity. Through this deception, the malicious Web site developer or host causes the unsuspecting Internet user to open a fraudulent or malevolent Web page in a Web browser software program, in some cases thereby surreptitiously uploading malicious code to the user's computer. During upload, the Web page may in fact upload one or more images, code and/or text from one or a plurality of locations on the network accessed through one or a plurality of domains, sub-domains or internet protocol addresses (sometimes also referred to herein as "IP addresses"). The aggregate data uploaded to the user's computer as the result of accessing the given Web page using its associated uniform resource locator, sometimes referred to herein as a "Web page instance," includes source information identifying the source domain name or names, sub-domain name or names and/or internet protocol address or addresses. Throughout this disclosure and the appended claims, unless specified otherwise or by context, the term "domain name" shall include both domains and sub-domains. In other cases, rather than uploading malicious code, the user is deceived by the content of the images and/or text uploaded as part of the Web page instance, causing the user to input data to the browser and transmit sometimes personal or confidential information through interaction with the Web page instance to the host server of the domain which initiated the Web page instance. Such scams are commonly referred to as "phishing" scams. "Pharming" scams are those in which malicious code is uploaded to either the end user computer or a server, causing the user to unknowingly be directed to fraudulent web sites. "DNS poisoning" is one example of a scam in which malicious code or information is uploaded to a server, causing corruption of the DNS server domain name system table, which thereby causes all users of that DNS server to be misdirected unknowingly to fraudulent Web sites. The malicious or fraudulent Web page instances are sometimes referenced via email, where users are tricked into believing a particular Web page is part of a Web site which is sponsored or hosted by a legitimate business or entity. By unknowingly uploading personal or confidential information upon interaction with a malicious Web page instance, in many cases the user has unwittingly provided information which can be used to further invade the user's privacy, to perpetrate a fraud such as, e.g., identity theft, or worse. Many of the current, so-called "spyware" removal software applications simply do not prevent or protect against all of these scams.

[0003] While the foregoing issues highlight the continued problems associated with malicious web sites, on the one hand, legitimate and authentic web site owners continue to struggle with mechanisms for authenticating visitors to their web sites, on the other hand. Web site owners seeking to provide services to customers over the Internet, e.g., financial institutions and other e-commerce product and/or service vendors, have special and heightened concerns regarding identity theft and information security. Two-factor authentication is becoming a more and more prevalent requirement for many industries trying to simultaneously provide services to, and share private information with, customers via the Internet, while securing customer information and preventing fraudulent web site use. Yet the two-factor authentication systems which are known rely upon customers to keep track of numerous passwords and authentication regimes, employ biometric hardware or carry cumbersome password generating devices (a/k/a pocket fobs) in order to interface with two-factor authentication systems.

[0004] A need thus exists for an efficient way to verify that a network user is uploading a Web page instance from a trusted web site, while also preventing inadvertent access to or use of known malicious web sites or of sites that may pose a risk to the end user. A need also exists for facile methods and systems which also enables authorized web site users to management multiple security keys or codes for a plurality of sites requiring multi-factor authentication, all in a manner which promotes security while enhancing the user experience through a simplified interface.

[0005] The following terms and acronyms may be used throughout this document. Their definitions are provided for the convenience of the reader; however, no limitation on the scope of the invention should be implied herefrom.

[0006] "Web page instance": All data, including but not limited to internet protocol addresses, domain names, images, HTML text and executable or other electronic files, which are uploaded to a user's computer when the user provides specific uniform resource locator input to an operative web browser installed on the computer.

[0007] "Approved Web page instance": A Web page instance determined to be safe for viewing and use by a browser user or by a third party who is trusted by the browser user.

[0008] "Approval database": A collection of data identifying domain names and corresponding internet protocol addresses, all of which are associated with an Approved Web page instance.

[0009] "Associated": When used generally to describe the relationship between an internet protocol address and a domain name or subdomain, it means that the domain name or subdomain resolves to the internet protocol address when processed during a DNS lookup. When used to describe the relationship between an internet protocol address or a domain name or subdomain name and a Web page instance, it means that the internet protocol address, domain name and/or sub-domain is called upon to download data to a browser which has instigated the uploading of a given Web page instance using a uniform resource locator.

[0010] "Authenticated Web page instance": A Web page instance the associated domain names of which have been verified through cross-checking of the corresponding internet protocol addresses against the internet protocol addresses for those particular domain names according to the records of a verifying agency, e.g., an official domain name registrar.

[0011] "Authentication database": A collection of data identifying domain names and corresponding internet protocol addresses, all of which are associated with an Authenticated Web page instance.

[0012] "Approval result": Information in the form of a visual or audible message indicating whether one, some or all of the domain names and internet protocol addresses associated with a given Web page instance match respective domain names and internet protocol addresses in an approval database.

[0013] "Authentication result": Information in the form of a visual or audible message indicating whether one, some or all of the domain names and their associated internet protocol addresses, which collectively are associated with a given Web page instance, match respective authenticated domain names and associated internet protocol addresses in an authentication database.

[0014] "Uniform Resource Locator" ("URL"): A unique address which fully specifies the location of a file or other resource on a computer network, e.g., the internet, a WAN, a LAN, etc. The general format of a URL for internet application is protocol://machine address.port/path/filename. The port specification is optional, and if none is entered by the user, the browser defaults to the standard port for whatever service is specified as the protocol. For example, if HTTP is specified as the protocol, the browser will use the HTTP default port.

[0015] "Web Site": A computer system that servers informational content over a network using standard protocols of the web. Typically, a web site corresponds to a particular internet domain name, such as TRACESECURITY.COM", and includes the content associated with a particular organization such as TraceSecurity, Inc. The term is generally intended to encompass both (1) the hardware/software server components that serve the informational content over the network, and (2) the "back-end" hardware-software components, including any non-standard or specialized components that interact with the server component to perform service for web site users.

[0016] "World Wide Web" or "web": Refers generally to both (1) a distributed collection of interlinked, user-viewable hypertext documents ("web documents" or "web pages") that are accessible via the internet, and (2) the client and server software components which provide user access to such documents using standardized internet protocols. Currently, the primary standard protocol for allowing applications to locate and acquire web documents is HTTP, and the web pages are encoded using HTML. However, the terms "web" and_ world wideweb" as used herein are intended to encompass future mark-up languages and transport protocols which may be used.

SUMMARY OF THE INVENTION

[0017] The present invention fulfills the foregoing need, amongst others, by providing in one embodiment a software application, e.g., a toolbar add-on for a web browser, which monitors all communication between a Web browser and a Web page instance the browser attempts to access upon input from a browser user. The application compares every domain name, sub-domain and internet protocol address that is accessed against at least one approval database (sometimes also referred to herein as "approved database") that is stored on, or accessible to, the user's computer. The approval database contains domain names and IP addresses of web pages, or of entire web sites, which have been pre-approved by a trusted third party (e.g., the application distributor) or pre- approved by the browser user. In another embodiment, the application also enables the user to add to the approval database domains and/or sub-domains of a given Web page instance which the user believes should be considered approved. [0018] In another embodiment of the invention, there is provided a software application which similarly monitors all Web browser communication, and compares every domain name and sub-domain name that is accessed with the browser against at least one authentication database (sometimes also referred to herein as "authenticated database") that is stored on, or accessible to, the user's computer. In this embodiment, the authentication database(s) contain data identifying domain names and sub-domains and their associated IP addresses that have been verified by the database developer as authenticated, through a cross-check of the domain name and its associated IP address against an official record, e.g., an official domain registrar record, for that domain name. In another embodiment of the invention, a "malicious" database is provided. This malicious database contains domain names and IP addresses that are associated with Web page instances which are known to be malicious or fraudulent. A third database is maintained by the end user of the software tool, the database containing - — domain names and IP addresses corresponding to the Web sites selected as trustworthy by the end user, thereby providing end users the ability to approve and identify the Web sites they trust. A fourth database is available for vendors who wish to distribute the tool. This fourth database contains domain names submitted by the vendor to the developer, for approval by the developer and subsequent inclusion in the fourth database.

[0019] In another embodiment of the present invention, the authentication database of domain names and associated IP addresses employed by the software application is itself further authenticated through a process which employs a cross-check of the database, or of one or more records with in the database, against a verification resource. Suitable examples of a verification resource can include, for example, an encrypted authentication database, an encrypted field in the database which marks whether a record has been modified from the originally issued version, an encrypted code, key or identifier which is automatically generated and is unique to a particular record set, or the like. In this way, the validity of the authentication database, or records within the authentication database, are reviewed and verified as true and accurate, even periodically or continuously, to reduce the vulnerability of the authentication database to corruption, e.g., through hacking.

[0020] Still another embodiment of the present invention provides a computerized process comprising: providing at least one approval database comprised of data representing one or more domain names or one or more internet protocol addresses, or both, associated with an approved Web page instance; comparing (a) one or more domain names or one or more internet protocol addresses, or both, associated with a browser-accessed Web page instance against (b) data in the approval database to determine the answer to the question of whether each of the one or more domain names, if any, and each of the one or more internet protocol addresses, if any, associated with the browser-accessed Web page instance matches any domain name or internet protocol address in the approval database; and generating an approval result indicative of the answer to the question posed for the one or more domain names, if any, and the one or more internet protocol addresses, if any, associated with the browser-accessed Web page instance, to thereby enable display of the approval result to a user of the browser. In another embodiment, this computerized process further comprises: providing at least one authentication database comprised of data representing and classifying as authenticated (x) one or more domain names associated with an authenticated Web page instance and (y) one or more internet protocol addresses identified in an official record as associated with at least one of the one or more domain names associated with the authenticated Web page instance; with respect to at least one of the one or more domain names associated with the browser-accessed Web page instance which matches a domain name associated with the approved Web page instance, so as to constitute an approved domain name, comparing (m) the approved domain name, and all of the internet protocol addresses associated with the approved domain name, against (n) data in the authentication database to determine the answer to an additional question of whether the approved domain name, and each of the internet protocol addresses associated with the approved domain name, match a domain name or internet protocol address in the authentication database; and generating an authentication result indicative of the answer to the additional question posed for the approved domain name associated with the browser-accessed Web page instance, to thereby enable display of the authentication result to a user of the browser.

[0021] The present invention also provides, in yet another embodiment, apparatus comprising a storage component for storing at least one approval database into which one or more domain names or one or more internet protocol addresses, or both, associated with an approved Web page instance are entered; a processing component, operatively connected to the storage component, the processing component being configured to compare (a) one or more domain names or one or more internet protocol addresses, or both, associated with a - browser-accessed Web page instance against (b) data in the approval database to determine the answer to the question of whether each of the one or more domain names, if any, and each of the one or more internet protocol addresses, if any, associated with the browser-accessed Web page instance matches, any domain name or internet protocol address in the approval database; and for generating an approval result indicative of the answer to the question posed for the one or more domain names, if any, and the one or more internet protocol addresses, if any, associated with the browser-accessed Web page instance, and a display component, operatively connected to the processing component, for displaying the approval result to a user of the browser.

[0022] Another embodiment of the present invention provides a computerized, two-way authentication method, the method comprising determining a level of Web page instance authenticity for a Web page instance initiated by a user, displaying indicia of the level of Web page instance authenticity, displaying at least a portion of the Web page instance to thereby enable the user to receive a challenge requiring a specific, algorithmically-generated response in order to authenticate the user, and generating the response to the challenge using an alphanumeric key associated with the user by a host of the Web page instance.

[0023] Still another embodiment of this invention provides a computerized, two- way authentication method, the method comprising determining a level of Web page instance authenticity for a Web page instance initiated by a user, displaying indicia of the level of Web page instance authenticity, displaying at least a portion of the Web page instance to thereby enable the user to receive a challenge requiring a specific, algorithmically-generated response in order to authenticate the user, storing a plurality of different alphanumeric keys, each alphanumeric key being associated with both a domain of an authenticated Web page instance and the user, and . . . generating the response to the challenge using one of the stored plurality of different alphanumeric keys.

[0024] These and other embodiments, features, objects, and advantages of this invention will be still further apparent from the ensuing description, drawings, and appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Illustrative embodiments of the present invention will now be described, with reference to the accompanying drawings which are summarized as follows:

[0026] Fig. 1 depicts a flowchart diagram of a software program for carrying out a method in accordance with one embodiment of this invention.

[0027] Fig. 2 depicts a flowchart diagram of a software program for carrying out a method in accordance with another embodiment of the present invention.

[0028] Fig. 3 depicts a flowchart diagram of a software program for carrying out a method in accordance with yet another embodiment of the present invention.

[0029] Fig. 4 depicts a flowchart diagram of a process for registering and authenticating one or more domain names in accordance with one embodiment of the present invention.

[0030] Fig. 5 depicts a flowchart diagram of one database authentication process component from the method depicted in the flow diagram of Fig. 3.

[0031] Figs. 6-19 depict different screenshots of the graphical interface of a toolbar software program in accordance with one embodiment of this invention.

[0032] Fig. 20 depicts a schematic block diagram of a computer system in accordance with one embodiment of this invention.

[0033] Fig. 21 depicts another screenshot of the graphical interface of the toolbar software program of Figs. 6-19.

[0034] Fig. 22A depicts part of a flowchart diagram of a software system for carrying out a method in accordance with another embodiment of this invention, facilitating multi-factor user authentication.

[0035] Fig 22B depicts the rest of the flowchart diagram of Fig. 22A.

[0036] Fig. 23 depicts a flowchart diagram of a component of the software system of Figs. 22A and 22B, the component facilitating user-specific encryption key management.

[0037] Figs. 24-40 depict different screenshots of the graphical interface of the software system of Figs. 22A-23.

[0038] In each of the above figures, like numerals or letters are used to refer to like or functionally like parts among the several figures. DETAILED DESCRIPTION OF THE INVENTION

[0039] The present invention will now be described in detail with reference to the accompanying drawings. While the present invention is described in the context of an Internet-based data communications network, which includes a specific number and type of components, the system of the present invention may be incorporated into data communications and computing network environments of varying structures and sizes (e.g.: networks implementing wireless application protocol, or WAP; a local area network, or LAN; a wireless local area network, or WLAN; a wide area network, or WAN; asynchronous transfer mode, or ATM; a logical network within a single computer; some other form of programmatic communication such as inter-process communication or dynamic link libraries; or any combination thereof). Those skilled in the art will appreciate that such network computing environments will typically encompass many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. Furthermore, databases described herein as part of the present invention may be stand-alone databases or distributed database systems comprising a plurality of databases connected to or accessible by a common processor.

[0040] Typically, the practice of embodiments of the present invention is undertaken through the use of various forms of information technology. For example, in one embodiment of this invention, a software program running on one or more personal computers is implemented to practice a process of this invention. In another embodiment, the software program runs on a personal computer configured with a network connection, e.g., an Internet connection, to a computer server. Embodiments within the scope of the present invention also include program products comprising computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, such computer-readable media can comprise RAM, ROM, EPROM, EEPROM, CD- ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above are also to be ! included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.

[0041] Embodiments of the invention are described in the general context of method steps, which may be implemented in one embodiment by a program product including computer-executable instructions, such as program code, executed by computers in networked environments. Generally, program products include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer- executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.

[0042] Software and web implementations of the present invention could be accomplished with programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps, calculation steps and decision steps. It should also be noted that the word "component" as used herein and in the claims is intended to encompass implementations using one or more lines of software code, and/or hardware implementations, and/or equipment for receiving manual inputs.

[0043] In one embodiment of the invention, the various participants may each utilize a general purpose computer system connected to an electronic network, such as a computer network. The computer network can also be a public network, such as the Internet. By way of example, the computer system may include a central processing unit (CPU) connected to a system memory. The system memory typically contains an operating system, a BIOS driver, and application programs. The application programs include one or more calculation routines for calculating various values for various parameters to be. discussed __ hereinafter using appropriate algorithms. The application programs provide appropriate application programming interfaces (API) through which the relevant calculations and communications can be implemented. For the present application, "API," or application programming interface, is a library of programmatic methods provided by a system of some kind (an example is a web- based imaging system) that enables client programs (web content operating within the browser is one example) to interact with that system. One method of creating an API is to create a library. For example, in Java, a library (conventionally called a jar file) is created by defining a class or classes, compiling the class or classes, and grouping the class or classes into a library. Additionally, the application programs may access various distributed external databases. In addition, the computer system may comprise or further comprise input devices such as a mouse and a keyboard, and output devices such as a printer and a display monitor. The computer system generally includes a communications interface, such as an ethernet card, to communicate to the electronic network. Other computer systems also connect to the electronic network which can be implemented as Wide Area Network (WAN) or as a public network such as the Internet. One of skill in the art would recognize that the above system describes the components of a computer system connected to an electronic network. It should be appreciated that many other similar configurations are within the abilities of one skilled in the art and all of these configurations could be used with a method of the present invention. Furthermore, it should be recognized that the computer system and network disclosed herein can be programmed and configured, by one skilled in the art, to implement the method steps discussed further herein.

[0044] The following description of the preferred embodiments of the invention relates to Web pages. It is noted as a preliminary matter, though, that while it is particularly well suited for use while browsing Web pages, the invention is not necessarily limited to use with Web pages. The accompanying drawings are intended to provide examples of a data communication network configuration in which a method and system of the present invention may be implemented and are not intended to limit the applicability of the present invention to other network or computer system configurations.

[0045] Turning now to the drawings, Fig. 1 illustrates a flowchart diagram of a . process carried out by one embodiment of this invention. The process is carried out in order to screen a Web page instance to determine if the domains, sub- domains and associated IP addresses for the Web page instance are known and are either approved, authenticated or malicious. In block 10, the illustrated process starts with a user directing a Web browser program to a particular URL. This is accomplished by any conventional manner, such as, e.g., clicking upon an email link or a link embedded in an HTML document or entering a particular URL into a browser address field. The browser then connects to the Web server associated with the URL at block 12. This initiates a transmission of data from the Web server associated with the URL to the Web browser, in turn initiating an approval process in block 14. The approval process analyzes the data transmitted from the Web server and generates one or more signals conveying information (in blocks 16A, 16B and 16C) for display to the user of the Web browser. The messages conveyed in and displayed through the signals inform the Web browser user about whether the Web page instance initiated by the W

entered URL uploaded information from an approved, authenticated or malicious source, based upon whether the data transmitted to the Web browser user's computer originated from sources which have been identified and classified in one or more databases accessible to the screening computer application of this invention installed on the user's computer. As used herein, the categories of "approved," "authenticated" and "malicious" are employed for illustrative convenience to convey a certain level of authenticity. These terms are by no means exclusive, as other terms or phrases could be used to convey the same basic meaning. Thus, "approved" or a like term refers to an authenticity level wherein a Web page instance has been reviewed by a third party or the browser user and the Web page instance has been deemed acceptable for normal browser viewing and interaction. "Authenticated" or a like term refers to an authenticity level wherein all of the domain names (including all sub-domains) employed by or otherwise associated with a Web page instance, and their associated IP addresses, have been verified against a database of pre-screened - domains and associated IP addresses. "Malicious" or a like term refers to an authenticity level wherein at least one of the domain names or sub-domains employed by or otherwise associated with a Web page instance, or an associated IP address, is present in a database of domains and/or IP addresses previously identified as malicious, fraudulent or unverifiable, or the domain or sub-domain does not resolve to the IP address pre-assigned to that domain or sub-domain in the authentication database. Rather than employing all three classifications of approved (or the like), authenticated (or the like) and malicious (or the like), some embodiments of the present invention may only provide a result indicating whether the sources of a Web page instance are approved or malicious, while other embodiments may only provide a result indicating whether the sources of the Web page instance are authenticated or malicious sources. Similarly, other categorizations of a Web page instance may be employed. Thus, for example, an additional intermediate category of "unapproved" or the like might be envisioned to convey the fact that the domain names and IP addresses of a particular Web page instance are not capable of being characterized as "approved" or "authenticated" or "malicious," but rather fall into a gray area because none of the databases contain data which permits such a characterization. Nevertheless, all such variations of the overall process fall within the spirit and scope of the broad embodiments of the present invention.

[0046] Thus, in Fig. 2 there is illustrated an embodiment of this invention in which the approval process of block 14 in Fig. 1 produces results indicating only whether the sources of the Web page instance, i.e., the domain names, sub- domains and IP addresses, are approved or malicious. The approval process of block 14 in Fig. 1 is thus carried out when a Web server returns IP addresses and/or domain names to the browser, as illustrated in block 15. The application of this embodiment of the invention compares each domain name, sub-domain name and/or IP address from the browser-accessed Web page instance to conduct the if-then analysis, with respect to each of them, set forth beginning with block 20. In this analysis, the application does a comparison of the domain names and/or IP addresses with an approval database accessible to the application. If a domain name or IP address is in an approval database accessible to the application per block 22, the domain name or IP address is flagged or classified as "approved" per block 26. If it is not in the approval database per block 24, it is flagged or classified as "malicious" per block 28. The results of this analysis are stored as noted in block 30 and the process is repeated at block 34 for all of the additional domain names, sub-domains and/or IP addresses, if any, when the answer to the query in block 32 is "yes." In the depicted flowchart of Fig. 2, the application then generates a display signal revealing the stored results (either block 16A or 16C) for display on the computer display, to convey whether the domain names and IP addresses, if any, of the browser-accessed Web page instance were all classified as "approved" or any of those domain names and IP addresses, if any, were classified as "malicious." In the depicted embodiment, a yellow colored button bearing the text "Approved" flashes in the toolbar if all were classified "approved," per block 16A, while a red colored button bearing the text "Malicious" flashes in the toolbar if any one was classified as "malicious," per block 16C. While the depicted flowchart illustrates this analysis of all domain names, sub-domains and IP addresses as a sequential process which is repeated, as necessary, it is of course conceivable that the analysis for each or some of the domain names and IP addresses alternatively could be conducted using a different order, e.g., concurrently. It is also conceivable that the process would not be repeated if any domain, sub-domain or IP address was determined to be missing from the approval database. In such case, the application could be configured to simply display the "Malicious" button per block 16C without conducting the analysis with respect to any other domains or IP addresses associated with that particular Web page instance.

[0047] As illustrated in Fig. 3, another embodiment of this invention provides a process which incorporates an additional layer of authentication to thereby enable the browser user to know whether the domains, sub-domains and IP addresses from which a browser-accessed Web page instance originate are "approved," "unapproved" (sometimes also referred to as "not approved"), "authenticated," or "malicious." The depicted embodiment provides an approval process (see block 14 from Fig. 1) which screens the domain names, sub-domains and IP addresses of a browser-accessed Web page instance against one or more-approval databases maintained in, or accessible to, the application to determine if the Web page instance is an approved Web page instance, and also screens the approved domain names and sub-domains against one or more similarly maintained or accessible authentication databases to verify whether the domains and sub- domains from which the browser-accessed Web page instance originate resolve to internet protocol addresses associated with pre-verified domain names and sub-domains. The application of this embodiment of the invention compares each domain name, sub-domain name and/or IP address from the browser- accessed Web page instance to conduct the if-then analysis, with respect to each of them, set forth beginning at block 20. If the domain or IP address is in the approval database, as noted in block 22, then the domain or IP address is deemed "Approved" and proceeds to a IP address lookup (e.g., via a DNS server) based upon the domain, if applicable (block 39), and then to an additional if-then authentication analysis (block 40). If the domain or IP address is not in the approval database, a secondary query at block 35 determines whether the domain or IP address is in a "black list" database of known malicious or fraudulent web resources. If the domain or IP address is in the "black list" database, then a flashing red button reading "Malicious" appears on the toolbar during viewing of the Web page instance, as noted in block 16C and no further processing of that Web page instance is conducted (enhancing processing speed). If the domain or IP address is in neither the approval database nor the "Black List" database as noted in block 36, the domain or IP address is flagged as "Unapproved" as noted in block 37, to convey the idea that the domain or IP address falls into an intermediate category since it is neither approved nor malicious. This result is then stored as noted in block 60.

[0048] Further with respect to the application illustrated in Fig. 3, if the domain name, sub-domain or IP address is determined to be "Approved" and the authentication analysis beginning at block 40 is commenced, the authentication analysis conducted by the application involves a look-up of the IP address resolved in block 39 in the various databases maintained in, or accessible to, the application. Thus, if the resolved IP address matches an IP address and domain name in the authentication database per block 42, the domain name or IP address may be flagged as "authenticated" as in block 52, or as further illustrated in Fig. 3, an additional authentication of the result may be carried out by comparing the result against an encrypted authenticated database as noted in block 50. This additional authentication of the result is described in greater detail below with reference to Fig. 5. If the resolved IP address which was matched to data in the authentication database fails to authenticate against the encrypted authenticated database, then the user is notified of this compromise and prompted to download an updated version of the authenticated database, as noted in block 16E. The toolbar also displays the flashing red "Malicious" button, as noted in block 16C. If the IP address which was matched to data in the authentication database does authenticate against the encrypted authenticated database, the domain is flagged as "Authenticated" as noted in block 52 and the result is stored as noted in block 60.

[0049] If the resolution of an IP address from a domain in block 39 is unsuccessful, either because the URL under analysis is an IP address rather than a domain or sub-domain, or because the domain lookup of block 39 otherwise failed as noted in block 43, the URL is flagged as "Approved" as noted in block 56 and the result is stored per block 60. When the results of the initial authentication query in block 40 reveal that the domain, when applicable, is not in the authentication database, as noted in block 44, the domain is flagged as "approved" per block 56 and the results are stored as noted in block 60. If the IP address to which the domain or sub-domain resolves failed to match with that domain in the authentication database as noted in block 46, a flashing red "Malicious" button appears on the toolbar per block 16C during viewing of the Web page instance and no further processing of the Web page instance is conducted. If the IP address to which the domain resolves is an IP address on the "Black List" database as noted in block 48, then a flashing red button reading "Malicious" appears on the toolbar during viewing of the Web page instance, as noted in block 16C and no further processing of that Web page instance is conducted.

[0050] As will be appreciated from the application illustrated in Fig. 3, and in particular blocks 62 and 64, the approval and/or authentication process is conducted for each and every domain name, sub-domain and IP address returned to the browser upon initiation of the Web page instance, unless the IP address or domain is determined to be on the "black list" or the database is determined to be compromised, in which case further processing can be terminated and the user appropriately notified of the malicious status of the Web page instance or database corruption. When the case is otherwise and all domains and IP addresses are analyzed, once all IP addresses and/or domains have undergone the analysis, the stored results determine the nature of the signal provided through the toolbar or other display to the browser user. If all stored results were flagged as "authenticated," then in this embodiment of the invention a flashing green button reading "Authenticated" appears on the toolbar during viewing of the Web page instance, as noted in block 16B. If some stored results are flagged "Authenticated" and the rest are flagged "Approved," then a flashing yellow button reading "Approved" appears on the toolbar during viewing of the Web page instance, as noted in block 16A. If any of the stored results was flagged as "Malicious," then a flashing red button reading "Malicious" appears on the toolbar during viewing of the Web page instance, as noted in block 16C. If none of the stored results was flagged "Malicious," but one or more results was flagged as "Unapproved" or "Not Approved," then a flashing red button reading "Not Approved" appears on the toolbar during viewing of the Web page instance, as noted in block 16D. Finally, if in the stored results any IP address or domain is flagged as "Database Compromised," the user of the browser is prompted, as noted in block 16E, to download an updated authentication database from a trusted provider of the authentication database, e.g., through an upload from a vendor's web-accessible server. In other embodiments of this invention, the approval and authentication analysis in the application may be truncated if, for example, a domain name or IP address is identified as malicious or the database is determined to be compromised, the process will simply stop and the "Malicious" or "Database Compromised" signal or message will be displayed without further processing of domains and IP addresses associated with the Web page instance in question.

[0051] In one particular embodiment of the invention providing a toolbar add-on to version 6 of Microsoft Corporation's Internet Explorer browser, the program is coded in C to conduct the authentication of approved domains and sub-domains, as illustrated for example in Fig. 3. The following is example pseudocode for toolbar software in accordance with this embodiment of the invention.

Capture all DWebBrowserEvents2 events. if DISPlD_NAV!GATECOMPLETE2:

{ if frame object not = to a newly created popup window

{ retrieve navigated to url if at least one / appears in the url

{ remove anything before any @ symbols copy all characters until it reaches a ? : / or a \

Save this string as the sub domain. extract domain from sub domain call GetHostByName using the sub domain

Save ALL ip addresses returned from the dns lookup.

Check if sub domain or domains are in a Trace security authenticated databases if In database

{ if has ip addresses

{ read in encrypted list of ip addresses for the sub domain/domain if ALL ip addresses returned from dns lookup match ip's in database { Continue with next incoming url

} else

{ Set site as malicious

} } else

{

Set not authenticated flag Continue with incoming url's } } else

{ check in custom database

} if domain/sub domain not found in any databases

{

Set as Un Approved

}

If domain/sub domain in blocked database

{ Set as malicious

}

} else

{ //Some sort of javascript function ignore, not an actual url

}

} } if DISPID_DOCUMENTCOMPLETE:

{ if frame = top level frame

{ If Not malicious and not un approved and authenticated flag still set to 1

{ Set button as authenticated

} else If not malicious and not un approved

{

Set button as approved

} } }

[0052] It should be noted that certain embodiments of this invention depend upon the existence of one or more approval databases, one or more authentication databases, and one or more "black list" databases. These databases may be maintained by or hosted on the local computer system, or on a remote computer system in operative communication with the browser user's computer upon which the executable application of this invention is installed. These databases may be created and maintained by a trusted third party, who may make the updated database files available to the computer upon which the executable application of the invention is installed, e.g., through a periodic or on- demand update over a web connection. With respect to the authentication databases, in one embodiment of this invention, these databases are created and maintained by the trusted third party. One way of creating the authentication database in an embodiment of this invention is illustrated in Fig. 4. There, it will be seen that the trusted database provider allows an account to be set up by a web site owner, as noted in block 70. As noted in block 72, the owner then provides information to the trusted database provider, including for example the domain name to be registered, a user name, a password and an email address associated with the web site owner. Jn the system illustrated, at block 74, the trusted database provider then conducts a cross-reference of the e-mail address so provided by the web site owner against the e-mail address for the owner of the domain name according to the official registrar records for that domain name. If both e-mail addresses match, a verifying e-mail containing a validation string is transmitted by the trusted database provider to the e-mail address provided by the web site owner, as shown in block 76. Upon receipt of the e-mail address, the web site owner may activate the account by replying to the e-mail message sent by the trusted database provider using the validation string, as noted in block 78. Once the account is active, the web site owner (i.e., the "end user" in Fig. 4) may log into its account as noted on block 80, using the user name and password previously provided, as noted in block 82. Once the account is established and the web site owner is logged in, the account may be configured to permit the web site owner to create assignments within the database, by adding or removing domain names and/or IP addresses consistent with the domain name level they own and have identified in the account set up process, as noted in block 84. In this way, the authentication database can be updated as needed by each web site owner. In addition, the trusted database provider may independently update the database by adding domain names, sub-domains and/or IP addresses which are verified through a cross-reference against the official registrar records for that domain. Each periodically updated authentication database may then be promulgated to the users of the application of this invention, either automatically or upon request by the application user.

[0053] As previously noted, some embodiments of the present invention may provide an additional level of authentication by including a database verification component, which is configured to further verify the authenticity of the authentication database, to protect against the possibility that the integrity of the authentication database has been compromised. See in this regard block 50 from Fig. 3. To elaborate upon the process carried out in one exemplary embodiment of the invention which includes this feature, Fig. 5 depicts one example of a software application process which conducts this verification of the authentication database. Once a domain name or IP address is determined to be in the authentication database as noted in block 42, the domain name or IP address under analysis is encoded to produce a unique record identifier, as noted in block 5OA, using any one of a number of encryption algorithms known to those of skill in the art. This unique record identifier may be, for example, an alphanumeric string generated using a specific encryption algorithm. This unique record identifier is then compared against a corresponding unique record identifier which has been generated using the same algorithm and which itself is unencrypted but is present in an otherwise encrypted version of the authentication database supplied by the trusted database provider, as noted in block 5OB.

[0054] If the unique record identifier generated for the domain name or IP address under scrutiny matches a unique record identifier in the otherwise encrypted authentication database as noted in block 5OC, the encrypted information in the encrypted authentication database associated with the unique record identifier which matches the unique record identifier under scrutiny is decrypted, per block 51. If the decrypted information matches the authenticated database information having the same unique record identifier, as noted in block 53A, the domain is flagged as "Authenticated" per block 52 and the result is stored as noted in block 60. If the decrypted information does not match the W 2

authenticated database information having the same unique record identifier, as noted in block 53B, the entire Web page instance is flagged as "Malicious" and a notification is displayed to the user indicating that the database has been compromised, as seen in block 54.

[0055] On the other hand, if the unique record identifier generated for the domain name or IP address under scrutiny does not match a unique record identifier in the otherwise encrypted authentication database as noted in block 5OD, the entire Web page instance is flagged as "Malicious" and a notification is displayed to the user indicating that the database has been compromised, as seen in block 54. An exemplary application thus might include two database files dealing with the encryption verification. First, an unencrypted database containing at least URL names, associated IP address ranges for each URL name and associated index number for each URL name. Second, an encrypted database at least containing index numbers and encrypted version of ip ranges. — Example pseudocode for this URL verification process feature of the application in this particular embodiment of the invention is set forth below. For this particular exemplary application, the code is in C for use with version 6 of Microsoft Corporation's Internet Explorer browser.

if DISPID_NAVIGATECOMPLETE2:

{

Open Authenticated Database if url found and has ip range

{

Read index number for url Open Encrypted Database for that index number

{

Read encrypted version of ip range i¹

Decrypt ip range if decrypted ip range = unencrypted version

{ Proceed with site verification

} } } }

[0056] This process is just one example of how encryption techniques may be used to provide a database verification component, as other processes employing encryption techniques will be readily apparent to those of ordinary skill in the art.

[0057] Figs. 6-19 and 21 provide screenshots of the graphical user interface of one embodiment of the present invention. In this embodiment, as seen in Fig. 6, the user interface is in the form of a toolbar add-on to a web browser, the toolbar including three pull-down menu indication arrows, and three buttons displayed directly above the web page image. Fig. 7 shows that the interface employs a first pull-down menu which enables the user to toggle an integrated popup blocker on and off, to view a list of popup sites which are allowed, to view the list of the domains of approved Web page instances, to view program settings and to obtain updates to the databases employed by the toolbar. As noted in Fig. 8, the center display button on the toolbar displays the message indicative of the stored results for the specific Web page instance being viewed (the yellow "Approved" button is shown in Fig. 8). This button includes a pull-down menu which permits the user to select to un-approve a sub-domain or domain. In contrast, and as shown in Figs. 9 and 10, if the stored results for the domain are labeled "Not Approved," the pull-down menu gives the user the option of approving the sub-domain or domain being viewed. The third button on the toolbar indicates the popup blocker status with bold text when the blocker is toggled "on," and includes a pull-down menu which allows the user to opt to approve popups from the sub-domain being viewed, or from the entire domain, as seen on Fig. 11.

[0058] Referring now to Figs. 12 and 13, when approving or un-approving a domain or sub-domain, the graphical user interface illustrated provided notifications to enable the user to select the domains or sub-domains to be approved or un-approved. Similar notifications are provided which sub-domains are added to the approved list (Fig. 14), domains are approved to allow popups therefrom (Fig. 15), sub-domains are approved to allow popups (Fig. 16) and sub-domains are removed from the list allowing popups (Fig. 18). When unapproving an entire domain from the domains from which popups are allowed, another notification is provided to inform the user that any sub-domains associated with the domain will also be barred from permitting popups (Fig. 17).

[0059] An additional feature of this embodiment of the invention provides a display of a message indicating that the browser-accessed Web page instance is still loading data to the browser. Thus, as seen in Fig. 21, when a user browses from one Web page instance (as illustrated, that generated by google.com on September 19, 2005) to the Web page instance at realpages.com, a flashing button reading "Loading" appears in the toolbar, to inform the user that the realpages.com Web page instance is loading. This message will flash until the entire Web page instance has loaded to the browser. This feature provides critical information, to inform the user that any previous indication of authentication from the previous Web page instance is no longer valid, and that the upcoming Web page instance has yet to be authenticated or approved. This prevents previous approval or authentication messages from being confused as a characterization of the currently loading Web page instance. It also prevents malicious Web page instances which might be configured to cycle load a feature to keep the Web page instance load from being completed, thereby preventing the completion of the approval and/or authentication analysis of the domains and IP addresses associated with that instance or appearing to have the approval or authentication characteristics displayed for the previously loaded Web page instance.

[0060] Also as noted in Fig. 19, this embodiment of the invention includes a field in the authentication database which represents the company name for the entity which controls the Web page instance. The data from this field is displayed on the toolbar application illustrated in Fig. 19 to display to the user the name of the entity (in this case TraceSecurity Inc.) to further guard against possible user confusion between similar domains which might appear concurrently in the authentication database. The data in this field will typically be supplied by the owner or administrator for the Web page instance loaded into the authentication database, after the trusted database provider independently verifies that information through a commercially reasonable investigation.

[0061] Fig. 20 illustrates a networked system in accordance with one embodiment of this invention. In Fig. 20, a personal computer system is comprised of a central processor unit 100 in operative connection with a display 102 in the form of a computer monitor, a first user interface selection device 104 in the form of a keyboard and a second user interface selection device in the form of a mouse 106. The central processor unit is in operative connection with the Internet (as illustrated) through conventional wired or wireless means, and has installed thereon a web browser program and an application in accordance with this invention. The internet connection so provided enables the computer system to communication with a remote server 108, which in this embodiment is also connected to the Internet by conventional means and provided by a trusted database provider. The_ trusted database provider programs server 108 to make - available up-to-date approval, authentication and blacklist databases of this invention, for upload by the end-user's personal computer system and use by the application installed thereon.

[0062] It will be appreciated that the data structure for an electronic file comprising the approval database in certain embodiments of this invention could comprise fields simply for domains, including sub-domains, and any other data of interest. Likewise, the data structure for an electronic file comprising the authentication database in certain embodiments of this invention could comprise fields for one or more of the following items:

Domain (including sub-domains)

IP Address

Domain Record Encrypt Key (Unique Identifier)

Company Name

[0063] As noted previously, the authentication database(s) and the approval database(s) may be distributed or aggregated into a single database or a subcombination thereof. [0064] In some embodiments of the invention (as noted in Figs. 6-19 and 21), the software application installed on a user's computer will be coded to include the features and utility of a popup blocker which incorporates some features which are known to those of skill in the art. Other embodiments of the invention also uniquely monitor data communication to the browser for popups and, if a popup occurs, to force the display of a software application, e.g., a toolbar, of this invention. Often times a popup can be coded to hide all browser toolbars, which can in effect defeat the purpose of a software application using a toolbar interface, since the user will be deprived of a program interface from the outset with respect to that popup window. The software application in one embodiment of this invention addresses this problem by including program code to monitor every popup and, when the popup is detected, to force the popup to allow the software application of this invention to display its approval, authentication and/or popup blocking results, as the case may be, and to otherwise be visible to the user, even if the Web page instance accessed included a popup coded to attempt to deny display of toolbars or similar add-on applications. Example pseudocode for this feature of the application in this particular embodiment of the invention is set forth below. For this particular exemplary application, the code is in C for use with version 6 of Microsoft Corporation's Internet Explorer browser.

Capture all DWebBrowserEvents2 events. if DISPID_NEWWIND0W2

{ create a new IWebBrowser2 object set view toolbars property of IWebBrowser2 object to true if Block Popups

{ set the object to hidden

} else

{ } return the IDispatch* from the IWebBrowser2 object //causes the popup to be in our created window if DISPID_BEFORENAVIGATE2

{ if object = our created popup window If Block Popups

{ If url navigating from allows popups

{ ShowWindow()

} else

{

Insert url navigating to into list

Destroy Window } }

If Click Button to Show Popups

{

While list!=NULL

{

Create Window Navigate to popup url } ^' }

If Click Button to Add UrI to Allow Popups

{

Get URL

Insert UrI into database }

[0065] In addition, one challenge in screening data from a given Web page instance for associated domains, sub-domains and IP addresses is determining when a given browser-accessed Web page instance ends and a new browser- accessed Web page instance begins. In one embodiment of the present invention, the toolbar software application is coded in C to address this issue in conjunction with version 6 of Microsoft Corporation's Internet Explorer browser. Example pseudocode for this aspect of the application in this particular embodiment of the invention is set forth below.

Capture all DWebBrowserEvents2 events. if DISPID_BEFORENAVIGATE2:

{

If Top Level frame = NULL

{ Set Top Level Frame pointer= current frame

}

If Top Level Frame = Our Top Level Frame Pointer { if(URL not = a javascript command)

{

Set new navigation = true

Reset all the notification buttons } }

[0066] Turning now to Figs. 22A and 22B, it will be seen that still another embodiment of this invention provides the additional feature of facilitating multi- factor user authentication and coupling that feature with authentication of a user- or browser-initiated web page instance so as to provide a two-way (or mutual) authentication system. Thus, the flowchart diagram of Figs. 22A and 22B illustrates the process of an embodiment of the invention carried out by a toolbar application in communication with a properly configured web site host server, which web site and server are configured to require multi-factor user authentication. For purposes of illustration of the embodiment of Figs. 22A and 22B, it is assumed that the user has initiated the web page instance by browsing to a primary login URL for the web site and has provided preliminary identification, and that the web site has processed and initially authenticated the user from the preliminary identification information supplied. Such a preliminary information might be, for example, a user name or other assigned identifier, alone or in combination with other such identifiers. Then, the web site posts an essentially random "challenge," as noted in box 200, to the user and invites the user to supply a response, all through a web page displayed in a browser window viewed through a display. The random challenge is typically an alphanumeric string, but can be any combination of machine-readable symbols suitable for use, or conversion for use, as a variable within a mathematical algorithm. Before, during and/or after calculating a response to the challenge, and typically without any interaction from the user, the toolbar application undertakes an analysis to determine and display a level of authenticity for the web page instance, in accordance with previously described methods of this invention. In the embodiment depicted, the analysis of the web page instance authenticity is conducted before the challenge is even displayed. If the Web page instance to which the user has browsed is determined to be malicious (box 204), the toolbar application generates a popup warning for display to the user and prevents display of any user authentication interface, per box 210. If the Web page instance is flagged as not authenticated (but also not malicious, per box 206), a notice is displayed to the user, as noted in box 212, stating as much and allowing the user to make a choice of whether to continue with user authentication (box 216), or to discontinue user authentication (box 214). If the Web page instance is flagged as authenticated per box 208, or the user elects to continue with authentication per box 216 because the site is not malicious (although not authenticated), the toolbar application conducts a search of user keys, stored by the application locally on the client computer, for a match to the domain which is issuing the challenge, as noted in box 218. In all cases, either a single key is found (box 220), no key is found (box 222) or a plurality of keys are found (box 224).

[0067] In the event that no key is found, a complete list of all of the stored keys is displayed as noted in box 226. The user may then select (e.g.rclick) the correct key, as noted in box 230, or input the correct key to the application manually (though a keyboard or any other suitable input device) as noted in box 232. Once the key is provided manually by the user, it should be noted that the program will calculate a response per box 240, without interaction from the user, using a specific encryption algorithm also used by the host of the Web page instance. If desired, the program may also be configured to then display the response to the user, and the illustrated system does in fact display the response. An exemplary algorithm useful for calculating the response would be SHA-2, but any conventional one-way encryption algorithm may be used as long as the software application of this invention and the host employ the same algorithm to generate the correct response from the key and the randomly generated challenge. The submission of the correct response represents successful completion of a multi-factor authentication protocol.

[0068] Referring again to Fig. 22B, if the user selects the key from the list of stored keys per box 230, the program prompts the user for any password which has been associated with the selected key, as noted in box 234, and if the password is correct per box 236, the program proceeds to calculate the response using a specific encryption algorithm, also used by the host of the Web page instance, and to display that response, as noted in box 240. If the password supplied is incorrect, per box 238, the user is prompted again for the correct password as in box 234 until the correct password is supplied or the user terminates the session.

[0069] If only a single key was found from the search conducted per box 218 and box 220, the program immediately requires the user to pass through the password routine of boxes 234, 236 and 238 until a correct password is supplied, and then the response is calculated and displayed as noted in box 240.

[0070] Under all three search result scenarios (of boxes 220, 222 and 224), the desired end result is the response calculation set forth in box 240. Once that response is calculated, it may be displayed and the user prompted with options to either copy the response into an input field of the Web page instance and/or into ^~ the clipboard or other similar local computer memory (per boxes 242 and 250), manually enter another key per box 244, display the list of keys per box 246 or exit the response-generating component of the program per box 248 and 252. Once the user does elect to copy the response into the input field of the Web page instance, the response-generating component closes per box 252. In this way, the user is provided with a way to simultaneously authenticate web sites to which the user may browse and interface with web sites requiring multi-factor authentication using a challenge-response encryption protocol, all while also facilitating the management of multiple keys for multiple web sites which may require multi-factor authentication using the same sort of protocol.

[0071] Fig. 23 depicts a flowchart diagram of an additional component of the software system of Figs. 22A and 22B, the component facilitating user-specific encryption key issuance and management. The process outlined in Fig. 23 will typically be conducted independently of other processes carried out by programs of this invention. In this process, it will be typical for the user to browse to a Web page instance per box 300. The program will undertake to screen the Web page instance to assess its authenticity as hereinabove described, per box 302, and if the instance is at least not malicious (per box 304) and includes code for a command to add a new key to the user's list of stored keys, the application will pull the command per box 306 and the user will be prompted in the browser with a notice that the web site is attempting to send a new key, as noted in box 308. The server application may be configured to send the key with or without an associated alias (i.e., nickname), but in the embodiment depicted the server transmits an alias with the key. The user also will be prompted to either accept (box 310) or decline (box 312) the new key. If the user declines the new key, this component of the program will terminate per box 314. If the user accepts the new key and it is associated with a truly new alias when compared to the aliases of previously stored keys in the client application, per box 316, the toolbar application will then prompt the user to supply a domain, a security key, optionally an alias (which may be that which was transmitted with the key) and optionally a password, for that specific key. Once these items are supplied to the program, the key and the associated data sent with the key or input by the user is stored to the list of keys maintained in the application of this invention. If, as noted in box 318, the alias transmitted by the web site is already stored locally in the user's application, the user is prompted to either elect to save the key as a new key nevertheless, as noted in box 320, or to overwrite the existing key with the key being transmitted by the web site, per box 322. If the user elects to overwrite the existing key, the user is so notified that the existing key has been overwritten, as noted in box 326. Of course, it will be appreciated that the aliases assist the user in referencing and using the keys which are stored in the application for later use.

[0072] Figs. 24-40 depict different screenshots of certain graphical interfaces of a prototypical version of a toolbar application in accordance with the embodiment of Figs. 22A-23. A first-time user of the toolbar application seeking to use a web site with multi-factor authentication requirements would first obtain a key from the host server or from the host through other means of communication. As may be seen from Figs. 24-33, upon initiation of the Web page instance for the primary login URL, the screenshot of Fig. 24 shows a browser window prompting the user to supply preliminary identification information in the form of a login name. If the account is not a pre-existing one, the user is also prompted in Fig. 25 to supply a password to be used for additional security later in the program. Once the user account is established, the preliminary identification information would typically only be a user name or some other form of personal identification information. As seen in Fig. 26, the user has logged in under the user name "ptotest." If no key has been entered into the application for this web site, then the host server would prompt the user to either manually enter the key (if obtained through other means), or initiate a request that the host server run a command which will generate and transmit to the user browser a random key for use by the user in a multi-factor authentication protocol for the web site. If "continue" is selected in Fig. 26, then as seen in Fig. 27, the user is prompted before the toolbar application processes the random key being transmitted by the web site for a confirmation to proceed. Upon confirmation, the tool bar application generates a dialog box shown on Fig. 28, displaying an alias ("Site Name") and the site's associated domain ("tracesecurity.com") and a key (the "Security Key"). The dialog box also enables the user to optionally add a password to further secure the key. Upon selecting "Save," the toolbar application stores the key locally on the user's computer system as noted in Fig. 29. The screenshot in Fig. 29 presents the user the option of verifying that the stored key works properly for the web site by selecting "Continue." Upon doing so, as seen in Fig. 30, the web site issues and displays a numeric, random challenge and an input field for a response (the "Result key"). The toolbar application also displays another dialog box showing the site's associated alias (or "Site Name") and prompts the user to enter the password in order to employ the site key. Upon selecting "Submit," the application generates the response or "Result key" in a new dialog box shown in Fig. 31. The dialog box presents the user with the option of copying the response into the input field on the browser web page, to enter a key manually, to view the list of stored keys, or to close the authentication component of the program. Upon selecting "Copy," the application copies the response to the clipboard and places the response into the input field on the web page seen, as on Fig. 32. Upon electing to continue with the submission of the response, the response is transmitted to the web site and, if the response matches the response expected by the host server based upon its own calculation of the correction response, the key is verified as a working key and the user is notified as shown in Fig. 33. [0073] Figs. 34-40 illustrate screenshots of the prototype where the user is attempting to access a web site which requires multi-factor authentication, and the web site has been "authenticated" by the toolbar application of this invention. These figures assume the user has already provided preliminary identification information, such as, e.g., a user name, to the web site host server. The screenshots each display an indication of "Authenticated" in the toolbar itself, along with an associated company name (in this case, "TraceSecurity Inc."). As seen in Fig. 34, after the preliminary identification information has been provided by the user, the displayed web page issues and displays a random, numeric challenge, and two input fields, one for the response (or "Result key") and one for a user password. Since the toolbar application in this illustrative example only contained one key in its storage of keys, the toolbar application made this assessment and proceeded to display a dialog box prompting the user to enter a password to use the key associated with the web site domain's associated alias or "Site name." Upon entry and submission of the correct password, a new dialog box is displayed as seen in Fig. 35, where the challenge and the calculated response ("Result key") are displayed and the user is prompted to copy the response to the appropriate input field, if desired. Upon selecting "Copy" in this dialogue box, the response is placed in the "Result key" field, as shown in Fig. 36, and the user is prompted for the user's password. If the correct user password and response are submitted upon selecting "Continue login," the user is notified of successful login, as seen in Fig. 37.

[0074] As noted in the screehshόt display on Fig. 38, the toolbar application pulldown menu shows various user options, including importing stored keys from other files, exporting stored keys, editing stored keys and initiating a two-factor authentication session. Upon selecting Two Factor Authentication from the pulldown menu, the toolbar application opens a dialog box (see in Fig. 39) which lists all of the keys stored on the local system, and provides input fields for any challenge key issued, the calculated response or "Result key" and any required password for use of the site key. The response may be automatically calculated, or entered manually using "Manual mode" as indicated in the dialogue box. Upon selecting "Edit two-factor keys" from the pull-down menu seen in Fig. 38 a dialog box shown in Fig. 40 appears to enable the user to interface with the program to add keys, select and edit keys or delete keys which have been previously stored in the application.

[0075] It should now be appreciated that, while certain software applications of this invention illustrated above are in the form of a browser add-on in the form of a toolbar, those applications could take a number of other forms which could perform many, if not all of the same functions. Thus, for example, a stand-alone software application could be configured to conduct processes in accordance with the invention. Such other application forms are well within the skills of those of ordinary skill in the art, and are considered to fall within the scope of the present invention.

[0076] It should be noted that the challenge employed in certain embodiments of this invention are preferably random, but may also be non-random. The challenge may be a string of one or more characters, numbers or other symbols which can transferred via a web page and employed in an algorithm. In addition, the key employed in certain embodiments of this invention is preferably alphanumeric, but may be any string of one or more characters, numbers or other symbols (e.g., ASCII, alphabetic, alphanumeric, numeric) which can be transferred via a web page and employed in an algorithm.

[0077] This invention is susceptible to considerable variation in its practice. Therefore, the foregoing description is not intended to limit, and should not be construed as limiting, the invention to the particular exemplifications presented hereinabove. The following pages set forth some examples of ways in which one might attempt to claim the present invention. These exemplary claims, however, are not intended to be exhaustive or all-inclusive.

Claims

CLAIMS:

1. A computerized process comprising: providing at least one approval database comprised of data representing one or more domain names or one or more internet protocol addresses, or both, associated with an approved Web page instance; comparing (a) one or more domain names or one or more internet protocol addresses, or both, associated with a browser-accessed Web page instance against (b) data in the approval database to determine the answer to the question of whether each of the one or more domain names, if any, and each of the one or more internet protocol addresses, if any, associated with the browser-accessed Web page instance matches any domain name or internet protocol address in the approval database; and generating an approval result indicative of the answer to the question posed for the one or more domain names, if any, and the one or more internet protocol addresses, if any, associated with the browser-accessed Web page instance, to thereby enable display of the approval result to a user of the browser.

2. A process according to claim 1 , wherein the step of comparing (a) and (b) is conducted with respect to all of the domain names, if any, and all of the internet protocol addresses, if any, associated with the browser-accessed Web page instance, so that the approval result is indicative of the answer to the question posed for all of the domain names, if any, and all of the internet protocol addresses, if any, associated with the browser-accessed Web page instance.

3. A process according to Claim 1 , further comprising: providing at least one authentication database comprised of data representing and classifying as authenticated (x) one or more domain names associated with an authenticated Web page instance and (y) one or more internet protocol addresses identified in an official record as associated with at least one of the one or more domain names associated with the authenticated Web page instance; with respect to at least one of the one or more domain names associated with the browser-accessed Web page instance which matches a domain name associated with the approved Web page instance, so as to constitute an approved domain name, comparing (m) the approved domain name, and all of the internet protocol addresses associated with the approved domain name, against (n) data in the authentication database to determine the answer to an additional question of whether the approved domain name, and each of the internet protocol addresses associated with the approved domain name, match a domain name or internet protocol address in the authentication database; and generating an authentication result indicative of the answer to the additional question posed for the approved domain name associated with the browser-accessed Web page instance, to thereby enable display of the authentication result to a user of the browser.

4. A process according to claim 3, wherein the step of comparing (m) and (n) is conducted with respect to all of the one or more domain names associated with the browser-accessed Web page instance which match a domain associated with the approved Web page instance, so that the approval result is indicative of the answer to the question posed for all of the domain names associated with the browser-accessed Web page instance.

5. A computerized process comprising: providing at least one authentication database comprised of data representing and classifying as authenticated (x) one or more domain names associated with an authenticated Web page instance, and (y) one or more internet protocol addresses identified in an official record as associated with at least one of the one or more domain names associated with the authenticated Web page instance; comparing (m) one or more domain names and one or more internet protocol addresses associated with a browser-accessed Web page instance against (n) data in the authentication database to determine the answer to the question of whether each of the one or more domain names associated with the browser-accessed Web page instance and each of the one or more internet protocol addresses associated with the browser-accessed Web page instance matches a domain name or internet protocol address in the authentication database; and generating an authentication result indicative of the answer to the question posed for each of the one or more domain names and each of the one or more internet protocol addresses associated with the browser-accessed Web page instance, to thereby enable display of the authentication result to a user of the browser.

6. A process according to claim 5, wherein the step of comparing (m) and (n) is conducted with respect to all of the one or more domain names and all of the one or more internet protocol addresses associated with the browser-accessed Web page instance, so that the approval result is indicative of the answer to the question posed for all of the domain names and internet protocol addresses associated with the browser-accessed Web page instance.

7. A process according to claim 5, further comprising verifying the authenticity- of at least a portion of the data in the authentication database through a comparison of the data in the authentication database against an encrypted database from a trusted database provider.

8. Apparatus comprising a storage component for storing at least one approval database into which one or more domain names or one or more internet protocol addresses, or both, associated with an approved Web page instance are entered; a processing component, operatively connected to the storage component, the processing component being configured to compare (a) one or more domain names or one or more internet protocol addresses, or both, associated with a browser-accessed Web page instance against (b) data in the approval database to determine the answer to the question of whether each of the one or more domain names, if any, and each of the one or more internet protocol addresses, if any, associated with the browser-accessed Web page instance matches any domain name or internet protocol address in the approval database; and for generating an approval result indicative of the answer to the question posed for the one or more domain names, if any, and the one or more internet protocol addresses, if any, associated with the browser-accessed Web page instance, and a display component, operatively connected to the processing component, for displaying the approval result to a user of the browser.

9. A computer-readable medium encoded with a computer-executable software program for carrying out a process in accordance with claim 1.

10. A computer-readable medium encoded with a computer-executable software program for carrying out a process in accordance with claim 3.

11. A computer-readable medium encoded with a computer-executable software program for carrying out a process in accordance with claim 5.

12. A set of application program interfaces embodied on a computer-readable medium for execution on a computer in conjunction with an application program that assesses the authenticity of Web page instances, comprising: a) a first interface that receives one or more domain names or one or more internet protocol addresses, or both, associated with a browser-accessed Web page instance; and b) a second interface that displays at least an approval result indicative of the outcome of a comparison routine performed between an approval database and the one or more domain names or one or more internet protocol addresses, or both, associated with the browser-accessed Web page instance.

13. A set of application program interfaces according to claim 12, wherein the second interface further displays an authentication result indicative of the outcome of a comparison routine performed between an authentication database and the one or more domain names or one or more internet protocol addresses, or both, associated with the browser-accessed Web page instance.

14. A set of application program interfaces according to claim 12, wherein the second interface further displays an indication of whether the display of a popup from the browser-accessed Web page instance has been blocked.

15. In a computer system comprised of a graphical user interface including a display, a internet-connected microprocessor, a web browser program and a user interface selection device, a method of displaying Web page instance authentication information and control to a browser user, the method comprising: displaying an approval result indicative of whether a browser-accessed Web page instance is in an approval database accessible to the microprocessor; displaying at least one menu; retrieving a set of menu entries for the at least one menu, the set of menu entries comprising at least an approval function selection and an disapproval function selection with respect to the browser-accessed Web page instance, displaying the set of menu entries on the display; receiving a menu entry selection signal indicative of the selection device selecting one of the menu entries; and . . . . ... . in response to the menu entry selection signal, retrieving an application program file, wherein the application program file has the corresponding menu entry function.

16. A method according to claim 15, wherein the set of menu entries further comprises at least an approval function selection and a disapproval function selection with respect to one or more sub-domains associated with the browser- accessed Web page instance.

17. A method according to Claim 15, wherein the set of menu entries further comprises a popup approval function with respect to a domain associated with the browser-accessed Web page instance.

18. A method according to Claim 17, wherein the set of menu entries further comprises a popup approval function with respect to a sub-domain associated with the browser-accessed Web page instance.

19. A process according to any one of claims 1, 3 and 5, further comprising forcing display of approval and, if applicable, authentication results in all popup windows which are displayed.

20. A computerized, two-way authentication method, the method comprising

determining a level of Web page instance authenticity for a Web page instance initiated by a user,

displaying indicia of the level of Web page instance authenticity,

displaying at least a portion of the Web page instance to thereby enable the user to receive a challenge requiring a specific, algorithmically-generated response in order to authenticate the user, and

generating the response to the challenge using an alphanumeric key associated with the user by a host server of the Web page instance.

21. A method according to claim 20, wherein the user receives the challenge only after first providing preliminary identification information to the host server.

22. A method according to claim 21 , wherein the key is further associated with a domain of the Web page instance.

23. A method according to claim 22, wherein the key is further associated with a domain of the Web page instance by the user.

24. A method according to claim 22, wherein the key is further associated with a domain of the Web page instance by the host.

25. A method according to any of claims 20-24, wherein the step of displaying at least a portion of the Web page instance to thereby enable the user to receive a challenge requiring a specific, algorithmically-generated response in order to authenticate the user, is carried out only if the level of Web page instance authenticity meets or exceeds a pre-determined minimum level of Web page instance authenticity.

26. The authentication method of claim 25, further comprising

storing the alphanumeric key for later use by the user.

27. A computerized, two-way authentication method, the method comprising

displaying indicia of the level of Web page instance authenticity,

displaying at least a portion of the Web page instance to_ thereby enable the user to receive a challenge requiring a specific, algorithmically-generated response in order to authenticate the user,

storing a plurality of different alphanumeric keys, each alphanumeric key being associated with both a domain of an authenticated Web page instance and the user, and

generating the response to the challenge using one of the stored plurality of different alphanumeric keys.

28. Apparatus comprising

a processing component configured to determine a level of Web page instance authenticity for each Web page instance initiated by a user and to generate a signal indicative of the level so determined, and to employ at least one alphanumeric key to generate a specific, algorithmically-generated response to a challenge issued by a Web page instance to the user of the Web page instance, and a display component, operatively connected to the processing component, for displaying indicia of the determined level of Web page instance authenticity and displaying one or more of the following: the Web page instance, the challenge, and an input field for receiving the response.

29. Apparatus according to claim 28, further comprising a storage component for storing one or more alphanumeric keys associated with the user by a respective host.

30. A computer-readable medium encoded with a computer-executable software program for carrying out a process in accordance any of claims 20-27.

31. A set of application program interfaces embodied on a computer-readable medium for execution on a computer in conjunction with an application program, comprising:

a first interface that receives one or more domain names or one or more internet protocol addresses, or both, associated with a browser-accessed Web page instance;

a second interface that displays at least an approval result indicative of the outcome of a comparison routine performed between an approval database and the one or more domain names or one or more internet protocol addresses, or both, associated with the browser-accessed Web page instance;

a third interface that receives and displays a random challenge issued by a host server for the Web page instance; and

a fourth interface that employs a key to generate a specific, algorithmically- generated response to the challenge for transmission to the host server in order to authenticate the user.

32. A set of application program interfaces according to claim 31, further comprising

a fifth interface that receives a key from the host server and stores the key for use in generating the response to the challenge.