Field

The present invention relates to a method performed by at least one server configured to authenticate a user for a web service login, and a related server device.

Background

Conventionally, most online services require users to only provide a static user- specified password that is transmitted to a server (hosting the services) for verification to authenticate the users. Once authenticated, the users are considered authorised to start accessing those online services.

There are however disadvantages with such a method of authentication in those systems, where the passwords are usually user-specified. Empirical analysis of real-world password databases revealed that users typically tend to select weak and easy-to-guess passwords for sake of convenience in remembering them afterwards. As a result, an attacker/hacker may easily guess such user passwords. Moreover, systems that allow users to specify their passwords are susceptible to brute-force password guessing attacks. In addition, even when a user specifies a strong password, the user will more often than not, for convenience, records down the password, thus rendering the password non- secret and again negates the advantage of having a strong secret password. Even if the user does not record down the password, a strong password is still also susceptible to phishing attacks. The static nature of passwords in such systems also means that if a password is compromised on a system, the compromised password may be re-used by the hacker to continue gaining access to that system until the compromised password is changed to a new one. Moreover, again for convenience, users tend to re-use a same password for multiple different websites that require some form of login access. Therefore, a compromised static, user-specified password may be used by a hacker on multiple websites for an indefinite amount of time, until the compromised password has been changed. Certificate-based authentication addresses the weak security aspects of password-based authentication, wherein mechanisms using certificate-based authentication are not susceptible to phishing attacks. And together with password protection of a certificate, two-factor authentication may be achieved by requiring a user to prove that he knows the password to the certificate, and he also is in (digital) possession of the certificate.

That said, certificate-based authentication is fairly inconvenient for online services that are accessed through web-browsers because the certificates are not easily portable digitally, and also browser support for external certificates is non-standardised and not guaranteed. For example, if a certificate is stored in a software file, the user needs to first make the file accessible to a web-based client application (arranged to access associated online services) via a browser (used to access the application itself), specify the local directory path to the file within the client application in the browser, and finally provide his password to the certificate.

One-time passwords (OTPs) address the security issue associated with static and weak passwords, because OTPs are system-generated, and so password strength can be easily enforced. Furthermore, since OTPs can only be used once (within a stipulated timeframe), systems that use OTPs for authentication are not susceptible to replay attacks, whereby the hacker illegitimately obtains passwords and re-uses those passwords for future authentication attempts.

An issue with OTPs is that since they are system-generated, the OTPs have to be (somehow) digitally distributed to users. And because OTPs can only be used once, a new OTP has to be distributed for each new login attempt. Presently, OTPs are commonly distributed using text messages, OTP generation software, or hardware tokens. However, all of the above distribution methods are not securely protected, and not to mention that some methods for distribution such as using text messages or the hardware tokens are also costly.

One object of the present invention is therefore to address at least one of the problems of the prior art and/or to provide a choice that is useful in the art. Summary

According to a 1 ^st aspect, there is provided a method performed by at least one server configured to authenticate a user for a web service login, comprising: (i) generating a first one-time password (OTP) and a first identification number associated with the first OTP, based on a first request received from a first computing device, the first request related to the login and includes a user identification of the user; (ii) transmitting a notification to a second computing device, the notification includes the user identification, the first identification number, and a second identification number associated with the first request, the second computing device configured to establish a trust relationship with the server by authenticating digital credentials of the user which are associated with the user identification; (iii) transmitting the first OTP to the second computing device in response to receiving a second request from the second computing device, the second request based on the notification to enable the server to authenticate the second request; and (iv) authenticating the first request based on a second OTP transmitted from the first computing device, the second OTP corresponding to the first OTP received by the second computing device.

Advantageously, the disclosed method combines both OTP-based authentication and a suitable separate authentication (e.g. certificate-based authentication) to provide secure two factor authentication to web services.

Preferably, user identification may be provided by the user via the first computing device, and the user identification may include a string of alphanumeric text and/or special characters.

Preferably, transmitting the notification to the second computing device may include, but is not limited to, using Apple Push Notification Service (APNS) or Google Cloud Messaging Service (GCMS) or Short Message Service (SMS) to perform the transmission.

Preferably, the method may further comprise transmitting the first identification number to the first computing device, in response to receiving the first request. Preferably, step (iii) may further include transmitting a configured expiry date of the first OTP to the second computing device.

Preferably, the method may further comprise establishing a secure digital communication channel with the first computing device, prior to step (i).

Preferably, the method may also further comprise transmitting a response to the first computing device, subsequent to step (iv), wherein the response includes a session identification number if the authentication at step (iv) is successful, or an error identification number if the authentication at step (iv) is unsuccessful.

