HK1164580A - Transforming static password systems to become 2-factor authentication - Google Patents

Abstract

The present invention provides systems and processes for transforming any system that implements a static password authentication or 1st-factor authentication so as to enforce strong 2-factor authentication, requiring the user to present both a static password and a dynamic password, without having to modify the existing system.

Description

Transforming static cryptosystems to become two-factor authentication

Technical Field

The present invention relates to two-factor authentication, and in particular to a system and method for implementing two-factor authentication on a static cryptographic system.

Background

In the modern electronics field, the approach taken to implement identification is mainly based on predefined factors such as "something you know" (such as a password, PIN number, etc.), "something you have" (such as a token, access card, etc.), or "something you are" (such as a fingerprint, iris scan, etc.). The verification process of the verification factor is generally regarded as authentication. For example, if Alice and Bob are going to make an appointment, they can identify each other by: i) knowing meeting time and place (first factor authentication); ii) identifying the license plate of the vehicle they are driving (second factor authentication); and iii) recognize each other's face and sound when meeting (third factor authentication). Naturally this authentication process will not be performed carefully and rigorously, but rather subconsciously each time they meet. However, if Bob forgets the time but still drives the same vehicle, Alice does not create suspicion as when Bob drives a different vehicle or even when Bob appears different.

The combination of different authentication factors makes it highly likely that the identified person is accurately authenticated. For example, if a system requires only a user to provide a secret password (one factor authentication) to be identified, while another system requires the user to provide a password and a dynamic password generated from a unique token (two factor authentication or 2FA), the latter system will be considered a more secure system in authenticating the user. Many successful attacks have existed, such as phishing and grafting (pharming) on systems that employ only one-factor authentication to determine user identity, and such attacks are increasing.

Even so, systems operating with a single authentication far exceed those using 2 FA. The 2FA is generally adopted by financial institutions and the like. There are many reasons why one-factor authentication is more popular than 2 FA. These reasons include cost feasibility, system feasibility, protocol compatibility, and user controllability.

Many 2FA solutions, such as RSA, VASCO, DS3, etc., already exist in commercial use. Which can be integrated at their backend systems to enable two-factor authentication of their users. The integrated 2FA solution requires significant upgrades to existing systems. Thus, the cost of deploying and maintaining 2 FAs on an existing system may outweigh the benefits gained. This becomes a major factor for organizations to abandon such practices.

Despite organizations 'efforts to make their application systems open and up-to-date, there are inevitably some legacy applications or proprietary systems, beyond the organization's control to modify or reconfigure. Even if an organization already has a 2FA solution on a business scale, these systems will not be able to take advantage of the added security.

There are a number of cryptographic protocols that are incompatible with the use of 2FA, for example, Kerberos incompatible 2FA is widely used by many systems including microsoft windows Active Directory, the enterprise backbone of most systems in the world. During the user login phase, the Kerberos network authentication protocol requires the manipulation of a static password as part of the key exchange with the Kerberos server. The protocol does not work well with the 2FA scheme when the user has to provide a static password as well as a dynamic password in order to send to the backend authentication server.

There are multiple coping schemes available that involve modifying the Windows GINA login process to solely account for dynamic passwords, but these coping schemes are difficult to deploy and even more difficult to maintain.

So far, the 2FA enforcement is left as the authority of the system owner. If the system owner chooses not to implement 2FA to protect the user account, the user has no other choice than to choose a more complex password and to log in using only a trusted machine.

It is clear that most internet and Web 2.0 services such as GMail, MSN, Yahoo, Facebook, MapleStory, etc. do not provide 2FA over the internet, despite much demand from the user. The user who wishes the 2FA to protect his account is only at the disposal of the system owner.

Disclosure of Invention

The present invention provides a system and method for converting any system that employs static password authentication or one-factor authentication into a system and method that employs robust two-factor authentication that requires a user to present both a static password and a dynamic password without modifying the existing system.

In one aspect of the invention, the invention provides a system for implementing two-factor authentication or multi-factor authentication on an existing system that employs static password authentication or one-factor authentication. The system comprises: a token manager operable to track a token of a user and generate a second authentication factor; a password manager having access to the existing system, the password manager operable to form a new authentication code based on a first authentication factor and a second authentication factor, wherein the first authentication factor is an authentication code registered on the existing system for access, the password manager replacing the first authentication factor with the new authentication code currently registered on the existing system.

In one embodiment, generating the second authentication factor and replacing the first authentication factor with the new authentication code are performed recursively at predetermined intervals.

