Patent Application
20050172229
This invention relates generally to the field of network security. More specifically, the invention relates to methods and systems for preventing users from mistakenly providing sensitive information to untrusted entities.
Fraudulent activities on the Internet have increased drastically. Examples include password spoofing, password phishing, and man-in-the-middle attacks. “Spoofing” and “phishing” generally refer to the practice by nefarious parties of fooling a web user into providing sensitive information, such as passwords, personal information, financial information, and the like, by imitating a web site the user trusts. “Man-in-the-middle attack” (MITM) generally refers to the practice of sniffing packets from a network, possibly modifying them, then returning them to the network. MITM typically requires comprising a sender's and/or a receiver's public key. In part, these fraudulent activities are successful because users are trained to enter sensitive information directly into web forms and popup windows. The content and appearance of these windows are easy to spoof since they are based on ordinary HTML. Any content delivered over the web, however, is easy to duplicate for the purposes of setting up a fake web site. In general there is risk whenever one wants to share sensitive information via a network. Thus, systems and methods are needed that assist users to not provide sensitive information to untrusted entities.
Embodiments of the invention thus provide a user interface through which a user at a client device interacts, via a network, with one or more resource sources. The user interface includes a display window that displays resources sent to the client device from the one or more resource sources and a control area having one or more applications that allow the user to manipulate interaction with the one or more resource sources. The one or more applications include a security application that includes at least one data field for receiving input from the user to be sent to a specific resource source and an icon that provides a visual indication of whether the specific source is a trusted resource source.
In some embodiments, the user interface may include means for interacting with a source of information relating to whether resource sources are trusted resource sources. The user interface may be a web browser. The security application may include a plug-in to the web browser. The client device may be a personal computer, personal digital assistant, laptop computer, workstation, cell phone, and/or the like. The one or more resource sources may be web sites. The at least one data field may have at least two states, a first state that accepts input if the specific resource source is a trusted resource source, and a second state that does not accept input if the specific resource source is not a trusted resource source. The security application may be a tool bar, a dialog box, a popup window, a standalone application, and/or the like. The security application may include an options menu for configuring the security application. The security application may include a selection that allows the user to declare a specific resource source to be a trusted resource source. The selection that allows the user to declare a specific resource source to be a trusted resource source may require user authentication. The security application may include a visual indication of a level of trust of a specific resource source. The visual indication may include a number from a scale, a color from a spectrum, and/or the like. The data field may includes a predetermined, user-defined personal assurance message that signals the user that the security application generated the data field. The security application may include a randomly-generated visual background.
Other embodiments provide a method of facilitating interaction between a user at a client device and a resource source. The client device includes a user interface through which the user interacts, via a network, with one or more resource sources. The method includes evaluating whether a resource directed to the client device is from a trusted resource source, displaying an icon on the client device that provides a visual indication of whether the resource is from a trusted resource source, and providing, in a control area of the client device, a data field for receiving input from the user to be sent to the resource source. The icon and data field together are a security application.
In some embodiments, the method includes receiving from a source of information an indication of whether one or more resource sources are trusted resource sources. Providing a data field may include providing the data field in a first state that accepts input if the resource source is a trusted resource source and providing the data field in a second state that does not accept input if the resource source is not a trusted resource source. The method may include providing an options menu for configuring the security application. The method may include receiving a selection from the user declaring a specific resource source to be a trusted resource source. The method also may include receiving user authentication prior to receiving the selection. The method may include providing a visual indication of a level of trust of the resource source. The visual indication may include a number from a scale, a color from a spectrum, and/or the like. The method may include providing in the data field a predetermined, user-defined personal assurance message that signals the user that the security application generated the data field. The method may include providing a randomly-generated visual background to the security application.
A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings wherein like reference numerals are used throughout the several drawings to refer to similar components. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
Embodiments of the invention provide network security applications. Such security applications assist network users not to provide sensitive information to untrusted entities. The security application, in some embodiments, is a consistent interface, in most cases appearing in a control region of a familiar application such as a web browser (i.e., a browser toolbar), which a user comes to trust for receiving sensitive information. In some embodiments the security application is a web browser tool bar, although in other embodiment, it may be an applet embedded in a web browser, a standalone application, or the like. The appearance of the application and whether it will accept the input depends on the trustworthiness of the network entity with which the user is communicating. Thus, although the appearance of a resource within the user's browser application may appear trustworthy, the appearance of the security application, and not the resource, provide the true indication of the source's trustworthiness to the user.
Sensitive information may include authentication data, digital identity data, personal data, and the like. For example, a user could enter a static or dynamic password to access a local credential (e.g. cryptographic key store, biometric), remote credential (e.g. cryptographic key roaming server) or even a handwritten biometric electronic signature system. In the case of biometrics, the security application, in some embodiments, provides confirmation that the user is not authenticating to a false site and thus perhaps signing data he did not intend to.
Embodiment of the invention may apply to any scenario wherein sensitive information is shared. As an example, in the context of authentication data, in addition to providing access to numerous authentication methods, embodiments of the invention may be used in a variety of systems including login at an eCommerce or home banking website, digital or electronic signature of a financial transaction, logging into a SSL VPN, etc. Other systems that utilize a browser and require authentication such as FTP server access and file access through Microsoft Explorer functionality may also apply.
Attention is directed to
The resource sources 106, 108 may be any computing device capable of network communication, although the resource sources 106,108 typically are web servers. Examples of resource sources include servers, workstations, personal computers, and the like. Thus, resources sources 106, 108 typically “host” web sites and send and receive resources (e.g., web pages) to users. Herein the term “resource” is to be construed broadly so as to refer to any network transmission. It is also to be understood that a particular resource source may host numerous web sites (i.e., resources), some of which may be trusted and some not, as will be explained. For ease of discussion, however, the following description will refer to resource source as if it hosts only a single resource, which may be trusted or not.
Resource sources may be “trusted” such as resource sources 106, or “untrusted” such as resource source 108. A trusted source is one that has been deemed so by any of a number of processes. A source may be trusted because a particular authority has deemed the source to be trusted. A source may be trusted because a user or the user's organization has configured its systems to trust the source. Other possibilities exist and will be described in greater detail hereinafter. An untrusted resource is one that has not been deemed “trusted.”
The network system also includes a trust authority 110, or “trust information source” as it is sometimes referred to herein. The trust authority 110 collects information about resource sources and distributes the information to users. Users may send alerts to the trust authority, after which the trust authority evaluates the information that was provided and distributes relevant information as necessary. This process will be explained in more detail hereinafter.
In one example of an embodiment of the present invention in operation, a user operates web browser software on his user device 104(1) to request a resource from a source 106(1). The source 106(1) is, in this specific example, the user's bank, and the resource is the login screen that allows the user to access his online bank statement and transactions menu. The untrusted source 108 recognizes the request and, having programmed a duplicate of the source's login page, attempts to satisfy the resource request by sending this “spoof” page to the user device 104(1). If the untrusted source is successful getting his spoof page to the user device before the trusted source 106(1) gets the legitimate page to the user device, the user's display may nevertheless appear as expected, having data fields for entering the user's account number and password. This user, however, has installed the security application according to an embodiment of the invention.
As will be explained further below, the user receives a visual indication that the untrusted source, whose display screen is rendered on the user's device, does not appear on a list of trusted sources. Thus, the security application displays an icon that so alerts the user. Further, the security application includes a data field that receives the user's password and/or account number. In this instance, however, the data field(s) are “grayed out,” so that the user cannot enter the sensitive information. Thus, through a combination of operations, the security application attempts to prevent the user from divulging sensitive information to an untrusted source. Of course, the user could still enter information directly into a data field in the web page. As will be described, however, embodiments of the invention include additional features that attempt to prevent this.
Attention is directed to
At operation 200, a trust information source (such as trust authority 110) collects trust information from users, other trust authorities, independent monitoring, and the like. In some cases the information is evaluated, and false reports and the like are disregarded. Periodically, however, the information is distributed to users. The information may include known trusted sources, and known untrusted sources. In ways known to those skilled in the art, the transmission may be cryptographically signed with a public key that chains up to an embedded trusted CA in the security application so that the user has confidence that the information may be relied upon. The trusted list may include domain names, fully qualified domain names, Uniform Resource Identifiers (“URIs,” such as URLs), and the like.
The information, or trusted site list, may be sent periodically from the trust information source 110 to user devices on a predetermined schedule. Alternatively, or additionally, the trust information source may be polled by users. The trust source may have an address, such as a URL, embedded in a digitally signed certificate that chains up to a trusted Root CA certificate in the security application.
Thus, a user may, at block 202, configure his trust options. The user may chose to include all or only certain parts of the information provided by the trust information source. Additionally, the user may include or exclude specific sites known to the user to be trusted or untrusted. The user also may chose to include information from an organization within which the user operates. Many other examples are possible and apparent to those skilled in the art. Modification may require user authentication, which may be once per session, once per application instance, and the like.
At block 204, the user sends a request for a resource. As those skilled in the art appreciate, this may involve typing a URL into an address window of a browser, selecting a stored “favorites” link, selecting a hyperlink in a web page, and the like. In some such examples, the link is to an untrusted source. In others, the link is to a trusted source, but the request is “sensed” by an untrusted source. Thus, a blocks 206 and 208 both a trusted source and an untrusted source, respectively, recognize the resource request and both attempt to respond to it a blocks 210 and 212. The untrusted source's response, however, is an attempt to imitate the trusted sources response so as to fool the user into providing sensitive information to the untrusted source.
At block 214, the user device receives either or both of the resources from the trusted and untrusted sources. If only one resource is received, the remaining decisioning may be made based only on the single resource. If more than one is received, however, the decisioning may be made on the current “focused” resource. Those skilled in the art understand how the control regions of browsers or other applications may change appearance depending upon which of several windows within the environment has the current “focus.” This applies here. Thus, the resource of the untrusted site may overlay the trusted site so that the user has difficulty identifying its presence. In order for the user to enter data into the resource, however, the focus would have to be on that resource, and the security application described herein can apply the teachings herein to appropriately alert the user.
At block 216, the security application decides whether the resource is from a trusted source. In some embodiments, the application consults a trusted sites list, an untrusted sites list, a user-configured option, and/or the like to decide. If the source is trusted, the process continues at reference number 2 in
At block 218, the application displays an untrusted site icon. Thus, attention is briefly directed to
In some embodiments, a visual cue to the user includes a graphic or text representation of the level of trust of the resource. The trust level may be a number on a scale or a color from a spectrum. The trust level may be calculated based on any of a number of factors, some of which may be configured by the user. In some embodiments, the trust level might be specifically configured for known sites in advance. Or factors such as the domain of the site might be applied. For example, a specific known site in the domain (e.g. dev.arcot.com) might be given the highest trust level, while other sites in the domain (e.g. sales.arcot.com) might still be trusted, but not to the same level. Similarly, a well-known site where the user has an existing relationship might engender the highest trust; sites known to be reputable businesses might be trusted somewhat but not completely; completely unknown sites, not at all. Negative configurations are also possible, either set up by the user or the trust information source—that is, sites identified as specifically not trustworthy, e.g. known attacker sites. Many other examples are possible and apparent to those skilled in the art in light of this disclosure.
Returning to
In some embodiments, the data field 308 is available only if the resource has a certificate containing a public encryption key signed by a CA (either directly or through a chain) appearing on a Root Certificate in the security application. In some embodiments, this requirement is combined with a requirement that an identifier of the resource (domain name, URL, or the like) match some information in the certificate, such as the common name. Other checks may include SSL and certificate validation. In some embodiments, a bitmap of an authorized organization may be included in the certificate and presented as part of the interface.
The process continues at reference numeral 1 in
The process may continue at block 224. At block 224, the security application may assemble a warning to a trust authority regarding having encountered an untrusted site. The warning is transmitted then, at block 226, received by the trust authority. The trust authority may process the warning and/or distribute an alert associated with the warning as will be described further hereinafter. In other embodiments, the user may initiate a warning by, for example, selecting a button on the interface.
Returning to reference numeral 2 and block 228, the sequence of operations related to determining a source to be trusted will be described. At block 228, having determined a source to be trusted, the security application receives sensitive information. Thus, in a specific example, the data field 308 of
In some embodiments, the security application uses an organization's public key that must be signed and chained to a trusted CA to encrypt the user's sensitive information. This provides even greater protection for the user's sensitive information.
At block 230, the trusted source receives the transmission from the user. If necessary, the source uses its private key to decrypt the transmission.
Block 232 begins another process wherein the security application continues to monitor activities on the user's device for suspicious activity. Examples include too many browsers and children, creation or destruction happening too rapidly, focus changing too rapidly, on-topness changing too rapidly, and the like. The types of suspicious activity may be user configured. If suspicious activity is detected, the user may be alerted via the icons and other visual warnings, depending upon the type of activity detected and the user's pre-selected response to such activity.
Additionally, the security application may assemble a warning to be sent to a trust authority. The warning may include information that identifies a source that caused or was “present” during the suspicious activity. Upon receipt at block 236, the trust authority may process the warning to verify the information and determine whether the warning is false. If the warning is legitimate, the trust authority may distribute an alert to other users at block 238. Thus, through a central authority, threats may be quickly evaluated and information concerning threats may be rapidly broadcast to other users.
Attention is redirected to
Having described several embodiments, it will be recognized by those of skill in the art that various modifications, alternative constructions, and equivalents may be used without departing from the spirit and scope of the invention. Additionally, a number of well known processes and elements have not been described in order to avoid unnecessarily obscuring the present invention. For example, those skilled in the art know how to arrange computers into a network and enable communication among the computers. Additionally, those skilled in the art will realize that the present invention is not limited to tool bars, plug ins, or applications embedded within browser applications. For example, embodiments of the invention may be standalone applications. Accordingly, the above description should not be taken as limiting the scope of the invention, which is defined in the following claims.
This application is a non-provisional of and claims the benefit of U.S. Provisional Patent Application No. 60/540,714, entitled “BROWSER USER-INTERFACE INTEGRATED SENSITIVE DATA ACCESS” filed on Jan. 29, 2004, the entire disclosure of which is herein incorporated by reference for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 60540714 | Jan 2004 | US |