More preferably, transmitting the first OTP to the second computing device may include, but is not limited to using Apple Push Notification Service (APNS) or Google Cloud Messaging Service (GCMS) or Short Message Service (SMS) to perform the transmission.

Also, authenticating the digital credentials of the user may preferably include using certificate-based authentication, multi-factor authentication, or private PKI infrastructure.

Particularly, the multi-factor authentication may include using smart cards for authentication.

According to a 2 ^nd aspect, there is provided a server device configured to authenticate a user for a web service login, comprising: a generation module for generating a first one-time password (OTP) and a first identification number associated with the first OTP, based on a first request received from a first computing device, the first request related to the login and includes a user identification of the user; a notification module for transmitting a notification to a second computing device, the notification includes the user identification, the first identification number, and a second identification number associated with the first request, the second computing device configured to establish a trust relationship with the server by authenticating digital credentials of the user which are associated with the user identification; a response module for transmitting the first OTP to the second computing device in response to receiving a second request from the second computing device, the second request based on the notification to enable the server to authenticate the second request; and an authentication module for authenticating the first request based on a second OTP transmitted from the first computing device, the second OTP corresponding to the first OTP received by the second computing device.

According to a 3 ^rd aspect, there is provided a method performed by a system configured to authenticate a user for a web service login, the system comprising at least one server, and first and second computing devices. The method comprises: (i) transmitting a first request by the first computing device to the server, the first request related to the login and includes a user identification of the user; (ii) generating a first one-time password (OTP) and a first identification number associated with the first OTP by the server, based on the first request received from the first computing device; (iii) transmitting a notification by the server to the second computing device, the notification includes the user identification, the first identification number, and a second identification number associated with the first request, the second computing device configured to establish a trust relationship with the server by authenticating digital credentials of the user which are associated with the user identification; (iv) transmitting a second request by the second computing device to the server, the second request based on the notification to enable the server to authenticate the second request; (v) transmitting the first OTP by the server to the second computing device in response to receiving the second request, and if the second request is successfully authenticated; (vi) transmitting a second OTP by the first computing device to the server, the second OTP corresponding to the first OTP received by the second computing device; and (vii) authenticating the first request by the server based on the second OTP received from the first computing device.

It should be apparent that features relating to one aspect of the invention may also be applicable to the other aspects of the invention.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. Brief Description of the Drawings

Embodiments of the invention are disclosed hereinafter with reference to the accompanying drawings, in which:

FIG. 1 is a system diagram of a server device, configured to authenticate a user for a web service login, in communication with first and second computing devices, according to an embodiment;

FIG. 2 is a schematic diagram of a configuration of the server device of FIG. 1 ; FIG. 3 is a schematic diagram of a configuration of the second computing device of FIG. 1 ;

FIG. 4 is a flow diagram of a method performed by the server device of FIG. 1 configured to authenticate the user for the web service login;

FIG. 5 is a flow diagram of a method overview relating to interactions between the server device, and the first and second computing devices of FIG. 1 to authenticate the user; and

FIG. 6 shows an authentication sequence diagram for the server device, and the first and second computing devices of FIG. 1 , with reference to FIG. 5.

Detailed Description of Preferred Embodiments

A server device 100 (hereafter "server"), configured to authenticate a user (not shown) for a web service login, in communication with first and second computing devices 102, 104, according to an embodiment disclosed in FIG. 1. It should be appreciated that the disclosed server 100 is adapted for use in the field of internet and mobile technologies. The server 100 and the first and second computing devices 102, 104 collectively form a secure one-time password (OTP) distribution and authentication system 106. The server 100 is also configured to provide related web services for the user based on successful web service login. The first and second computing devices 102, 104 are used by the user to communicate with the server 100, and may be any suitable computing devices, e.g. a smartphone, a laptop, a desktop computer, a tablet or the like. But in this embodiment, the second computing device 104 is preferably a mobile smart device. Further, it is to be appreciated that the first computing device 102 may be termed as a secondary device (hereafter), whereas the second computing device 104 may be termed as a trusted primary device (hereafter), for reasons to be elaborated below. Referring to FIG. 2, a schematic diagram 200 of a configuration of the server 100 is depicted. Specifically, the server 100 is implemented with the following software modules: an OTP identification (ID) request module 202, an OTP generation module 204, an OTP storage module 206, an OTP ID response module 208, an OTP notification module 210, an OTP request module 212, an OTP response module 214, an OTP authentication module 216, an OTP verification module 218, and an OTP verification response module 220. The interactions between the modules 202-220 will be described later below with reference to FIG. 6.

