Abstract
A network authentication system and method is described for authenticating multiple profile accesses from a single remote device. A device remote from a web server, yet connected to the web server via, for example, the Internet, can allow multiple users to register their profiles within the device. The profiles are registered using a pre-existing user ID and password corresponding to, for example, the user's financial accounts. Multiple profiles and, specifically, the indicia of those profiles, can appear on the display of the remote device allowing each user the ability to select their own registered profile. Access to a profile is granted when the user enters their private PIN. Once the PIN is entered, the private information such as financial account information will be securely forwarded from the web server to the remote device.
Claims
1-14. (canceled)
15. A method for authenticating multiple accesses to user profiles stored on a web server from a single remote device communicatively coupled to the web server, said method comprising: (a) entering a user identifier and user password into the user interface of the remote device; (b) entering a personal identification number (PIN) into the user interface of the remote device and associating the PIN with a corresponding profile indicator displayed on the user interface to register the profile indicator and respective PIN; (c) repeating steps (a) and (b) to register at least two profile indicators and respective at least two PINs; (d) selecting from a list of the at least two profile indicators displayed on the user interface of the remote device; (e) entering the PIN corresponding with the selected profile indicator for receiving a profile from the web server; and (f) repeating steps (d) and (e) to receive at least two profiles from the web server.
16. The method according to claim 15, wherein the entering of the user identifier and user password further comprising combining the user identifier and the user password for authenticating the receipt of a software token sent from the web server to the remote device, and repeating said combining for authenticating the receipt of at least two software tokens sent from the web server to the single remote device.
17. The method according to claim 16, wherein the entering a personal identification number (PIN) further comprising combining the at least two software tokens with corresponding at least two PINs for encrypting the at least two software tokens and storing the at least two encrypted software tokens in the single remote device.
18. The method according to claim 17, further comprising: combining the at least two encrypted software tokens with corresponding at least two PINs for decrypting the at least two software tokens and generating corresponding at least two decrypted software tokens; and generating at least two one-time passwords using corresponding said at least two decrypted software tokens.
19. The method according to claim 18, further comprising sending the at least two one-time passwords from the remote device to the web server.
20. The method according to claim 19, further comprising receiving at least two profiles from the web server in response to the web server receiving the corresponding at least two one-time passwords from the remote device.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] Other objects and advantages of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings in which:
[0016] FIG. 1 is a block diagram of a remote device;
[0017] FIG. 2 is a block diagram of the remote device platform communicating over a public network or web with a web server;
[0018] FIG. 3 is a flow diagram of the process for registering one or more profiles of a user and associating a user PIN and software token with each registered profile;
[0019] FIG. 4 is a flow diagram of the process for obtaining one or more profiles from a single remote device by one or more users entering a PIN associated with each profile;
[0020] FIG. 5 is a diagram of the communication between the remote device and web server over the network, such as the web, and the various types of activities and signals sent between the remote device and web server; and
[0021] FIG. 6 is diagram of the various screen shots shown on a remote device illustrative of registering one or more profiles and thereafter gaining access to one or more profiles stored on a web server.
[0022] While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0023] Turning now to the drawings, FIG. 1 illustrates a device 10, such as a remote device, that is communicatively coupled to a public network, such as the Internet. Device 10, having an execution unit 12 and memory 14, is generally considered a computational device operating through instructions fetched from the Internet or from memory 14. The instructions can be launched by a user through, for example, user interface 16. The resulting executions arising from user interaction can be shown on display 18.
[0024] Device 10 operates as a client and, specifically, a client computing platform containing software. Because device 10 communicates with a web server or other devices via the Internet, device 10 includes an external communication unit 20. Unit 20 operates as a bridge and buffer between an external communication link 22 and bus 24. Like other internal system buses, bus 24 allow communication between execution unit 12 and external communication unit 20. One skilled in the art will appreciate upon reading this disclosure that the architecture of device 10 and the various hardware elements associated with a client device as being one that communicates to other clients or to a host via the Internet. In addition, a skilled artisan will understand the concept of user interface 16 that communicates with display 18 to allow input through, for example, a graphical portion of that user interface. As will be described in more below, one type of input would be the entry of a PIN onto a pop-up keyboard of the graphical user interface. The PIN can be used to encrypt a token sent from the external bus through communication unit 20 to bus 24, and then to encryption unit 28. The combination of the token and PIN allows for encryption of that token based on an instruction received from the read/write memory 14. The ensuing encrypted token 11 can then be stored in memory 14. In addition, decryption can occur by entry of the PIN into a decryption unit 26 within execution unit 12. When instructed, decryption unit 26 will decrypt the encrypted token 11 fetched from memory 14. The encrypted token is decrypted by combining it with the PIN used to encrypt the token, and thereafter the decrypted token can be sent as a one-time password.
[0025] As shown in FIG. 1, a PIN is used by encryption unit 28 to encrypt a token that is then stored in memory 14. The same PIN can be used to decrypt an encrypted token that is then sent as a one-time password to external communication unit 20. The PIN is not persistently maintained in memory of device 10, so it cannot be intentionally extracted by someone other than the intended user. Instead, the unique, private PIN must be entered each time by the intended user in order for access to be obtained. The cryptology of the private PIN can be one of a symmetric key algorithm that does not require a secure initial exchange of a token. Moreover, the token described herein is preferably a software token. A software token is one that is stored in the memory of the web server connected to device 10 via external link 22. Contrary to hardware tokens where the credentials are stored on a dedicated hardware device, a software token is not in any one person's physical possession; however, software tokens are vulnerable to man-in-the-middle or phishing attacks. Due to the preferred embodiments herein, the software token is stored in the remote device 10 only as an encrypted token. Thus, a malicious intruder is unable to access the software token from memory of device 10 or from a web server. Using symmetric or asymmetric cryptology, a private PIN in combination with an encrypted public PIN or software token ensures an additional layer of authentication similar to that of a two-factor authentication security mechanism.
[0026] FIG. 2 illustrates the computing platform of remote device 10 coupled through an external communication link, network, or Internet 30 to a web server 32. Device 10 operates as a client computing platform containing software, including a native application or web browser and proxy server 34. Communications between device 10 and web server 32 takes place using an appropriate communication protocol, such as the Internet Protocol (IP). The computing platform of device 10 may be run on one or more of a plurality of different operating systems, such as Windows, Mac OS, iOS, Linux, Android, Web OS, etc. A representative platform for a native application could include applications on mobile platforms for accessing messages in multiple formats, such as JSON, XML, and other formats and types of files. A representative platform for a browser and proxy server 34 can include Internet Explorer, Firefox, Safari, Opera, or Chrome, as well as known software applications for accessing hypertext documents in a variety of formats including text files, graphics files, word processing files, Extensible Markup Language (XML), Hypertext Markup Language (HTML), Handheld Device Markup Language (HDML), and other formats and types of files. The proxy server within the browser acts an intermediary for requests from device 10 seeking resources from other servers, such as web server 32. The proxy server services requests, such as file, connection, webpage, or other resources available from web server 32. Proxy server 34 evaluates the request as a way to simplify and control its complexity.
[0027] Shown in FIG. 2 is the capability of device 10 storing in its memory multiple encrypted tokens 11a, 11b, etc., through 11n. Each token is drawn from a memory 38 within web server 32. Each token stored in memory 38 is assigned to and corresponds with a respective profile. Multiple tokens can then be drawn from memory 38 and stored as encrypted tokens in the memory of device 10. Encryption is carried out through use of an encryption algorithm, all of which are fairly well known to those skilled in the art. Encryption occurs by using a PIN entered by a user. That PIN is used to uniquely encrypt a token where, as shown, a PIN is assigned to and encrypts respective tokens.
[0028] When a user enters a PIN for the first time, that PIN is assigned in association with a user-specific identifier which allows the token to be stored in its encrypted form within device 10. That process is known as the registration process. However, before the PIN is entered, the user ID and password is used to authenticate the device to the web server and, specifically, to authenticate the device to separate profiles stored in the web server. After the registration process (i.e., after the device is authenticated and the PIN is entered and assigned to a unique profile), that PIN can be entered when the profile is to be fetched from memory 38 of web server 32. The process of accessing a profile requires decrypting of the token using the PIN specified during the registration process. The PINs decrypt respective tokens that are stored in their encrypted form, and the decrypted tokens are sent through the proxy server 34 as passwords. Specifically, the passwords are one-time passwords in that they have a time limit as to their validity. As shown in FIG. 1, a timer 40 can be used to effectuate the one-time password feature. An execution unit 42 within web server 32 can parse or decode the various one-time passwords received from device 10 into the corresponding sections of memory 38 to extract and have access to the corresponding profiles. For example, PIN 1 can be used to decrypt only encrypted token 1 within device 10. A one-time password 1 is generated using the decrypted token 1, whereupon the one-time password 1 is sent to retrieve only profile 1 within memory 38. This process can be repeated to access the other profiles, using other encrypted tokens and PINs, as shown in FIG. 2.
[0029] FIG. 3 illustrates the process of registering profiles and, more specifically, illustrates corresponding profile indicators on the display of device 10. The registration process 50 can begin at step 52 by downloading an application to the client device. For example, the user might download application code from an application store, and an icon for that application would appear on the display of device 10 indicating completion of the download process. Once downloaded, the user can enter their ID and password previously associated with that user's profile. The profile is stored in a web server and maintained by an online service institution. However, the web server requires secure, authenticated, and trusted communication between that institution and its users. Examples of institutions having profiles include banks, healthcare providers, or other institutional sites with sensitive or personal information of its customers. A popular type of profile maintained by a bank or financial institution includes checking accounts, money market accounts, savings accounts, etc. of that user, herein referred to as “financial accounts.” Of course, for other types of institutions, there are other types of profiles that are not financial in nature, yet specific to the service provided by that institution to the user. All such accounts have one thing in common in that they are meant to be confidential and private to that user. In the example of a bank, a user can have one or more financial accounts; therefore, the user may setup those accounts with a different profile. On the other hand, there may be different users, where each user has previous established a separate profile since they all have different financial accounts that must be kept confidential from one another.
[0030] The profile could include certain confidential information besides simply the account balance of a financial account, and could include other personal information, such as a social security number, driver's license number, etc. Nonetheless, according to the embodiments described herein, each profile is unique and has its own user ID and password associated with that specific profile. When the user launches the downloaded application 52, the user will enter the unique ID and password at step 54. In one embodiment, the user is then asked a challenge question and must enter the correct answer at step 56. For example, an institution may have previously established challenge questions and maintains answers provided by the user, e.g., mother's maiden name, favorite pet's name, etc. The user will then enter their PIN at step 58. The same PIN is entered each time for gaining access to the specific profile. The PIN serves to authenticate future accesses and also encrypts tokens stored in the device, as described in more detail below.
[0031] Importantly, in addition to registering a single user profile, the present registration process allows for registering multiple profiles. Accordingly, at step 60, a decision block asks if all profiles are added. If all profiles have not been added, the registration process begins again at step 54. Once all profiles are added, the registration process ends at step 62. For example, a user Bob has a checking account and money market account, both of which he registers under his unique profile indicator, named “Bob's Accounts.” However, Bob's wife Barbara may want to register her financial accounts on the same device under her unique profile indicator, named “Barbara's Accounts.” If desired, this process could continue for each member of the family. Alternatively, for example, Bob could create separate profiles for his personal accounts and business accounts, given the profile indicators “Bob's Personal Accounts” and “Bob's Business Accounts.” After performing the registration process steps illustrated in FIG. 3, a profile indicator for each unique profile would be displayed on device 10, giving access to the unique profile only to the specified user.
[0032] Turning now to FIG. 4, after the profiles are registered (FIG. 3), flow diagram 66 illustrates the process steps for obtaining access to the registered profile. At step 68, the application program residing on device 10 is launched, e.g., clicking on the application icon displayed on device 10. Once launched, a list of registered profile indicators is displayed. Using the example above, profile indicators could be listed as “Bob's Accounts” and “Barbara's Accounts.” At step 70, one profile is selected by the user, e.g., clicking on the profile indicator displayed on device 10. Once the profile is selected, the user's unique PIN is entered by that user at step 72. The profile is then received at step 74. If there are multiple profile indicators, a decision block 76 asks if all desired profiles are obtained. Using the above example, if Barbara wants to access her profile from the Bob's device, the access steps for Barbara begin again at step 70. This process can be repeated for however many profile indicators are registered. For example, if Bob had created separate profiles for personal and business accounts, a unique profile indicator would be listed for “Bob's Personal Accounts” and “Bob's Business Accounts.” When using a mobile device, it proves advantageous and efficient to be granted access by simply entering a PIN that Bob has memorized corresponding to his personal account and his business account, rather than an ID and password each time access is desired. If there are no more registered profiles to be accessed, the application program is closed at step 78.
[0033] Turning now to FIG. 5, a time diagram is shown along with the various signals sent between remote device 10 and web server 32. The timing of signals begins with registering the profiles 80 (FIG. 3). Thereafter, the profiles are obtained 82 (FIG. 4). In timed sequence, with ascending time 84, the registering profiles 82 begins with downloading the application from web server 32, and storing the application in device 10. For example, a bank web server may have available an application that a user can download to their device which, according to a preferred embodiment is a mobile device. Once downloaded, the user authenticates the device with their unique ID, password, and PIN created with the particular institution. Once the user device is authenticated, token1 is requested from web server 32, and token1 is then forwarded to device 10. Token1 is obtained using an encryption such as SSL/TLS on the network communication between web server 32 and device 10. However, token1 can be encrypted while resident on device 10 when the user enters their unique PIN. PIN1 can be associated with token1, while PIN2 can be associated with token2, etc., such that the registration can be repeated for additional profiles.
[0034] After one or more tokens and associated PINs are registered, only the encrypted token is maintained and stored in device 10. The PIN is not stored within device 10 and is a secret key known only to the user. Obtaining the profile 82 begins by decrypting each token with its corresponding PIN. For example, token1 is decrypted with PIN1. A one-time password, e.g., password1, is generated using the decrypted token1. In this example, password1 is then sent from device 10 to web server 32 to authenticate device 10, at which time the profile, e.g., profile1, is forwarded to device 10. This process can be repeated for up to however many profiles are registered on device 10.
[0035] FIG. 6 illustrates examples of various screen shots of the embodiments described herein after the subject application program has been downloaded to a remote device. Screen 90 might prompt a user to add a profile. After clicking “add profile,” screen 92 might prompt a user to verify they wish to “continue.” If so, screen 94 requests entry of the user ID and password, as previously setup with the particular institution. Once the user ID and password are entered, screen 96 then requests the user to name their profile (i.e., given their profile a profile indicator name that would thereafter appear in screen shot 100). The user is also prompted to enter a PIN to be associated with that given profile indicator name. If there are additional profiles to be entered 98, the process begins again at screen 90. Once all the profiles are registered, each profile indicator can be listed as shown in screen 100. Using the examples herein, there may be a profile indicator for Bob's Personal, Bob's Business, and Barbara's Accounts. There is no limit to the number of profiles that can be created. If “profile 2” is selected, screen 102 prompts the user to enter the PIN previously registered for that unique profile. Once the PIN is correctly entered by the user, screen 104 reflects the accounts associated with that unique profile. An account can be selected by clicking on icon 106, which shows that account's activity, such as withdrawals, deposits, etc. There can be other transactions implemented by clicking icon 106, such as bill pay, for example. Thus, “access” includes not only being able to see the account information stored on a web server, but also perform transactions within that account, all from a remote device. Most importantly, the preferred embodiments herein allow access to multiple profiles from a single device—whether a single user has multiple accounts or a family wishes to have multiple persons using one device. Once the profiles and associated accounts are registered, each individual need only remember their specific PIN in order to gain access to their profile.
[0036] Further modifications and alternative embodiments of various aspects of the invention will be apparent to those skilled in the art in view of this description. It is intended that the following claims be interpreted to embrace all such modifications and changes and, accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
