JP2016129062A - Authentication from network via device-specific one-time password - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method and system for authentication from a network via a device-specific one-time password (OTP).SOLUTION: A method includes: generating a first one-time password (OTP) on the basis at least partly of a plurality of client device attributes; and providing the first OTP to an authenticator associated with a private network during a first session, where the authenticator is configured to authenticate the client device to at least one of the private network and protected content included in the private network for a second session following the first session on the basis of the provided first OTP.SELECTED DRAWING: Figure 1

Description

  The present disclosure relates to authentication from a network, and more particularly to authentication from a network with a device specific one-time password.

  Many companies have private networks. Private networks can include local area networks (LANs) and / or enterprise networks. Employees may attempt to access these private networks remotely over public networks such as the Internet. Techniques exist for providing access to a private network over a public network and providing secure encrypted message and data transmission between the user's computing device and the private network over the public network. One such technique is virtual private network (VPN).

  The private network may be configured to prevent unauthorized users from accessing the private network and allow only authorized users to access the private network and / or information stored in the private network. Such authorized user perception typically relies on verification of the user's identity, i.e. authentication of the user against the network. Typically, to authenticate from a private network and access the private network, the user can be asked to provide a username and password. In some situations, the user may be required to provide additional authentication such as a passcode.

  A user attempting to access a private network with a computing device is required to authenticate from the computing device with a username and password, and then be authenticated from the private network with a different password and possibly another username. sell. To ensure security, passwords should be changed relatively frequently. The user must then remember the password or record the password for later retrieval. Neither technique is very reliable, and the recorded password can be obtained by someone other than the user, compromising security.

  The features and advantages of embodiments of the claimed subject matter should become apparent with reference to the drawings as the following detailed description proceeds, wherein like reference numerals indicate like parts.

