Patent Application
20060282678
The present invention relates generally to ensuring secure access to a remote server and more particularly to a system and method for secure authentication of a user by passing login credentials for a user from a secure storage device.
User authentication is one of the most vexing problems in the use of computerized devices. While computers have automated or even enabled many tasks, the use of computers and in particular the access of computerized services over networks has significantly increased risks. While security of personal and corporate data have been secured by the adoption of many security protocols and devices, e.g., encryption, secure protocols, and use of smart cards, these security mechanisms have seen attack in many different forms.
The use of user identification in conjunction with passwords or personal identification numbers (PIN) is one mechanism for protecting access to personal or private corporate data or services that require some form of authentication. Traditionally, the PIN is entered by a user in some type of text box and the PIN is transmitted to an authentication server.
However, passwords and PINs can be attacked and compromised even if these are transmitted over a secure channel in an encrypted form. For example, if an untrusted computer is used to enter an authorization phrase, software executing on that computer may be used to capture that PIN before the PIN has been passed to the encryption layer. Such software can be in the form of software that impersonates the service to which a user may seek access or in the form of keyboard loggers that capture keystrokes entered by users.
PINs and passwords can also be obtained by persons who simply look over the shoulder of a user entering such authorization phrases.
The Internet has become a very popular vehicle for carrying out many transactions that require user authentication. At the same time, the Internet has also made it possible to access private and sensitive information from many different locations. For example, with online banking it is possible for a banking customer to login to his bank account to view balances and make certain transactions from his home or office. However, while that is a relatively secure physical location on relatively trusted computers, other transactions may not be as safe. For example, online stockbrokerages make buying and selling securities possible while being logged in on a wireless network while having a latte in a café, and online auction services enable the sale and purchase of goods from public computers at a university. These are only examples; there is really no limit on the many different scenarios coupling online services where user authentication is extremely important with the use of computers that cannot be fully trusted either because of ownership, location, or by being exposed to malicious software that may have been deployed to illicitly obtain passwords.
The majority of servers that permit remote user logins employ some form of username/password to authenticate users before granting access. This is particularly true when logging into a remote web server via a web browser. Since good passwords are not easy to remember, there has always been a need to devise methods of storing and automatically “entering” the user's password without requiring the user to manually type it. To address this need there are numerous commercial software packages that allow a user to send login credentials to a remote web server without having to type the username and password in a web form. However, all these existing solutions suffer from one or more of the following drawbacks:
There are two broad categories of current solutions. The first category consists of data-on-host solutions. In these solutions there is no external token. The user data is stored in the host application. Examples of this are RoboForm, from Siber Systems, Inc., and Ghostsurf, from Tenebril, Inc.
The second category consists of data-on-external-token solutions that store data on a conventional smart card, but still require a host application to transfer this data to the remote server. An example is the Otanium Suite available with some laptops sold by Dell Computer Corporation.
A specialized application program A1107 monitors the communication data flowing between the browser B1103 and the remote server 105. The application program A1107 automatically fills in the username and password data in the login HTML form by reading this data from a data repository D1109 on the host computer 101. The repository D1109 can either be a file on the host computer 101 or can be kept inside the system Registry database of the host computer 101.
As before, the web browser B1103 is a standard web browser through which a user connects to the login page of a remote server serverABC 105. An application A1213 monitors the communication data between the browser B1103 and the serverABC 105 and inserts the username and password into login HTML form. The application A1213 reads the login data D1209 from the smart card 207. Because mainstream PC applications cannot communicate with conventional ISO 7816 based smart cards, a smart card specific middleware application M1211 is required to read data from the smart card 207.
Recent advances in smart card research have made it possible to treat the smart card as a network peer. As a network peer, the smart card (a network smart card) can communicate securely with other computers on the network using standard mainstream network communication protocols like TCP/IP and SSL/TLS. Network smart cards and their use are described in greater detail in co-pending and co-assigned U.S. patent application Ser. No. 10/848,738, entitled, “SECURE NETWORKING USING A RESOURCE-CONSTRAINED DEVICE” of Hongqian Karen Lu, Michael Andrew Montgomery, Asad Mahboob Ali, the entire disclosure of which is incorporated herein by reference.
Network smart cards can be used to send a user's login credentials to remote servers. However, this approach, though extremely secure, requires the remote server to be modified so that it can accept login credentials from a smart card. Modifications to large established computerized services can be very costly and time consuming. Furthermore, if a user would prefer to have his passwords stored on a storage device to alleviate the need for remembering the passwords but the online service does not wish to make the required modification, the user would still be precluded from that option.
As discussed above, an alternative approach is to automatically fill form data in browsers from a smart card. However, that solution requires the installation of a host application and possibly some middleware.
From the foregoing it will be apparent that there is still a need for a way to provide login credentials from a trusted and secure storage device, e.g., a smart card, to a remote server in a manner that does not require modification of the software or hardware used by either the host computer or the remote server.
In a preferred embodiment the invention provides a system and method for automatically providing login credentials to a remote server using a secure storage device without requiring any modifications to the remote server or requiring any special software on the host computer from which a user is attempting to connect to the remote server.
An embodiment for secure authentication to a remote server includes transmitting from the secure storage device to the host computer a server list containing a list of servers available for secure authentication using the secure storage device. The list is then used to establish a connection from the host to the remote server and to request the secure storage device to present the login credentials to the remote server.
In response to receiving the login request, the secure storage device transmits the login credentials and a login software module to the host computer. The login software module is automatically executed on the host computer to fill in the login page and to cause the transmission of the filled-in login page from the host computer to the remote server.
Other aspects and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.
In the following detailed description, reference is made to the accompanying drawings that show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.
Introduction
As shown in the drawings for purposes of illustration, the invention is embodied in a novel system and method for providing user login credentials to a remote server using a secure storage device, e.g., a smart card, to store the login credentials and to provide the login credentials to the remote server without requiring modifications to the host system used by the user or to the remote server the user is seeking to access.
In one embodiment of the invention, a software module, e.g., a JavaScript, for providing login credentials and a standard web browser on the host computer are used to transfer login information from a network smart card (e.g., a network smart card as described in co-pending patent application Ser. No. 10/848,738) to a remote server wherein the remote server does not require any modification to accommodate the solution provided by the invention. Furthermore, no additional application software is required on the host. Furthermore, since the network smart card does not require any smart card specific middleware or reader drivers this approach provides an extremely portable way of carrying the login credentials of multiple existing commercial servers on the smart card and then logging into these servers. The servers do not have to be modified to allow this login.
The smart card 307 is a network smart card (NSC) having thereon a network smart card web server 309 and a store D1311 for holding login credentials.
The user login credentials are passed from the smart card 307 to the remote server 305 using a second web browser B2313. In alternative embodiments, web browsers B1303 and B2313 are different windows within the same web browser, are different flames within the same web browser window, two different web browser tabs (e.g., as provided in Mozilla Firefox), or even combined into the same web browser window and operating within the same frame.
In a preferred embodiment, the web browsers B1303 and B2313 are two distinct web browser windows. Accordingly, the examples that follow are described in the context of two web browser windows. However, that implementation must only be considered as an example and not as a restriction on the claims.
With the above-described message flow, a network smart card (NSC) 307 may be used to connect seamlessly to an unmodified remote server 305 and to provide the login credentials of a user to the remote server 305.
As described herein-above a preferred embodiment of the invention relies on a combination of an HTML form and JavaScript code to transfer user login credentials from a network smart card (NSC) to a remote server.
In a simple ideal case the user login credentials, e.g., user login name and password, may be sent to a remote web server using a simple HTML form template using a single web browser instance B1301. The form template consists of three principal elements:
Once these three elements are known, a form can be constructed as illustrated in Table 1:
The actual values for the userID and userPassword fields can be stored on a secure hardware token 307, e.g., a Network Smart Card. These values are then read from the secure hardware token 307 and placed in the form template. The filled-in form is then submitted to the URL indicated in the action element. In theory these steps are all that is needed to login to the remote server 305 using a secure hardware token 307. However, in practice this approach seldom works.
The reason the simple ideal case described above does not work is the use of session cookies by many remote servers. A cookie is a packet of information sent by a server to a browser and then sent back by the browser each time the browser accesses that server. Servers store cookies on the local client machines for two reasons. The first is to identify users and keep track of their browser session at the server. The second reason is to prevent repeated automated login requests. Servers regard such requests as attempts by a potentially malicious user to break into existing accounts on the server. Therefore, servers reject login requests from browsers that fail to present adequate set of cookies.
The cookies are placed in the user's machine when the user connects to the login page of the server. The server can choose to put one or more cookies for each login session. The cookies can also be time stamped so they cannot be used after their time has expired. All this is done to make sure that it is an actual user who is trying to login, and not an automated script with malicious intentions.
A system and method according to the invention extends the simple ideal case scenario to make it possible to transfer login credentials from a secure storage token, e.g., a smart card, to remote servers when taking into account the constraints imposed by most online servers.
In one embodiment of the invention, a secure storage token interacts with a web browser to perform the login operation to a remote server as a process having two logical steps: 1. connect to a login page of the remote server and allow the remote server to write cookie data, 2. send user login credentials to the remote server from the same browser instance used in step 1. The two-step login process solves the disparity between the simple form submission scenario and the real world authentication environment wherein commercial web servers use an extensive set of session cookie logic. In the first step, in response to a user's request to connect to a remote server, the login page from the remote server is downloaded into a second web browser instance. The remote server is thus given the opportunity to write all authentication related cookies to the local host machine into that second web browser instance. After the cookies have been written, the second web browser instance can be used to load and send the completed HTML form template of Table 1 to the remote server. Because the second web browser instance is used, the remote server accepts the login credentials passed by the form and the user is granted access.
Returning now to
The link “https://www.serverABC.com” connects to the login page of the remote server serverABC 305. The link https://myNetworkSmartCard/serverABC.html connects to the corresponding page on the network smart card 307. Both links have browser B2313 as their respective targets.
Next the user clicks on one such server link, e.g., the link 505 to login to serverABC 305, step 405. A connection is made to the login URL of the server, https://www.serverABC.com/login, step 407.
The login page is downloaded from serverABC, 305, into a new browser window B2, message 409. This allows the server to write any cookies that are necessary during the login process. The cookies are written to the host PC 301, step 410. In case these cookies are session specific cookies they are associated with the stance B2313.
Instead of filling the login information in web browser B2313, the user clicks on the login link (line 4, Table 2) in web browser instance B1303, i.e., the login link 507. This is the link corresponding to the server link picked in step 405. This click sends a request (https://myNetworkSmartCard/serverAbc.html) back to the NSC web server, 309.
The response from the NSC web server 309 is displayed in the web browser B2313, over-writing the login page 601 from the remote server serverABC 305. This response data, message 414, consists of an HTML form template that matches the form used for login at serverABC. An example of the HTML code is shown in Table 3.
The key aspects of code in Table 3 are:
Line 8 creates an inline flame on the same page. The source of this page is another HTML file, serverAbcLogin.html on the smart card. The code for this file is shown in Table 4. The code of Table 4 contains the JavaScript code to fill the username and password data and to automatically submit the form to serverABC.
The key aspects of code in Listing 3 are:
The JavaScript code from serverAbcLogin.html is automatically launched, step 415 by the execution of line 8 Table 4. The confidential user login credential data is kept on the smart card 307 and placed in serverAbcLogin.html file before being sent to the browser B2313.
The second web browser B2313 sends the form data containing user login information to the URL at the remote server (serverABC) 305 that processes login requests. This URL is specified in line 4 of the code of Table 3.
When the remote server (serverABC) 305 authenticates the user, the user is granted access to the remote server 305.
This example described herein above describes the use of HTML and JavaScript code to pass user login data to a merchant server. The embodiment illustrated by the example reuses the same browser instance B2313 through which session cookies have been stored. This browser reuse is possible through the TARGET element of HREF tag. In an alternative embodiment, browser window handles are used. The connection link 505 that goes to the login page of serverABC 305 creates a new web browser window B2313. The handle of this window is saved inside the JavaScript code. The link that goes to serverAbc.html on smart card web server 309 reuses this window handle.
In an alternative embodiment, the user would only be required to click on one link to cause the execution of the two logical process steps: connecting to a login page on remote server 305; and having the login credentials transmitted from the smart card 307 to the remote server 305. In such an embodiment, the services page transmitted from the NSC web server 309 contains a link to “connect and login to” for each remote server supported by the NSC 307. Clicking on one such link first triggers the connection to the corresponding remote server 305 and then a subsequent login request message is automatically sent to the smart card web server 309, without any additional action from the user. Sending of the second message—the login request to smart card web server 309—is delayed until the login page from remote server 305 is loaded and all cookies have been written to the local host computer 301.
The network smart card 307 further includes a processor 703 connected to the communications means and to a memory 705. For illustrative purposes, the memory 705 is illustrated as one unit. In practice, the memory 705 would usually be divided into several distinct memory areas, e.g., a read-only memory, a random access memory, a programmable read-only memory.
The memory 705 contains one or more application programs 707 having instructions to direct the processor 703 to receive and send data to other computers, e.g., the host computer 301 or the remote server 306.
The memory 705 further contains one or more data stores 709 for storing data, e.g., login credentials for a user.
The receive connection request module 803 contains software logic to direct the communications module in establishing a communications channel between the smart card 307 and the local host computer 301. Thus, the connection request module 803 contains smart card side logic to implement the step to establish a connection, message traffic 402 of
The web server 309 further contains a software module 805 to receive a login request message 412. The login request message 412 contains an indication of which server to which the user wishes to connect. The receive login request module 805 would then call on the retrieve login credentials module 807 to retrieve the login credentials for the server from the login credentials database 311 and any other information necessary to produce a login form, e.g., the form illustrated in Table 3. This additional information includes the tags used by the particular remote server for username and password. These tags are inserted by the build login form and script module 809 into a template for the login form together with the user's username and password.
The build login form and script module 809 further contains logic to build the login script, e.g., as shown in Table 4.
The receive login request module 805 further contains logic to call upon the communications module 801 to transmit the login form and login script to the indicated browser instance on the local host computer 301.
From the foregoing it will be appreciated that method and system for secure login of the present invention provides an efficient and secure method of having login credentials stored and supplied by a secure network storage device, e.g., a network smart card, without requiring any modifications to either the local host computer being used by a user trying to log in to a remote server or that remote server. Furthermore, the actual values of the login credentials are never exposed. This technique addresses an existing need that is not served by prior art form-fill software approaches because this new technique provides a more portable way of passing login data from any machine. The user is not restricted to the machine on which form-fill software is installed. In addition the user is protected from potential phishing attacks.
This use of the network smart card allows secure logins without any changes to the existing merchant servers.
While the present invention has been described hereinabove in the context of automatic provision of login credentials from a network smart card to a remote server, the invention may also be used to provide other information that may be required by a remote server. Examples of such information include, but are not limited to account numbers, addresses, social security numbers, telephone numbers, identification numbers, biographical information (e.g., height, weight, race, blood type, known allergies). The modifications needed to the above described techniques include providing in the smart card the tags used by the remote server for such information and the corresponding user data.
To provide for such use of the above-described technique, the services page 501 may include an additional link to provide user data. The network smart card webserver would then also contain code to provide such data in a form For example, if the remote server is used for online shopping, the server may request a shipping address having the tags “Street Address”, “City”, “State”, “ZIPCODE”.
Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The invention is limited only by the claims.