Then, as shown in FIG. 3, the trusted primary device 104 is configured with an application module 300 and an OTP notification module 302. The application module 300 is internally arranged with an authentication module 304 and an OTP module 306. It is to be appreciated that the authentication module 304 provides an authentication mechanism to digitally authenticate the user with the server 100 in order to establish a security trust relationship for the primary device 104 with the server 100, and hence usage of the term "trusted" in the trusted primary device 104. In particular, the authentication is performed by authenticating digital credentials of the user which are associated with his user identification. For this embodiment, the digital credentials are obtained from an accredited digital certificate associated with the user, and the said digital certificate is used in a certificate-based authentication for establishing the trust relationship, but is not to be construed as limiting since other suitable methods are possible too, such as using multi-factor authentication (e.g. using removable smart cards), or private PKI infrastructure. Indeed, the primary device 104 is arranged to use any suitable internal or external trust store to enable establishment of the trust relationship with the server 100.

For certificate-based authentication, the user inputs an account and password into the trusted primary device 104 to digitally unlock his digital certificate (which has been pre-stored on the trusted primary device 104) to gain access to his digital credentials, and the trusted primary device 104 is then configured to use the unlocked digital certificate to execute a certificate-based authentication protocol with the server 102. If the server 102 successfully verifies and authenticates the user (and the primary device 104 consequently becomes "trusted" by the server 102), the application module 300 then grants access to various application functions in the trusted primary device 104, including the OTP request function. It is noteworthy to highlight that the trusted primary device 104 is specifically associated to the user, and not to any other users. Particularly, the trusted primary device 104 is in physical possession by the user (who is the owner), but if the trusted primary device 104 maliciously falls into possession by other users, it may mean a serious security breach of the trust relationship, since those users may use the trusted primary device 104 to masquerade the owner of the trusted primary device 104 for unauthorised web logins to the server 100. However this can be mitigated by automatically logging out the user after a fixed period of time to limit the window where the application considers the user to be authenticated and trusted. After the automatic log out, the malicious thief will need to provide the password again to unlock the digital certificate and re-authenticate himself/herself to the server 100.

FIG. 4 depicts a method 400 performed by the server 100 configured to authenticate the user for a web service login, which broadly comprises: (i) generating a first one-time password (OTP) and a first identification number associated with the first OTP at step 402, based on a first request received from the secondary device 102, the first request related to the login and includes a user identification of the user; (ii) transmitting a notification to the trusted primary device 104 at step 404, the notification includes the user identification, the first identification number, and a second identification number associated with the first request; (iii) transmitting the first OTP to the trusted primary device 104 at step 406, in response to receiving a second request from the trusted primary device 104, the second request based on the notification to enable the server 100 to authenticate the second request; and (iv) authenticating the first request (at step 408) based on a second OTP transmitted from the secondary device 102, the second OTP corresponding to the first OTP received by the trusted primary device 104.

It is to be appreciated that at steps 404 and/or 406, transmitting the notification and/or the first OTP to the trusted primary device 104 may be accomplished using Apple Push Notification Service (APNS) for iOS™-based devices, or Google Cloud Messaging Service (GCMS) for Android™ devices, but is not to be construed as limiting. For example, Short Message Service (SMS) or other suitable notification services may also be adopted. Using APNS or GCMS allows the server 100 to initiate a request to the trusted primary device 104, without requiring additional user actions to manually input parameters of the second request and initiate the second request from the trusted primary device 104.

FIG. 5 shows an overview of a method 500 relating to sequential interactions between the server 100, the secondary device 102 and the trusted primary device 104 to accordingly authenticate the user for the web service login. The method 500 begins at step 502. At step 504, the trusted primary device 104 is digitally registered with the server 100 to form the trust relationship (as afore explained). Next, at step 506, the user sends an OTP ID request (i.e. the first request) from the secondary device 102 to the server 100 to start an authentication session for the web service login in order to access the related web services. It is to be appreciated that the first request is uniquely identified by an associated ID, i.e. an OTP request ID. Particularly, the user opens a login page on the secondary device 102 to input his user identification (ID), and thereafter, operates the secondary device 102 to send the first request (which includes the user ID) to the server 100. The user ID may be in the form of a string of alphanumeric text, and/or may also include special characters, such as underscore(s), dot(s), dash(es) and etc. On receipt of the first request, the server 100 is configured to generate an OTP and an associated ID of the generated OTP (i.e. OTP ID) - this corresponds to step 402 of FIG. 4. The server 100 also transmits the OTP ID back to the secondary device 102. The secondary device 102, upon receiving the OTP ID, displays the following information to the user: the user ID, the OTP ID, and a blank input text box for entering the OTP. It is to be appreciated that at this point, the user still does not know what the OTP is, since the OTP has yet to be transmitted by the server 102.