FIG. 3 illustrates a device specific one-time password authentication system consistent with various embodiments of the present disclosure. 6 is a flowchart illustrating an exemplary operation of a device specific one-time password authentication system consistent with various embodiments of the present disclosure. 6 is a flowchart illustrating an exemplary operation of a client device configured to generate a one-time password consistent with an embodiment of the present disclosure. 6 is another flowchart illustrating an exemplary operation of a device specific one-time password authentication system configured to provide a second authentication consistent with various embodiments of the present disclosure.

  The following detailed description proceeds with reference to exemplary embodiments, but many alternatives, modifications, and variations of these embodiments will be apparent to those skilled in the art.

  In general, this disclosure describes a method and system for authenticating from a private network using a one-time password (OTP). The client device is configured to generate a one-time password based at least in part on the device attributes. Device attributes may include, but are not limited to, file system attributes, device settings (both software and hardware), hardware features, and device (user) context.

  Device attributes are typically device specific and cannot be replicated on another device. The unique device attributes used to generate the OTP may be selectable by a system administrator, for example, as described herein. The OTP may be generated by the client device during a session where the client device is connected to a private network. The OTP may then be stored on the client device and provided to an authenticator associated with the private network. The OTP may then be used to authenticate the client device to the private network in the next session. Thus, a client device can be authenticated to a private network using a potentially unique random OTP based on device attributes that cannot be replicated on another device. In that case, the user does not have to remember such a password. The user can be authenticated from the client device, which can then be authenticated from the private network.

  Session OTP may be used to authenticate client devices to a private network. Session OTP may also be used to control access to protected content contained in a private network. Content may include information, data and / or applications. Client devices that have been authenticated from the private network using session OTP may be configured to provide further authentication to access the protected content. Further authentication may include a static session OTP and / or a second (dynamic) session OTP, as described herein.

  In one embodiment, a second authentication may be performed. In this embodiment, the client device may be configured to generate a second (dynamic) OTP based on device attributes upon authentication. The authenticator is configured to determine successful authentication if the second OTP is within a predetermined tolerance of the stored OTP provided by the client device during the previous session. Good. The second authentication is configured to verify that the client device that generated the stored session OTP is the client device attempting the second authentication.

  For example, the selected file system attribute may be used to generate a device specific session OTP. The file system attribute may be selected based on, for example, a predetermined rule defined by the system administrator. In this example, the selected file system attribute may correspond to one or more specified areas of the hard disk included in the client device. The selected region may be static or configured to change relatively infrequently. The selected area may be scanned and data stored in the scanned area may be captured. The captured data may then be processed to generate a device specific OTP. For example, the captured data may be processed using a cryptographic hash function configured to provide an OTP of a desired size. Thus, a device-specific OTP can be generated based on device-specific device attributes.

  FIG. 1 illustrates a device-specific one-time password authentication system 100 consistent with various embodiments of the present disclosure. System 100 generally includes client device 102, private network 104, and network 106. Private network 104 generally includes an authentication server “authenticator” 108, one or more servers 140, and one or more storage devices 142. The one or more storage devices 142 may include hard disk drive (s) and / or other storage media, as described herein. Authenticator 108 may be included in private network 104 and / or associated with private network 104 (such as a gateway). A user may use client device 102 to access private network 104 via network 106. The network 106 may be a public network such as the Internet.

  Client device 102 may include a secure storage 110, a processor “CPU” 112, a memory 114, one or more storage devices 116, and a communication module 118. “Client device” as used herein means any computing device, including but not limited to mobile phones, smartphones, tablet computers, notebook computers, desktop computers, ultraportable computers, ultramobile computers. , Netbook computers, sub-notebook computers, personal digital assistants, enterprise personal digital assistants, mobile internet devices, and similar devices. The CPU 112 is configured to perform operations associated with applications and / or modules within the client device 102. Memory 114 is configured to store applications and / or data for client device 102. The one or more storage devices 116 may include hard disk drives, removable storage devices, and / or other storage media as described herein. The communication module 118 is configured to provide a network connection for the client device 102. The communication module 118 may be configured to connect to the network 106 in a wired or wireless manner using one or more communication protocols.

  Secure storage 110 is configured to restrict access to elements contained within secure storage 110. The secure storage 110 includes a security engine 120, a session OTP generation module 122, a local session OTP store 124 that may include a session OTP 123, a session OTP rule 126, and may include a dynamic session OTP 128. Security engine 120 is configured to manage secure storage 110 and control access to secure storage 110 and may be configured to perform encryption and / or hashing operations.

  The session OTP generation module 122 is configured to generate a first (static) session OTP 123 based on the device attribute 130 and the session OTP rule 126. Session OTP generation module 122 may be further configured to generate a second (dynamic) session OTP 128, as described herein. The static session OTP 123 may be generated immediately before the current session ends. The static session OTP 123 may then be used to authenticate the client device 102 to the private network 104 in the next session. In some embodiments, the static session OTP 123 may include a date field configured to include the expiration date of the static session OTP 123.

  Session OTP generation module 122 is configured to scan client device 102 and select a plurality of device attributes based on session OTP rules 126. The selected device attributes may then be selectively combined, encrypted, and / or hashed by the session OTP generation module 122 based at least in part on the session OTP rules 126. Hashing is configured to provide a session OTP of a desired length (size). The results may then be stored in the local static session OTP store 124 and provided to the authenticator 108 for storage for later use.

  Device attributes 130 include, but are not limited to, file system attributes, hardware features, software configuration settings, and user context. File system attributes include directory (folder), subdirectory (subfolder), file and file specific information (file location, file name, author, timestamp, file size, file type, string in file, file statistics and / or Other file specific information) and / or other file system attributes. Hardware features include memory size, MAC address, storage string, graphic characteristics and / or other hardware features. The user context includes user (client device 102) location, user profile, user biometric data and / or other user context data. The device attribute 130 may include any device-specific attribute. Thus, device-specific attributes include multiple device-specific data that cannot be replicated on another device.

  Session OTP rule 126 is configured to define which device attributes are selected, the number of device attributes selected, and may be configured to define hashing parameters. Session OTP rules 126 may be determined, for example, by a system administrator associated with private network 104. The unique device attributes selected and the number of device attributes selected may be based on the level of security required. For example, selecting a larger number of device attributes is more likely to result in a unique OTP than selecting fewer device attributes. Session OTP rules 126 may include selecting at least some device attributes that change relatively infrequently. Session OTP rules 126 may include at least some random functionality. The random function may be configured to ensure that each generated OTP is likely to be unique to a previously generated OTP or a later generated OTP. For example, unique device attributes may be selected randomly. In another example, the number of device attributes selected may be random and may be constrained to be greater than a threshold number. Thus, a generally unique OTP can be generated based on multiple device attributes.

  For example, if the selected device attributes include configuration settings for the application, the user profile attribute string (s) may be used to generate the session OTP. User profile attribute string (s) may be scanned and captured. The captured data may be hashed to generate a session OTP. The hashing parameter may be configured to provide a specified size session OTP.

  The generated first session OTP 123 may be stored in the local session OTP store 124 on the client device 102 and may be provided to the authenticator 108. The authenticator 108 is configured to provide an authentication service for the private network 104. The authenticator 108 includes a client session OTP inspection module 150 and a client session OTP store 152, and may include a dynamic session OTP inspection module 154 and OTP inspection rules 156.

  The client session OTP inspection module 150 is configured to receive a session OTP, eg, the first session OTP 123, from the client device 102 and manage the inspection of the client session OTP. The first session OTP 123 is configured to be used to authenticate the client device 102 in the next session, as described herein. The authenticator 108 is configured to store the received first session OTP 123 in the client session OTP store 152 for later use. Thus, when a session OTP is generated by the client device 102, the generated first session OTP 123 can be stored in the local session OTP store 124 of the client device 102 and the client session OTP store 152 of the authenticator 108. .

  When a user attempts to access the private network 104 using the client device 102, the user may receive his own authentication from the client device 102, and the client device 102 then attempts to authenticate from the private network 104. It's okay. The session OTP stored in the local session OTP store 124 (“local session OTP”) may be provided to the authenticator 108 as part of the authentication process. The client session OTP inspection module 150 is configured to receive a local session OTP and compare the received local session OTP with a session OTP stored in the client session OTP store 152 (“client session OTP”). If the local session OTP corresponds to the client session OTP, the client device 102 may be authenticated to the private network 104 and access may be permitted.

  When the client device 102 receives an indication that the session is to be terminated, the session OTP generation module 122 generates a new session OTP, stores the new session OTP in the local session OTP store 124, and stores the new session OTP in the authenticator 108. Configured to provide. The authenticator 108 may then store the received new session OTP in the client session OTP store 152 for use in the next session.

  Thus, a unique device-specific session OTP can be generated and stored during the current session to authenticate the client device 102 to the private network 104 in the next session. A unique device-specific session OTP or another device-specific session OTP may be utilized to authenticate the client device 102 for access to protected content in the private network. Session OTP may be generated based on client device attributes 130 and session OTP rules 126. The user may not remember a frequently changed password for accessing the private network 104. The session OTP corresponds to a shared secret between the client device 102 and the private network 104.

  In some situations, it may be desirable to require a second authentication to access private network 104 and / or protected content within private network 104. Such second authentication is configured to provide a relatively higher level of security than is available with only the first authentication. The second authentication is configured to confirm that the device to be authenticated is the client device 102 that provided the first session OTP 123 in the previous session. The first authentication may be performed using a first (static) session OTP, as described herein. A second authentication may then be performed using a second (dynamic) session OTP. The first session OTP is generated by the client device 102, stored on the client device 102, and provided to the authenticator 108 for use in the next session, as described herein. It's okay. The first session OTP is thus present on the client device 102 before the next session. The second (dynamic) session OTP is configured to be generated during an authentication attempt rather than during a previous session. Therefore, the second session OTP is generated based on the device attribute at the time of authentication. The second authentication is configured to confirm that the device that is to be authenticated from the private network is the client device 102 that provided the first session OTP 123 stored in the authenticator 108.

  If a second (dynamic) authentication is requested (based on policy), a second dynamic session OTP 128 may be generated based on device attributes 130 and session OTP rules 126. The session OTP rule 126 used to create the second (dynamic) session OTP 128 corresponds to the session OTP rule 126 used to create the first (static) session OTP 123. In other words, the same rules may be used to generate both the first session OTP 123 and the second session OTP 128. Similarly, the same device attribute 130 may be used to generate both the first session OTP 123 and the second session OTP 128. However, the value associated with the device attribute may change between the generation of the first session OTP 123 and the generation of the second session OTP 128. For example, the file may have been edited. As another example, device settings may have changed. As another example, the device context, eg, location, may have changed. Thus, tolerance (ie, range) may be utilized when evaluating whether the second session OTP 128 corresponds to the first session OTP 123. If the second session OTP 128 is within the tolerance of the first session OTP 123, the second authentication may be considered successful.

  The dynamic session OTP inspection module 154 is configured to perform the second authentication based at least in part on the OTP inspection rules 156. The OTP inspection rule 156 may include a tolerance parameter (s) to be utilized for the second inspection. The second (dynamic) session OTP 128 may be generated in response to a request for second authentication. The second session OTP 128 may be generated by the session OTP generation module 122 and provided to the authenticator 108. The dynamic session OTP inspection module 154 receives the second session OTP 128, compares the second session OTP 128 with the first (static) session OTP 123 from the client session OTP store 152, and based on the OTP inspection rules 156 It is configured to determine whether the second session OTP 128 corresponds to the first (static) session OTP 123.

  For example, the device attributes selected as the basis for generating the session OTP may include file system attributes. The file system may be scanned and data captured at a plurality of random locations within a predetermined range. A secure hash may then be applied to the scanned (captured) attributes to generate a session OTP. The secure hash may be configured to yield a desired size session OTP. The session OTP may then be provided to the authenticator 108. Authenticator 108 may store a session OTP and may include a time stamp with the stored session OTP. If second authentication is required, the file system may be scanned at multiple locations within the same range. The captured scan result may be hashed to generate a second (dynamic) OTP. The second OTP may be provided to the authenticator 108. The authenticator 108 may then compare the stored session OTP with the dynamic OTP. Since the file system attribute may have changed between the generation of the first session OTP and the generation of the second session OTP, the client device may determine that the second session OTP has a predetermined percentage ( (For example, 90%) may be considered valid when corresponding to the first session OTP.

  In another example, the device attribute may include a time stamp. In this example, hardware attributes may be utilized to generate the first session OTP and the second session OTP. In this example, a hardware attribute change below a threshold over a predetermined time interval can result in a test success, and a hardware attribute change above a threshold over a predetermined time interval can result in a test failure.

  FIG. 2 shows a flowchart 200 of exemplary operations of a device specific OTP authentication system consistent with various embodiments of the present disclosure. The operations of flowchart 200 may be performed by a client device, eg, client device 102, and / or an authenticator, eg, authenticator 108. In particular, flowchart 200 illustrates an exemplary operation configured to authenticate a client device to a private network using device-specific OTP, consistent with this disclosure.

  The operations of flowchart 200 may begin with a login 202 to a user's client device. At act 204, a private network access request may be initiated. At act 206, it may be determined whether a valid client session OTP exists at the authenticator. If no valid client session OTP exists at the authenticator, standard user authentication may be performed at operation 208. At operation 210, it may be determined whether standard authentication is successful. If standard authentication is not successful, the connection may be terminated at operation 212. If the standard authentication is successful, the program flow may proceed to operation 218 as described herein.

  Returning to operation 206, if a valid client session OTP exists at the authenticator, a local session OTP may be requested from the client device at operation 214. At act 216, it may be determined whether the received local session OTP corresponds to a client session OTP stored in the authenticator. If the received local session OTP does not correspond to the stored client session OTP, at operation 208, standard user authentication may be performed. If the local session OTP corresponds to a stored client session OTP, at operation 218, access may be granted and / or a second (dynamic) user authentication may be required depending on the policy. At operation 220, it may be determined whether the session is terminated. If the session ends, at operation 222, a new session OTP may be generated by the client device and provided to the authenticator. At operation 224, the new session OTP may be stored by the authenticator as a client session OTP. Then, at operation 226, the session may be terminated.

  FIG. 3 illustrates a flowchart 300 of an exemplary operation of a client device configured to generate a device specific session OTP, consistent with one embodiment of the present disclosure. The operations of flowchart 300 may be performed by a client device, eg, client device 102, and correspond to operation 222 of FIG. In particular, flowchart 300 illustrates example operations configured to generate a session OTP to be provided to an authenticator that will be used to authenticate a client device in the next session. . The program flow may begin with an indication 302 that the session ends. Act 304 includes obtaining (capturing) the selected device attributes. The unique device attributes that are captured may be based on session OTP rules. At operation 306, a new session OTP may be generated based at least in part on the selected device attributes and session OTP rules. Act 308 includes storing the new session OTP in the local session OTP on the client device and providing the new session OTP to the authenticator. Then, at operation 310, the session may be terminated.

  FIG. 4 illustrates another flowchart 400 of exemplary operation of a device-specific OTP authentication system configured to provide second authentication, consistent with various embodiments of the present disclosure. The operations of flowchart 400 may be performed by a client device, eg, client device 102, and / or an authenticator, eg, authenticator 108. In particular, flowchart 400 illustrates an exemplary operation configured to perform a second authentication using a second (dynamic) OTP generated upon authentication based on device attributes. The operations of flowchart 400 may be included in operations 218 of FIG. The operations of flowchart 400 may begin with a request 402 for second user authentication. Act 404 may include generating a second (dynamic) session OTP based at least in part on the selected device attributes and session OTP rules. At act 406, a second (dynamic) session OTP may be provided to the authenticator. At operation 408, it may be determined whether the dynamic session OTP corresponds to a stored client session OTP within a predetermined tolerance. If the dynamic session OTP does not correspond to the stored client session OTP with a predetermined tolerance, the dynamic authentication may fail at operation 410 and the session may be terminated at operation 412. If the dynamic session OTP corresponds to the stored client session OTP with a predetermined tolerance, dynamic authentication is successful at operation 414 and the session may continue at operation 416.

  Thus, a client device can be authenticated against a private network and / or protected content using a session OTP generated based on multiple device attributes and session OTP rules. The plurality of device attributes correspond to a device “fingerprint” unique to the device. Device attributes can change over time, and the device attributes selected to generate the session OTP can also change. Thus, each session OTP generated can be substantially unique and generally random. The session OTP may be generated during the current session for use in authentication in the next session. Thus, the session OTP can correspond to a shared secret between the client device and the authenticator.

  In some embodiments, the second dynamic authentication may be performed using a first session OTP that is generated prior to the authentication attempt and a second session OTP that is generated during the authentication attempt. The second session OTP is configured to verify the identification information of the client device with higher reliability. Since the second session OTP is generated upon authentication and is not stored on the client device, the second session OTP is relatively more secure. Since the device attribute may change between the generation of the first session OTP and the generation of the second session OTP, the generation of the first session OTP and the generation of the second session OTP Some variation between them can be expected. Thus, tolerances and / or thresholds can be used to allow for this variation.

  Although FIGS. 2-4 illustrate various operations according to one embodiment, it should be understood that not all operations illustrated in FIGS. 2-4 may be required for other embodiments. is there. Indeed, in other embodiments of the present disclosure, the operations illustrated in FIGS. 2-4 and / or other operations described herein are not specifically illustrated in any of the drawings herein. However, it is well contemplated that it can nevertheless be combined in a manner that is sufficiently consistent with the present disclosure. Thus, claims directed to features and / or actions not explicitly shown in certain drawings are considered within the scope and spirit of this disclosure.

  A system that includes one or more storage media storing instructions, individually or in combination, that perform each method when performed by one or more processors, any of the operations described herein May be implemented. Here, the processor may include, for example, a client device CPU, a server CPU, and / or other programmable circuits. It is also contemplated that the operations described herein may be distributed across multiple physical devices, such as processing structures at multiple different physical locations. The storage medium includes any kind of tangible medium, such as a hard disk, floppy disk, optical disk, compact disk read only memory (CD-ROM), rewritable compact disk (CD-RW), and magneto-optical disk. Any type of disk, read only memory (ROM), random access memory (RAM) such as dynamic RAM and static RAM, erasable writable read only memory (EPROM), electrically erasable writable read only memory (EEPROM), It may include a flash memory, a semiconductor device such as a solid state disk (SSD), a magnetic or optical card, or any type of medium suitable for storing electronic instructions. Other embodiments may be implemented as software modules that are executed by a programmable control device. The storage medium may be non-transitory.

  While the above is provided as an exemplary system architecture and methodology, modifications to the present disclosure are possible. For example, memory such as client device memory 114, authenticator memory and / or server memory may include one or more of the following types of memory. Semiconductor firewall memory, programmable memory, non-volatile memory, read-only memory, electrically writable memory, random access memory, flash memory, magnetic disk memory, and / or optical disk memory. Additionally or alternatively, the client device memory 114, authenticator memory and / or server memory may include other types and / or later developed types of computer readable memory.

  Client device 102 may be configured to communicate with network 106 and / or private network 104 using various communication protocols. Communication protocols may include wireless communication protocols such as but not limited to Wi-Fi, 3G, 4G, and / or other communication protocols. The communication protocol may be compliant and / or compliant with other related Internet Engineering Task Force (IETF) standards.

  Wi-Fi protocol, published by the date 8 March 2007, "IEEE 802.11-2007 Standard, IEEE Standard for Information Technology-Telecommunications and Information Exchange Between Systems-Local and Metropolitan Area Networks-Specific Requirements - Part 11 ： Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications ”, the Institute of Electrical and Electronics Engineers (IEEE) ctrical and Electronics Engineers) issued by the 802.11 standard, and / or compliant with a new version of this standard, or may conform.

  The 3G protocol is an International Mobile Telecommunications (IMT) standard published by the International Telecommunications Union (ITU) published in 2000 and named “IMT-2000” and / or It may conform to or conform to a new version of the standard. The 4G protocol may comply with or be compatible with the IMT standard published by 2008 and named “IMT-Advanced” and / or new versions of this standard.

  Client device 102 may be able to communicate with network 106 and / or private network 104 using a selected packet switched network communication protocol. One exemplary communication protocol may include an Ethernet communication protocol that may allow communication using Transmission Control Protocol / Internet Protocol (TCP / IP). The Ethernet protocol is an Ethernet standard published by the American Institute of Electrical and Electronics Engineers (IEEE), published in March 2002, named “IEEE 802.3 Standard” and / or It may conform to or conform to a new version of this standard. Alternatively or in addition, the client device 102 It may be possible to communicate with the network 106 and / or the private network 104 using 25 communication protocols. X. The 25 communication protocol may conform to or conform to a standard published by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T). Alternatively or additionally, client device 102 may be able to communicate with network 106 and / or private network 104 using a frame relay communication protocol. The Frame Relay communication protocol is published by the International Telegraph and Telephone Consultative Committee (CCITT) and / or by the American National Standards Institute (ANSI) or compliant with the American National Standards Institute (ANSI). It's okay. Alternatively or additionally, client device 102 may be able to communicate with network 106 and / or private network 104 using an asynchronous transfer mode (ATM) communication protocol. The ATM communication protocol conforms to or conforms to the ATM standard published by the ATM Forum, published in August 2001, named “ATM-MPLS Network Interworking 1.0” and / or a new version of this standard. You can do it. Of course, different and / or later developed connection-oriented network communication protocols are equally contemplated herein.

  "Circuit" as used in any embodiment herein, for example, instructions executed by a wiring circuit, a programmable circuit, a state machine circuit, and / or a programmable circuit, either alone or in any combination Firmware may be included. An application and / or module may be embodied as a circuit when used in any of the embodiments herein. The circuit may be embodied as an integrated circuit such as an integrated circuit chip.

  The method and system for receiving authentication from the private network using the device-specific session OTP has been described above. The client device is configured to generate a session OTP based at least in part on the device attributes. A session OTP may be generated by a client device during a session in which the client device is connected to a private network. The session OTP may then be stored on the client device and provided to an authenticator associated with the private network. The session OTP may then be used to authenticate the client device to the private network in the next session. In one embodiment, a second authentication may be performed. In this embodiment, the client device may be configured to generate a second (dynamic) OTP based on device attributes upon authentication. In this embodiment, the authenticator determines that the authentication is successful if the second OTP is within a predetermined tolerance of the stored OTP provided by the client device during the previous session. It may be configured.

  Thus, the client device can be authenticated to the private network using a potentially unique random OTP based on device attributes. In that case, the user does not have to remember such a password. The user can be authenticated from the client device, which can then be authenticated from the private network. The second authentication is configured to provide a relatively more robust authentication that does not rely on the session OTP stored on the client device.

  According to one aspect, a method is provided. A method generates a first one-time password (OTP) based at least in part on a plurality of client device attributes, and the first OTP is associated with a private network during the first session. The authenticator is included in the private network and the private network for a second session following the first session, based on the provided first OTP. The client device is configured to authenticate against at least one of the protected content.

  According to another aspect, a system is provided. The system may include a client device and an authenticator. The client device generates a first one-time password (OTP) based at least in part on a plurality of client device attributes, and the first OTP is associated with the private network during the first session. Based on the first OTP that is provided, the authenticator is protected in private and private networks for the second session following the first session. Configured to authenticate the client device for at least one of the stored content.

  According to another aspect, a system is provided. The system may include one or more storage media that store instructions that, when executed by one or more processors, cause the following operations individually or in combination, the operations comprising at least Some generate the first one-time password (OTP) based on multiple client device attributes and provide the first OTP to the authenticator associated with the private network during the first session The authenticator, based on the provided first OTP, for the second session following the first session, of the protected content included in the private network and the private network The client device is configured to authenticate to at least one.

  The terms and expressions used herein are words of description rather than limitation, and any equivalents of the features (or portions of the features) illustrated and described may be used when using such terms and phrases. It is not intended to be excluded, but it will be appreciated that various modifications are possible within the scope of the claims. Accordingly, the claims are intended to cover all such equivalents.

