WO2017003379A1 - A method performed by at least one server configured to authenticate a user for a web service login - Google Patents
A method performed by at least one server configured to authenticate a user for a web service login Download PDFInfo
- Publication number
- WO2017003379A1 WO2017003379A1 PCT/SG2016/050305 SG2016050305W WO2017003379A1 WO 2017003379 A1 WO2017003379 A1 WO 2017003379A1 SG 2016050305 W SG2016050305 W SG 2016050305W WO 2017003379 A1 WO2017003379 A1 WO 2017003379A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- otp
- computing device
- request
- user
- server
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
- G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
- H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
- H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
Definitions
- 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.
- 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.
- 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.
- OTPs One-time passwords 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.
- OTPs 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.
- OTPs are commonly distributed using text messages, OTP generation software, or hardware tokens.
- 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
- 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
- OTP one-time password
- 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.
- a suitable separate authentication e.g. certificate-based authentication
- 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.
- 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.
- APNS Apple Push Notification Service
- GCMS Google Cloud Messaging Service
- SMS Short Message Service
- the method may further comprise transmitting the first identification number to the first computing device, in response to receiving the first request.
- step (iii) may further include transmitting a configured expiry date of the first OTP to the second computing device.
- the method may further comprise establishing a secure digital communication channel with the first computing device, prior to step (i).
- 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.
- 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.
- APNS Apple Push Notification Service
- GCMS Google Cloud Messaging Service
- SMS Short Message Service
- authenticating the digital credentials of the user may preferably include using certificate-based authentication, multi-factor authentication, or private PKI infrastructure.
- the multi-factor authentication may include using smart cards for authentication.
- 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
- a method performed by a system configured to authenticate a user for a web service login 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
- 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;
- 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.
- a server device 100 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.
- OTP secure one-time password
- 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.
- 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.
- 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.
- ID OTP identification
- OTP generation module 204 OTP generation module 204
- OTP storage module 206 an OTP ID response module 208
- OTP notification module 210 an OTP request module 212
- OTP response module 214 an OTP authentication module
- 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.
- 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.
- 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.
- the authentication is performed by authenticating digital credentials of the user which are associated with his user identification.
- 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.
- 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.
- 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.
- 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.
- 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.
- OTP one
- transmitting the notification and/or the first OTP to the trusted primary device 104 may be accomplished using Apple Push Notification Service (APNS) for iOSTM-based devices, or Google Cloud Messaging Service (GCMS) for AndroidTM devices, but is not to be construed as limiting.
- APNS Apple Push Notification Service
- GCMS Google Cloud Messaging Service
- SMS Short Message Service
- 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.
- the trusted primary device 104 is digitally registered with the server 100 to form the trust relationship (as afore explained).
- 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.
- the first request is uniquely identified by an associated ID, i.e. an OTP request ID.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- the OTP notification module 302 of the trusted primary device 104 presents the OTP to the user.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- the user then proceeds to input the OTP into the blank input text box previously presented on the secondary device 102.
- the user operates the secondary device 102 to send the OTP authentication request to the server 100 (i.e. as per step 516).
- 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.
- 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.
- 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”.
- 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).
- Users are provisioned with user credentials that are securely stored and protected on their respective trusted primary devices 104.
- 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.
- 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.
- 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.
- the respective modules of the server 100 may be (independently/collectively) implemented in hardware as application-specific ICs (ASICs) for a quicker computing response.
- ASICs application-specific ICs
- 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.
- the authentication service may be hosted on a first server, whereas the OTP service may instead be hosted on a different second server.
- 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.).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
SG10201505212X | 2015-06-30 | ||
SG10201505212X | 2015-06-30 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2017003379A1 true WO2017003379A1 (en) | 2017-01-05 |
Family
ID=57608577
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/SG2016/050305 WO2017003379A1 (en) | 2015-06-30 | 2016-06-29 | A method performed by at least one server configured to authenticate a user for a web service login |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2017003379A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3582469A1 (en) * | 2018-06-14 | 2019-12-18 | Koninklijke KPN N.V. | Authentication using a mobile network operator system |
WO2020131537A3 (en) * | 2018-12-20 | 2020-07-30 | Microsoft Technology Licensing, Llc | Cross-device access to one-time passwords |
US11190517B2 (en) | 2018-08-08 | 2021-11-30 | At&T Intellectual Property I, L.P. | Access control based on combined multi-system authentication factors |
US20220417224A1 (en) * | 2021-06-25 | 2022-12-29 | Eleven-X Incorporated | Method and apparatus for authenticating encrypted communication |
EP4366238A1 (en) * | 2022-11-07 | 2024-05-08 | Cisco Technology, Inc. | Web browser-based secure equipment access |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100269162A1 (en) * | 2009-04-15 | 2010-10-21 | Jose Bravo | Website authentication |
US20110276495A1 (en) * | 2010-05-10 | 2011-11-10 | Computer Associates Think, Inc. | One-time use password systems and methods |
US20130179350A1 (en) * | 2012-01-11 | 2013-07-11 | Rawllin International Inc. | Electronic signature security algorithms |
US20130276078A1 (en) * | 2012-04-13 | 2013-10-17 | Ebay Inc. | Two factor authentication using a one-time password |
US20130297513A1 (en) * | 2012-05-04 | 2013-11-07 | Rawllin International Inc. | Multi factor user authentication |
-
2016
- 2016-06-29 WO PCT/SG2016/050305 patent/WO2017003379A1/en active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100269162A1 (en) * | 2009-04-15 | 2010-10-21 | Jose Bravo | Website authentication |
US20110276495A1 (en) * | 2010-05-10 | 2011-11-10 | Computer Associates Think, Inc. | One-time use password systems and methods |
US20130179350A1 (en) * | 2012-01-11 | 2013-07-11 | Rawllin International Inc. | Electronic signature security algorithms |
US20130276078A1 (en) * | 2012-04-13 | 2013-10-17 | Ebay Inc. | Two factor authentication using a one-time password |
US20130297513A1 (en) * | 2012-05-04 | 2013-11-07 | Rawllin International Inc. | Multi factor user authentication |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3582469A1 (en) * | 2018-06-14 | 2019-12-18 | Koninklijke KPN N.V. | Authentication using a mobile network operator system |
US11190517B2 (en) | 2018-08-08 | 2021-11-30 | At&T Intellectual Property I, L.P. | Access control based on combined multi-system authentication factors |
WO2020131537A3 (en) * | 2018-12-20 | 2020-07-30 | Microsoft Technology Licensing, Llc | Cross-device access to one-time passwords |
US11252145B2 (en) | 2018-12-20 | 2022-02-15 | Microsoft Technology Licensing, Llc | Cross-device access to one-time passwords |
US20220417224A1 (en) * | 2021-06-25 | 2022-12-29 | Eleven-X Incorporated | Method and apparatus for authenticating encrypted communication |
EP4366238A1 (en) * | 2022-11-07 | 2024-05-08 | Cisco Technology, Inc. | Web browser-based secure equipment access |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11716324B2 (en) | Systems and methods for location-based authentication | |
US10009340B2 (en) | Secure, automatic second factor user authentication using push services | |
US10136315B2 (en) | Password-less authentication system, method and device | |
US11444932B2 (en) | Device verification of an installation of an email client | |
US9979719B2 (en) | System and method for converting one-time passcodes to app-based authentication | |
EP3208732A1 (en) | Method and system for authentication | |
US8532620B2 (en) | Trusted mobile device based security | |
US9275218B1 (en) | Methods and apparatus for verification of a user at a first device based on input received from a second device | |
US20230055282A1 (en) | Multi-Factor Authentication with Increased Security | |
US10944738B2 (en) | Single sign-on for managed mobile devices using kerberos | |
EP3308526B1 (en) | Single sign-on for managed mobile devices | |
WO2017003379A1 (en) | A method performed by at least one server configured to authenticate a user for a web service login | |
US11368449B2 (en) | Asserting a mobile identity to users and devices in an enterprise authentication system | |
US11811750B2 (en) | Mobile device enabled desktop tethered and tetherless authentication | |
US10404684B1 (en) | Mobile device management registration | |
US20170230416A1 (en) | System and methods for preventing phishing attack using dynamic identifier | |
US8832812B1 (en) | Methods and apparatus for authenticating a user multiple times during a session | |
EP3496361A1 (en) | Authentication in integrated system environment | |
US20220278981A1 (en) | Authentication System for Computer Accessing a Remote Server | |
Lazarev et al. | Analysis of applicability of open single sign-on protocols in distributed information-computing environment | |
Schmitz | MFAProxy: A reverse proxy for multi-factor authentication |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16818355 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 11201800027Q Country of ref document: SG |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 25/04/2018) |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 16818355 Country of ref document: EP Kind code of ref document: A1 |