In another embodiment, the token manager generates a second authentication factor based on the first authentication factor. In yet another embodiment, the first authentication factor comprises a static password and the second authentication factor comprises a dynamic password.

In another embodiment, the password manager replaces the first authentication factor with a new authentication code by changing the password operation. It is also possible that the password manager replaces the first authentication factor with a new authentication code by setting/resetting the password operation.

In another embodiment, the system exists remotely from an existing system. It is also possible that the system resides on an existing system. However, when the password manager is present on an existing system, the token manager may be present remotely from the existing system.

In another embodiment, the system may be a software module or a hardware module, or a combination of both.

According to another aspect of the present invention, there is provided a method for implementing two-factor authentication or multi-factor authentication on an existing system employing static password authentication or one-factor authentication, the method comprising: a deployment module; tracking, by an existing system, a token of a user; generating a second authentication factor; forming a new authentication code based on a first authentication factor and a second authentication factor, wherein the first authentication factor is an authentication code for access registered on an existing system; the first authentication factor is replaced with a new authentication code on the existing system, whereby authentication to access the existing system will be based on the new authentication password.

In one embodiment, generating the second authentication factor and replacing the first authentication factor with the new authentication code are performed recursively at predetermined intervals.

In one embodiment, the first authentication factor comprises a static password and the second authentication factor comprises a dynamic password. It is also possible that the second authentication factor is generated based on the first authentication factor.

In another embodiment, replacing the first authentication factor with a new authentication code includes changing a password registered on an existing system. It is also possible that replacing the first authentication factor with a new authentication code comprises setting/resetting a password registered on an existing system.

In yet another embodiment, the module is deployed to exist remotely from an existing system. It is also possible that the modules are deployed to exist on existing systems.

Additionally, the modules may be software modules or hardware modules, or a combination of both.

Drawings

Preferred embodiments of the present invention will hereinafter be described in conjunction with the appended drawings, wherein like designations denote like elements.

FIG. 1 is a functional block diagram of a two-factor authentication system according to one embodiment of the present invention.

Fig. 2 is a functional block diagram of a two-factor authentication system according to another embodiment of the present invention.

Fig. 3 is a functional block diagram of a two-factor authentication system according to another embodiment of the present invention.

Fig. 4 is a functional block diagram of a two-factor authentication system according to another embodiment of the present invention.

Fig. 5 is a functional block diagram of a two-factor authentication system according to another embodiment of the present invention.

FIG. 6 is a functional block diagram of a two-factor authentication system according to another embodiment of the present invention.

Fig. 7 is a functional block diagram of a two-factor authentication system according to another embodiment of the present invention.

Detailed Description

Consistent with the above summary, a number of specific and alternative embodiments are provided below to understand the inventive features of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. Some of the details may not be described in detail so as not to obscure the invention. For ease of reference, the same reference numerals are used throughout the specification when referring to the same or similar features common to the figures.

It is an object of the present invention to provide a scheme that can be implemented on an established system, typically a one-factor authentication system, to support two-factor authentication (2 FA). It is desirable to implement 2FA over an established one-factor authentication system without requiring any modifications to the existing system. The present invention provides a system and method for converting an existing system employing static password authentication or one-factor authentication into a 2FA system. In one embodiment, the converted system will require the user to present a static password and a dynamic password for authentication without requiring modification to the existing system.

For purposes of this description, a static password refers to a predetermined code or string of characters used for authentication. The static password is the first authentication factor that is typically stored in the existing system to be accessed. Static passwords are typically fixed at all times until changed by a user's request. In another aspect, the dynamic password refers to a second authentication factor generated based on a preset algorithm.

Fig. 1 is a functional diagram of a 2FA system 100 according to an embodiment of the present invention. The 2FA system 100 generally includes two parts: a front-end user 110 and a back-end system 120. For simplicity, the front-end user 110 will also refer to the user 110, and the back-end system 120 will also refer to the back-end system 120. The user or front end user 110 is hereinafter referred to as anyone with legitimate rights to access restricted resources with an identification code. The backend system 120 includes a backend module 121 and an existing system 125. The back end module 121 has access to the existing system 125 and can be provided with access and funding to the existing system 125. The existing system 125 is a factor or static password authentication system. Prior to the login process, the user 110 is given a token for obtaining a user dynamic password.

The token may be in the form of a hardware device, a software module running on the device, a message sent over any available route such as SMS, email, etc., or even a scratch card or any physical medium containing a cryptographic sequence. Typically, the dynamic password provided by the token is a one-time password (OTP), which is a pseudo-random code that varies at predetermined intervals or any predetermined condition. These conditions may be specific to the user at specific times or intervals. Those skilled in the art will appreciate that tokens are widely used for 2FA or multi-factor authentication, and thus details are not provided herein for brevity.