Claims (15)

Generating a first one-time password (first OTP) based at least in part on a plurality of client device attributes;
Providing the first OTP to an authenticator associated with a private network during a first session;
The authenticator is configured to, based on the provided first OTP, for at least one of the private content and the protected content included in the private network for a second session following the first session. A method of authenticating a client device against one. Generating a second OTP based at least in part on the plurality of client device attributes;
The second OTP is generated when the client device is authenticated to the private network for the second session, and the second OTP provides secondary authentication. The method according to 1. Storing the first OTP in the client device;
Comparing the stored first OTP with the first OTP provided to the authenticator;
The method of claim 1, wherein the client device is authenticated to the private network if the stored first OTP corresponds to the first OTP provided to the authenticator. Further comprising comparing the first OTP to the second OTP;
The method of claim 2, wherein the client device is authenticated to the private network if the first OTP is within a tolerance of the second OTP. The method of claim 1, further comprising selecting the plurality of client device attributes based on predetermined OTP rules.   The method of claim 1, wherein generating the first OTP includes applying a secure hash to the plurality of client device attributes.   The method of any one of claims 1 to 6, wherein the plurality of client device attributes include at least one of a file system attribute, a hardware feature, a software configuration setting, and a user context. A client device;
With an authenticator,
The client device generates a first one-time password (first OTP) based at least in part on a plurality of client device attributes, and the first OTP is exchanged with a private network during a first session. Providing the associated authenticator, the authenticator based on the provided first OTP for the second session following the first session for the private network and the private network A system for authenticating the client device against at least one of the protected content contained in   The client device further generates a second OTP based at least in part on the plurality of client device attributes, wherein the second OTP is used by the client device for the second session. 9. The system of claim 8, wherein the second OTP is generated when authenticated against the second OTP to provide secondary authentication.   The client device further stores the first OTP, and the authenticator further compares the first OTP stored in the client device with the first OTP provided to the authenticator. 9. The client device of claim 8, wherein the client device is authenticated to the private network if the stored first OTP corresponds to the first OTP provided to the authenticator. system.   The authenticator further compares the first OTP with the second OTP, and the client device communicates with the private network if the first OTP is within the tolerance of the second OTP. 10. The system of claim 9, wherein the system is authenticated.   The system of claim 8, wherein the client device selects the plurality of client device attributes based on predetermined OTP rules.   The system of any one of claims 8 to 12, wherein the plurality of client device attributes includes at least one of a file system attribute, a hardware feature, a software configuration setting, and a user context.   The program for making a computer perform each step contained in the method as described in any one of Claim 1 to 6.   The program of claim 14, wherein the plurality of client device attributes include at least one of a file system attribute, a hardware feature, a software configuration setting, and a user context.

Images