The server 100 also sends an OTP notification to the trusted primary device 104 regarding receipt of the first request from the secondary device 102, at step 508. This corresponds to step 404 of FIG. 4. It is to be appreciated that the server 100 is able to send the OTP notification to the "correct" trusted primary device 104 (amongst the many different trusted devices registered with the server 100) based on this mechanism: the user registers an APNS or GCMS token/device ID with the server 100 upon authentication. So in effect, the server 100 (gradually) builds a knowledge map of user ID to APNS/GCMS tokens/device IDs over time. Hence, the OTP notification will be sent to the device associated with the device token/ID by Apple or Google. In the case of SMS notification, the server 100 builds a knowledge map of user ID to phone number, and sends the notification SMS to the phone number corresponding to the user ID. Subsequently, the trusted primary device 104 receives the OTP notification on the OTP notification module 302 (via APNS/GCMS/SMS and etc.) and presents an OTP notification alert to the user. Upon tapping the OTP notification alert on the screen of the trusted primary device 104 at step 510, the application module 300 is launched. If the user is not already authenticated on the trusted primary device 104, the application module 300 prompts the user to authenticate with the server 100 (i.e. to establish the trust relationship), before proceeding with next step. But if the user is already authenticated, the OTP module 306 (of the application module 300) then transmits an OTP request (i.e. the second request) along with the OTP request ID to the server 100 at step 512. On receipt of the second request, the server 100 verifies the second request and (if the second request is valid) retrieves the generated OTP and transmits the OTP to the trusted primary device 104. This corresponds to step 406 of FIG. 4. Upon receiving the OTP at step 514, the OTP notification module 302 of the trusted primary device 104 presents the OTP to the user.

Accordingly, the user inputs the OTP, referenced from the trusted primary device 104, into the blank input text box presented on the secondary device 102, and then operates the secondary device 102 to transmit the entered OTP to the server 100 (as an OTP authentication request) at step 516. Thereafter, the server 100 receives the OTP from the secondary device 102, verifies/authenticates the received OTP (i.e. this corresponds to step 408 of FIG. 4), and if the verification is successful, returns a unique web session ID to the secondary device 102. At this stage, the user is considered successfully authenticated, and so the server 100 grants the user access to other functionalities and resources on the server 100 via access from the secondary device 102. On the other hand, if the user is not successfully authenticated, then an error ID is transmitted to the secondary device 102 to notify the user, and access to the web services will be denied. The method 500 ends at step 518.

FIG. 6 shows a related authentication sequence diagram 600 for the server 100, the secondary device 102 and the trusted primary device 104, which is based on FIG. 5, and so reference will be made thereto wherever necessary. Initially, the user launches a web browser installed on the secondary device 102 to access web services hosted on the server 100, which requires a web service login for authentication purposes prior to granting access to the web services, and to do so, the secondary device 102 first establishes a secure digital communication tunnel with the server 100 (using a pre-agreed security protocol). It is assumed at this stage, the trusted primary device 104 has already been setup with the server 100 (i.e. as per step 504). Then, the user proceeds to provide his user ID on the secondary device 102 as part of the authentication procedure to request an OTP from the server 100. Subsequently, the secondary device 102 transmits the first request to the server 100 (i.e. as per step 506), which is technically in the form of a data packet that includes the user ID and the OTP request ID. The first request is received by the OTP ID request module 202 (of the secondary device 102), and then the OTP generation module 204 is configured to securely generate a random OTP ID of a configurable length and a random OTP of a configurable length. The OTP generation module 204 also computes an expiry date (and time) for the generated OTP based on a configurable expiry interval, and further associates the OTP ID, the generated OTP, and the expiry date with the OTP request ID, the user ID, and a configurable maximum number of attempts. The OTP storage module 206 then stores the user ID, OTP request ID, OTP ID, OTP, expiry date, and maximum number of attempts into a persistent data store (arranged internally or externally). After the OTP is generated, the OTP ID response module 208 transmits the generated OTP ID to the secondary device 102 (as a response to the first request), and concurrently, the OTP notification module 210 sends an OTP notification to the trusted primary device 104 (i.e. as per step 508). The OTP notification, which is received by the OTP notification module 302 of the trusted primary device 104, is a data packet which includes the user ID, OTP request ID, and OTP ID. After the user successfully authenticates himself with the server 100 on the trusted primary device 104, and acknowledges the OTP notification (i.e. as per step 510), the OTP module 306 transmits the second request to the server 100 (i.e. as per step 512). Subsequently, the OTP request module 212 receives the second request from the trusted primary device 104. Specifically, the second request, in the form of a data packet, includes the user ID, the OTP request ID, and the OTP ID (all of which are obtained from the OTP notification as received by the trusted primary device 104). That is, the second request is based on the OTP notification. Thereafter, the server 100 validates the second request, which if determined to be valid, then instructs the OTP storage module 206 to retrieve the previously stored OTP (from the data store) and the corresponding expiry date. The retrieved OTP and associated expiry date are forwarded to the OTP response module 214, and are also associated with the user ID, OTP request ID and the OTP ID. Next, the OTP response module 214 transmits the OTP and the OTP expiry date to the trusted primary device 104 (i.e. as per step 514), which is again received by the OTP notification module 302 of the trusted primary device 104.