Operatively, on the backend system 120 side, at regular preset intervals, the backend module 121 calculates 122 the dynamic password. When a dynamic password is generated, the back-end module performs a "change password" operation at step 124 to change the current registered password registered on the existing system 125 to a new password in a predefined format, including static passwords and modular dynamic passwords. The change password operation is a common feature that allows a user to actively change the login password on any one factor authentication system. The new password is further recorded in the back-end module at step 126, enabling a subsequent new password to be obtained based on the previously obtained new password. By regularly changing and updating new passwords, including static passwords and dynamic passwords, on the existing system 125, the existing system 125 can be better protected because the password registered on the existing system 125 includes two or more authentication factors.

The static password for the user 110 is a password for a record registered on the existing system 125. The user 110 assumes that a static password is used to access the existing system 125 that is authenticated based on one factor. The static password should also be pre-recorded with the back-end module 121 in order to generate a new password. In case the user 110 actively changes the static password, the back-end module 121 needs to be updated with the new static password.

The predefined form of the new password may be a combination of both static and dynamic passwords, e.g. in a chain form. To improve security, the new password may also be encoded.

On the user 110 side, the user 110 requests to log on to an existing system 125 at step 112. The user 110 then calls 114 a static password for the user 110 to access the existing system 125 and obtains 116 a dynamic password via the token. When the static password and the dynamic password are available to the user 110 at step 118, the two passwords are combined in a predetermined manner and provided to the existing system 125, e.g., in a chain, to verify the new password recorded on the existing system 125.

The dynamic password obtained by the token should be the same as or correspond to the dynamic password generated by the back-end module 121. Similarly, the predetermined manner of combining the passwords from the user 110 will be the same as or correspond to the new password registered on the existing system 125. Thus, the combined password transmitted from the user 110 side is verified against the new password registered in the existing system 125 for authentication. It should be noted that the verification and authentication of the password is performed over existing systems 125 through a factor or static password authentication. Thus, the 2FA is implemented on the existing system 125 by the back-end module 121 and thus significantly improves the security of the existing system 125.

The back end module 121 is an add-on application or system that operates independently of an existing system 125 that employs a one-factor authentication system. Which automatically includes the second factor or more to a factor authentication system without requiring modification of the existing system 125. There have been no changes or modifications to the protocols employed by the existing system 125.

In one embodiment, the static password is stored on the back-end module 121 such that the static password is retrievable to interlock with the second (or more) factor for authentication.

Those skilled in the art will appreciate that the present invention may be applied to most, if not all, existing systems that employ one-factor authentication. A module is provided that can be deployed on existing systems to extend authentication to two or more factor authentication, thereby increasing security of access. Typically, users access the system via electronic devices such as personal computers, mobile phones, etc. via communication networks such as the internet.

Fig. 2 is a functional diagram of a 2FA system 200 according to another embodiment of the present invention. The 2FA system 200 includes a subscriber 210 and a backend system 220. The backend system 220 includes a backend module 221 and an existing system 225. Operationally, at step 222, the back-end module 221 calculates the dynamic password at regular preset intervals. The dynamic password is then concatenated with the registered static password to form a new password. At step 224, the new password is set/reset as an authorized password for accessing the existing system 225. Typically, such an operation (i.e., setting/resetting the password) requires administrator authority to set the new password, which is different from the "change password" operation illustrated in FIG. 1. Thus, at step 226, the chain password sent from the user 210 verifies the new password set by the back-end module 221 for authentication.

On the user 210 side, the user 210 is given a token. At step 212, the user 210 requests to log on to the existing system 225. At step 214, the user 210 invokes a static password, and at step 216, the user activates the token to generate a dynamic password. At step 218, a new password comprising a static password and a dynamic password can be formed and provided to the existing system 225. Thus, the existing system 225 may verify the password from the user 210 against the chained password currently registered on the existing system 225.

It will be appreciated by those skilled in the art that the back end module 221 is provided to change and update the recorded password registered on the existing system 225 to a new password comprising the original static password and the generated password. The above-described embodiments implement 2FA over an existing one-factor authentication system by changing the password registered on the existing system 225 to include a second factor (i.e., dynamic password) for authentication, thereby emulating 2FA over the one-factor authentication system.

For purposes of illustration, the operations "change password" and "set/reset password" differ primarily in the right to access the existing system 225. As mentioned above, in most systems, it is common for users to be given user privileges to actively change their passwords. To perform a change password operation, the user will be required to enter the password currently registered on the existing system 225. On the other hand, set/reset password operations may typically be operated by an administrator of existing system 225, thereby requiring administrator privileges to do so. The password registered on the existing system 225 can be changed without knowing the password, typically under administrator privileges. Therefore, it is important to recognize that implementing 2FA on a one-factor authentication system will require replacing the registration password with a rule that includes a second authentication factor. Thus, 2FA or multi-factor authentication can enable any significant upgrade or modification on any existing system and/or protocol that need not be employed.

Fig. 3 is a functional diagram of a 2FA system 300 according to another embodiment of the present invention. 2FA system 300 includes a user 310 and a backend system 320. Backend system 320 includes a backend module 321 and an existing system 325. Operatively, at step 322, a back-end module 321 residing on the back-end system 320 calculates dynamic passwords at regular preset intervals. At step 324, the back-end module 321 performs a "change password" operation to change the recorded current password for the dynamic password generated by the back-end module 321 by providing the recorded current password. Thus, the existing system 325 waits for the user 310 to log in with a dynamic password. Similarly, the operations of generating the dynamic password and changing the recorded password are performed recursively at predetermined cycles/intervals.

On the user 310 side, the user 310 is given a token. At step 312, the user 310 requests to log onto the existing system 325. At step 314, the user enters a static password into the token. At step 316, the token provides a dynamic password. The dynamic password is then provided to backend system 320 for authentication at step 318. The user providing the matching dynamic password is allowed access to the existing system 325.

Returning to step 322, the back-end module may calculate a dynamic password based on the static password registered on back-end system 320. It is also possible that once the user ID is authenticated, the back-end module calculates a dynamic password without the need for a static password. In this case, entering a static password into the token may be considered a first authentication factor, while a dynamic password is considered a second authentication factor.

In the present embodiment, although only the dynamic password is used for verification in the existing system 325, another authentication factor is required to generate the dynamic password, and thus 2FA is also implemented.

Fig. 4 is a functional diagram of a 2FA system 400 according to another embodiment of the present invention. The 2FA system 400 includes a subscriber 410 and a backend system 420. The backend system 420 also includes a backend module 421 and an existing system 425. Operatively, at step 422, the back-end module 421 calculates the dynamic password at regular preset intervals. At step 424, a "change password" operation is performed by the back end module 421 to change the existing password to the chain password. In step 426, after the dynamic password is generated (step 422), the dynamic password is remotely communicated to the user 410 as required. Thus, the existing system 425 waits for the user 410 to log in.

On the user 410 side, the user is provided with a pre-specified means, such as a mobile phone number or email address or any message ID, to receive the dynamic password. The dynamic password is remotely provided to the user 410 in a pre-specified manner as it is delivered at step 426. The user 410 can obtain the dynamic password via any available service, for example, the generated dynamic password may be delivered to the user 410 from the backend module 421 via SMS or email or online message. At the point in time when the password on the existing system 425 is changed, the user 410 receives the dynamic password from the back end module 421 at step 416. To log in, user 410 invokes a static password that was previously registered with existing system 425 at step 414 and interlocks with a dynamic password at step 418. The concatenated password is then provided to the existing system 421 for authentication at step 428.

As shown in the above embodiments, 2FA or multi-factor authentication enables the deployed module to be implemented on a one-factor authentication or static password authentication system without modifying or changing the existing architecture and protocols of the existing system. The modules include a token manager and a password manager. A token manager is provided for tracking a user's token and generating a corresponding dynamic password. The token manager is adapted to ensure that the generated dynamic password is new and synchronized. The password manager is adapted to retrieve and replace an existing password as a new password when authentication is required. Password replacement can be performed through a change password operation or a set/reset password operation. Depending on the type of deployment, the password manager may require the original password to be stored/recovered. The type of deployment may be a local deployment or a remote deployment.

FIG. 5 illustrates a block diagram of a 2FA deployment 500 according to an embodiment of the invention. The 2FA deployment 500 is implemented on a target system 510 that allows access by a user 520. Target system 510 is a system that employs a static password or one-factor authentication. The back-end module 530 is deployed on a remote system accessible to the target system 510 to implement and simulate a 2 FA. The remote system can be an external device provider for implementing the 2FA system. The back-end module 530 is adapted to implement the 2FA via a "change cipher" operation. In this case, the user can access the remote system to manage their own dynamic token through the token management service provided thereon. This embodiment is desirable for systems on the internet and Web 2.0 such as Gmail.