Now, with reference to the OTP disclosed to the user on the trusted primary device 104, the user then proceeds to input the OTP into the blank input text box previously presented on the secondary device 102. Once completed, the user operates the secondary device 102 to send the OTP authentication request to the server 100 (i.e. as per step 516). It is to be appreciated that the OTP authentication request is in the form of a data packet, which includes the user ID, OTP request ID, and OTP. The OTP authentication module 216 receives the OTP authentication request from the secondary device 102, and the OTP verification module 218 proceeds to verify that the received OTP is indeed valid in relation to the user ID, OTP request ID, and OTP ID. This also means to authenticate the first request based on the OTP entered via the secondary device 102. Upon successful verification, the OTP verification response module 220 returns a web session ID to the user on the secondary device 102. The user can then use the web session ID to access the web services (which are hosted by the server 100) via the secondary device 102. In summary, the proposed server 100 discloses the method 400 for authenticating a user for granting him access to web services in a way that is convenient and secure. The method 400 combines both OTP-based and a certificate-based authentication to provide secure certificate-based two factor authentication to web services. In two factor authentication lingo, the password the user uses to unlock his associated digital certificate provides the first aspect of "something the user knows", while his digital certificate contained/stored in the trusted primary device 104 provides the second aspect of "something the user possesses". Specifically, the method 400 (performed by the server 100) securely authenticates the user on the trusted primary device 104 with support for multi-factor authentication (with the server 100), before securely distributing an OTP to the user on the trusted primary device 104, and thereafter securely authenticates the user using the OTP provided on the secondary device 102 (as referenced form the trusted primary device 104).

Several salient points about the method 400 are set out below:

1. Users are required to authenticate themselves with the server 100 before allowed to access the web services hosted by the server 100.

2. Users are provisioned with user credentials that are securely stored and protected on their respective trusted primary devices 104.

3. Users are required to provide a password on their respective trusted primary devices 104 in order to access the associated user credentials to authenticate with the server 100.

4. The proposed method 400 allows using a same user account (based on the user ID) to authenticate with the server 100 by way of using the same user credentials, without having physical access to the securely stored and protected user credentials on the trusted primary device 104.

5. The concept of using the same user credentials is achieved by introducing an OTP for authentication from the secondary device 102, and ensuring that the OTP is distributed to the user in a secure way so that the OTP is only available to the user via his trusted primary device 104, after the user has authenticated himself on the trusted primary device 104 using his digital credentials that are stored on the trusted primary device 104 and made available only on the trusted primary device 104.

6. Accordingly, if the user is able to present the correct OTP to the server 100 from the secondary device 102, the server 100 is then able to ascertain with a high degree of certainty (from a security perspective) that the user has the valid digital credentials and has authenticated successfully from the trusted primary device 104.

While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary, and not restrictive; the invention is not limited to the disclosed embodiments. Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practising the claimed invention. For example, the respective modules of the server 100 may be (independently/collectively) implemented in hardware as application-specific ICs (ASICs) for a quicker computing response. Then, the server 100 may not be hosting the web services itself, but rather, the server 100 is simply configured as an authentication gateway to other respective web servers that are in fact hosting the web services. That is, all the services might not be hosted on a same physical server. For example, the authentication service may be hosted on a first server, whereas the OTP service may instead be hosted on a different second server. Also, to reiterate, the mechanism to send notifications to the trusted primary device 104 is not limited to APNS/GCMS, and indeed could be any suitable notification mechanism (e.g. SMS, WeChat, Amazon SNS, and etc.).