FIG. 6 illustrates a block diagram of a 2FA deployment 600 according to an alternative embodiment of the invention. The 2FA deployment 600 is implemented on a target system 610 that allows user access in a manner similar to the 2FA deployment of fig. 5, except that the backend module 630 of the 2FA deployment 600 is integrated outside of the target system 610. The integrated 2FA deployment 600 performs better and has lower processing overhead. Although not limited to, the 2FA deployment 600 is applicable to enterprises having full control over the target system 610 itself, such as microsoft windows Active Directory. Token management for the user, etc., will likely depend on the administrator.

In yet another embodiment of the present invention, a 2FA deployment 700 is provided as shown in fig. 7. The 2FA deployment 700 is implemented on the target system 710 by locally integrating the back-end module's password manager 740, but remotely setting the back-end module's token manager 730. When user 720 requests to log in, password manager 740 is operable to connect to the token manager to obtain an updated password for password 720. A new password will be generated to authenticate user 720. Similarly, password manager 740 may make a "change password" to replace the currently registered password with the new password for authentication. The deployment 700 is applicable to an enterprise having multiple target systems above which two-factor authentication is required.

A change to add a module may be to place the token management outside of the target system and keep the changing password component within the target system. At regular intervals, the change password component will connect to the token management service to obtain an updated password for the user and set the password for the user. This arrangement is suitable for an enterprise where there are multiple target systems.

The invention is suitable for converting a single authentication system into a 2FA system. However, those skilled in the art will appreciate that the present invention is capable of converting any existing system (including 2FA systems as established) into a multi-factor authentication system without modification to any of the above embodiments.

While the invention has been described and illustrated, it should be understood that many variations, modifications, changes, and combinations thereof may be made to the invention without departing from the invention.

Claims (20)

1. A system for implementing two-factor or multi-factor authentication on an existing system that employs static password authentication or one-factor authentication, the system comprising:

a token manager operable to track a token of a user and generate a second authentication factor;

a password manager accessible to the existing system, the password manager operable to form a new authentication code based on a first authentication factor and the second authentication factor, wherein the first authentication factor is an authentication code registered for access on an existing system, the password manager replacing the first authentication factor with the new authentication code currently registered on the existing system.

2. The system of claim 1, wherein generating the second authentication factor and replacing the first authentication factor with the new authentication code are performed recursively at predetermined intervals.

3. The system of claim 1, wherein the new authentication code comprises the first authentication factor and the second authentication factor.

4. The system of claim 1, wherein the token manager generates the second authentication factor based on a first authentication factor.

5. The system of claim 1, wherein the first authentication factor comprises a static password and the second authentication factor comprises a dynamic password.

6. The system of claim 1, wherein the password manager replaces the first authentication factor with the new authentication code by changing a password operation.

7. The system of claim 1, wherein the password manager replaces the first authentication factor with the new authentication code through a set/reset password operation.

8. The system of claim 1, wherein the system exists remotely from the existing system.

9. The system of claim 1, wherein the system resides on the existing system.

10. The system of claim 1, wherein the token manager exists remotely from the existing system and the password manager exists on the existing system.

11. The system of claim 1, wherein the system is a software module.

12. The system of claim 1, wherein the system is a hardware module.

13. A method for implementing two-factor or multi-factor authentication on an existing system employing static password authentication or one-factor authentication, the method comprising:

a deployment module;

tracking, by the existing system, a token of a user;

generating a second authentication factor;

forming a new authentication code based on a first authentication factor and the second authentication factor, wherein the first authentication factor is an authentication code for access registered on the existing system;

replacing the first authentication factor with a new authentication code on the existing system, whereby authentication to access the existing system will be based on the new authentication password.

14. The method of claim 13, wherein generating the second authentication factor and replacing the first authentication factor with the new authentication code are performed recursively at predetermined intervals.

15. The method of claim 13, wherein the first authentication factor comprises a static password and the second authentication factor comprises a dynamic password.

16. The method of claim 13, wherein the second authentication factor is generated based on the first authentication factor.

17. The method of claim 13, wherein replacing the first authentication factor with the new authentication code comprises changing a password registered on the existing system.

18. The method of claim 13, wherein replacing the first authentication factor with the new authentication code comprises setting/resetting a password registered on the existing system.

19. The method of claim 13, wherein the module is deployed to exist remotely from the existing system.

20. The method of claim 13, wherein the module is deployed to reside on the existing system.