Connection-resilient multi-factor authentication

Abstract

A first authenticator payload including a first authenticator random value is obtained. A first authenticator encrypted file is generated using an authenticator public key associated with a client authenticator application. The first authenticator encrypted file is generated based on a first encryption algorithm. The first authenticator encrypted file includes the first authenticator payload. A first target payload including a first target random value is obtained. A first target encrypted file is generated using the first authenticator random value. The first target encrypted file is generated based on a second encryption algorithm. The first target encrypted file includes the first target payload.

Description

[Technical Field]

[0001] TECHNICAL FIELD This disclosure relates to data security, and more particularly to authenticating target machines during varying network availability. [Background technology]

[0002] Authenticating a computer system through providing login credentials can be one method for providing security for the computer system. The login credentials can be combined with additional factors to enhance the security of the computer system. The additional factors can depend on network availability for success. Summary of the Invention [Means for solving the problem]

[0003] According to embodiments of the present invention, a method, system and computer program product are disclosed.

[0004] A first authenticator payload including a first authenticator random value is obtained. A first authenticator encrypted file is generated using an authenticator public key associated with a client authenticator application. The first authenticator encrypted file is generated based on a first encryption algorithm. The first authenticator encrypted file includes the first authenticator payload. A first target payload including a first target random value is obtained. A first target encrypted file is generated using the first authenticator random value. The first target encrypted file is generated based on a second encryption algorithm. The first target encrypted file includes the first target payload.

[0005] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure.

[0006] The drawings contained herein are incorporated into and constitute a part of this specification. The drawings illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The drawings are merely illustrative of certain embodiments and are not intended to limit the disclosure. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 illustrates representative major components of an exemplary computer system that may be used in accordance with some embodiments of the present disclosure. [Figure 2]FIG. 2 illustrates a cloud computing environment in accordance with an embodiment of the present invention. [Figure 3] FIG. 3 illustrates abstraction model layers according to one embodiment of the present invention. [Figure 4A] FIG. 4A illustrates an example system configured to perform multi-factor authentication during varying network availability, consistent with some embodiments of the present disclosure. [Figure 4B] FIG. 4B illustrates an example system that performs multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. [Figure 4C] FIG. 4C illustrates an example system that performs multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. [Figure 4D] FIG. 4D illustrates an example system that performs multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. [Figure 4E] FIG. 4E illustrates an example system for performing multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. [Figure 4F] FIG. 4F illustrates an example system that performs multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. [Figure 4G] FIG. 4G illustrates an example system that performs multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. [Figure 5] FIG. 5 illustrates an exemplary method for multi-factor authentication by an authentication server, consistent with some embodiments of the present disclosure. [Figure 6] FIG. 6 illustrates an exemplary method of multi-factor authentication by a target machine consistent with some embodiments of the present disclosure. [Figure 7] FIG. 7 illustrates an example method for multi-factor authentication by an authentication application consistent with some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0008] While the invention is susceptible to various modifications and alternative forms, specific features thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. Rather, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the invention.

[0009] Aspects of the present disclosure relate to data security, and more particularly to authenticating target machines during varying network availability. While the present disclosure is not necessarily limited to such applications, various aspects of the present disclosure may be understood through a discussion of various examples using this context.

[0010] Modern computer systems are becoming increasingly prevalent as tools for the purposes of creating, consuming, storing, and sharing data. For example, individuals may have data (e.g., bank account information, private conversations, medical information) stored, shared, or otherwise accessed by computer systems. In another example, an organization (e.g., a financial institution, a hospital, a government agency) may be responsible for generating, collecting, storing, or securing data. The livelihoods of various individuals may depend on adequate data security. For example, if data is not kept confidential or otherwise properly protected, the organization or individual may suffer significant financial or other losses.

[0011] One way computer systems try to enforce data security is through single-factor authentication. For example, the operating system (e.g., macOS) 登録商標 , Unix 登録商標 , Windows 登録商標A single-factor authentication system (SFA) may establish a specific scheme, challenge, or set of computer operations to perform single-factor authentication. In such computer operations, an entity (e.g., a client device, a user computer, a user) may be presented with a request for an identity and a request for a first factor to verify that identity. The identity may be a username or serial number associated with the user. The first factor may be a piece of information known by the entity, such as a password or passphrase. Another first factor may be information that describes the entity itself or a piece of information related to the entity, such as biometric data (e.g., a user's fingerprint, a three-dimensional model of the user) or machine data (e.g., a computer system's serial number, the amount of memory installed in a computer system).

[0012] To increase security, computers may utilize multi-factor authentication (MFA). MFA may involve requiring a second or additional factor, information, or challenge. The additional factor of MFA may increase security in that the computer system will respond only if all factors are provided (e.g., username, password, and second factor together). MFA may be improved by storing the additional factor on another device. For example, a computer system protected by MFA (hereinafter, the "target machine") may require a factor stored or provided by a second client device (e.g., a user's smartphone). These second factor devices may be termed "authenticators." Various examples of MFA include time-based one-time passwords (TOTP) and push authentication.

[0013] In many MFA configurations, various elements may be performed by one or both of the accessed device (hereinafter, the “target machine”) (e.g., the computer the user is attempting to log in to) and a second MFA device, where the target machine and the second MFA device may each interface with a third external verification service, such as a central or remote authentication / verification server (hereinafter, the “authentication server”). In most MFA configurations, security practices may favor the target machine obtaining its MFA verification results from a trusted external authentication service via network communications (e.g., the authentication server). In particular, a user attempts to log in to a target machine that is over a network connection with another computer (e.g., the Internet). The user provides a username and password to the target machine. The target machine may include a suite of authentication modules or libraries deployed (e.g., Windows Credential Provider, Unix Pluggable Authentication Modules) for communicating with external machines, such as authentication servers. Sometime contemporaneously, a user's secondary computer (e.g., a smartphone, a personal laptop) is provided with a second factor, and the target machine is also provided with the second factor over the network connection. The user may provide the second factor received from the secondary computer to the target machine. The target machine may verify identity using the first factor and the second factor.

[0014] Many MFA technologies have several drawbacks. One drawback may be the need for an online connection. Specifically, some MFA operations depend on a network connection. These online-based MFA technologies may operate properly during times of online connection. However, online-based MFA cannot be completed during periods when the connection between the target machine and the authentication server is unavailable. Furthermore, fallback behaviors for online-based MFA may also not be ideal. One fallback involves denying access to the target machine. While denying access to the target machine may be more secure, it may become impractical or present unacceptable technical hurdles. For example, during downtime or maintenance, the target machine may need to be accessed to perform some administration. If this downtime coincides with network unavailability, it may be impossible to access or log in to the target machine. Another fallback involves skipping the MFA operation and allowing access during a network outage or downtime. This poses a security risk and may be used by a third party to circumvent security. For example, a malicious user could prevent a target machine from accessing a network connection, causing the target machine to skip the MFA operation and grant access based on a single factor.

[0015] Another drawback is that the shared secret can potentially be accessed if any device in the MFA chain is compromised. Specifically, TOTP MFA may operate by sharing a second factor that is initially static. For example, a specific static value is shared between the authentication server, the target machine, or the secondary computer used for MFA, or a combination thereof. The static value is then placed into a time-based algorithm so that the value changes periodically (e.g., every 30 seconds) among all devices. Each device participating in TOTP requires the initial static value and an algorithm to update the static value at predefined periodic intervals. If one device is compromised, its second factor (i.e., the static value and the TOTP algorithm) may be obtained by a third party. The third party who obtains the second factor can then masquerade as the TOTP MFA secondary computer and gain access to the target machine.

[0016] Connection resilient multi-factor authentication (CRMFA) may operate to circumvent other security techniques. CRMFA may implement an MFA scheme between an authentication server, a target machine, and an authenticator application (hereinafter, “authenticator app”) running on a secondary computer. CRMFA may circumvent MFA security or access issues, or a combination thereof, between the server, target machine, and authenticator app, even during network instability or outages. CRMFA may utilize pairing (e.g., cryptographic pairing) of various MFA devices. The MFA devices may include the target machine, the authentication server, and the authenticator app. The MFA devices utilizing CRMFA may have advantages over TOTP operations, such as not sharing a shared secret. By not sharing a secret, CRMFA may be secure even if one of the MFA devices is compromised or otherwise accessed by a malicious entity.

[0017] The CRMFA may operate by sharing an encrypted value from an authentication server to other MFA devices during an online connection (e.g., during a network connection, during online MFA). The encrypted value may be a different encrypted value for each of the other MFA devices. Specifically, the target machine may receive one or more target encrypted files containing target random values. The target machine may not be able to initially decrypt the encrypted files. For example, the target machine may receive and store the target encrypted files but may not be able to independently obtain, decrypt, or otherwise access the target random values. The authenticator app may optionally run on another computing device and receive one or more authenticator encrypted files containing authenticator random values. The authenticator encrypted files may be accessible by the authenticator app. For example, a public key (part of a public / private key pair) may be provided by the authenticator app to a central authentication service, such as during a registration ceremony. The central authenticator service may encrypt the authenticator-encrypted file with the public key. The authenticator app may decrypt the authenticator-encrypted file with the private key to obtain an authenticator random value. The authenticator app may then possess the authenticator random value, which is the key to unlock the target-encrypted file. As a result, a target machine may only be able to verify the contents of the target-encrypted file as part of a CRMFA by providing the target-encrypted file to the authenticator app for decryption.

[0018] The CRMFA may also be resilient to offline attacks. Specifically, the authentication server may provide only a limited number of encrypted files containing random values ​​to each of the other MFA devices. For example, the authenticator app and the target machine may be configured to use the encrypted files, a given authenticator encrypted file, and a given target encrypted file only once. After a single attempt, the authenticator app or target machine, or a combination thereof, may be configured to delete the encrypted files, thereby disabling future attempts to perform MFA offline. The CRMFA may also be configured to be self-expiring, such that each encrypted file also expires as part of the CRMFA. Specifically, each target encrypted file and authenticator encrypted file may include an expiration value, and the target machine or authenticator app, or a combination thereof, may be configured to only operate based on random values ​​that have not yet expired. If the encrypted files are expired, the authenticator app or the target machine, or a combination thereof, may be configured to invalidate or delete, or invalidate and delete, all data associated with the encrypted files. Thereafter, when network availability to the central authentication server is restored, the CRMFA may proactively generate a new set of encrypted files (e.g., before another network outage or unavailability occurs).

[0019] FIG. 1 illustrates representative major components of an exemplary computer system 100 (alternatively, a computer) that may be used in accordance with some embodiments of the present disclosure. It is understood that the individual components may vary in complexity, number, type, or configuration, or combinations thereof. The specific example disclosed is for illustrative purposes only and is not necessarily the only such variation. Computer system 100 may include a processor 110, memory 120, an input / output interface (herein, I / O or I / O interface) 130, and a main bus 140. Main bus 140 may provide a communication path for other components of computer system 100. In some embodiments, main bus 140 may connect to other components, such as a component-specific digital signal processor (not shown).

[0020] Processor 110 of computer system 100 may be comprised of one or more cores 112A, 112B, 112C, and 112D (collectively, cores 112). Processor 110 may further comprise one or more memory buffers or caches (not shown) that provide temporary storage of instructions and data for cores 112. Core 112 may execute instructions on input provided from the cache or from memory 120 and output results to the cache or memory. Core 112 may be comprised of one or more circuits configured to execute one or more methods consistent with embodiments of the present disclosure. In some embodiments, computer system 100 may comprise multiple processors 110. In some embodiments, computer system 100 may have a single processor 110 with a single core 112.

[0021] The memory 120 of the computer system 100 may include a memory controller 122. In some embodiments, the memory 120 may include a random-access semiconductor memory, storage device, or storage medium (either volatile or non-volatile) for storing data and programs. In some embodiments, the memory may be in the form of a module (e.g., a dual in-line memory module). The memory controller 122 may communicate with the processor 110 to facilitate the storage and retrieval of information in the memory 120. The memory controller 122 may communicate with the I / O interface 130 to facilitate the storage and retrieval of inputs or outputs in the memory 120.

[0022] I / O interface 130 may include an I / O bus 150, a terminal interface 152, a storage interface 154, an I / O device interface 156, and a network interface 158. I / O interface 130 may connect main bus 140 to I / O bus 150. I / O interface 130 may direct instructions and data from processor 110 and memory 120 to various interfaces of I / O bus 150. I / O interface 130 may also direct instructions and data from various interfaces of I / O bus 150 to processor 110 and memory 120. The various interfaces may include terminal interface 152, storage interface 154, I / O device interface 156, and network interface 158. In some embodiments, the various interfaces may include a subset of the interfaces described above (e.g., an embedded computer system in an industrial application may not include terminal interface 152 and storage interface 154).

[0023] Logical modules throughout computer system 100 (including, but not limited to, memory 120, processor 110, and I / O interface 130) may communicate faults and changes to one or more components to a hypervisor or operating system (not shown). The hypervisor or operating system may allocate the various resources available in computer system 100 and track the location of data within memory 120 and the locations of processes assigned to the various cores 112. In embodiments that combine or rearrange elements, aspects and capabilities of the logical modules may be combined or redistributed. These variations will be apparent to those skilled in the art.

[0024] Although this disclosure includes detailed descriptions related to cloud computing, it should be understood that implementation of the teachings recited herein is not limited to a cloud computing environment. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0025] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0026] The features are as follows:

[0027] On-demand self-service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, as needed, without requiring human interaction with the provider of the service.

[0028] Broad network access: Functionality is available over the network and accessed via standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0029] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, and various physical and virtual resources are dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge of the exact location of the resources provided, but are said to be location-independent in that they may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0030] Rapid Elasticity: Capabilities can be provisioned quickly and elastically, sometimes automatically, scaled out quickly, released quickly, and scaled in quickly. To the consumer, the capabilities available for provisioning are often unlimited and can be purchased in any quantity at any time.

[0031] Measured Services: Cloud systems automatically control and optimize resource usage by using metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services being used.

[0032] The service model is as follows:

[0033] Software as a Service (SaaS): The ability to offer consumers the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface, such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings.

[0034] Platform as a Service (PaaS): The capability offered to consumers to deploy consumer-created or acquired applications, created using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure (e.g., including networks, servers, operating systems, or storage), but does have control over the deployed applications and, in some cases, the application-hosting environment configuration.

[0035] Infrastructure as a Service (IaaS): The capability offered to consumers to provision processing, storage, network, and other basic computing resources on which they can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does have control over the operating systems, storage, deployed applications, and in some cases, limited control over selecting network components (e.g., host firewalls).

[0036] The deployment models are as follows:

[0037] Private Cloud: Cloud infrastructure is operated exclusively for an organization. The cloud infrastructure may be managed by the organization or a third party, and may reside on-premises or off-premises.

[0038] Community Cloud: Cloud infrastructure is shared by several organizations and supports a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by the organizations or a third party and may reside on-premises or off-premises.

[0039] Public Cloud: Cloud infrastructure is available to the general public or large industry groups and is owned by organizations that sell cloud services.

[0040] Hybrid Cloud: A cloud infrastructure is a blend of two or more clouds (private, community, or public) that remain unique entities but are brought together by standardized or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data and application portability.

[0041] A cloud computing environment is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure comprising a network of interconnected nodes.

[0042] Referring now to Figure 2, an exemplary cloud computing environment 50 is illustrated. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, or an automotive computer system 54N, or combinations thereof, may communicate. The nodes 10 may communicate with each other. The nodes 10 may be physically or virtually grouped into one or more networks (not shown), such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as previously described herein.

[0043] This allows the cloud computing environment 50 to provide infrastructure, platform, or software, or a combination thereof, as a service without the cloud consumer having to maintain resources on a local computing device. It is understood that the types of computing devices 54A-54N shown in Figure 2 are intended to be exemplary only, and that the cloud computing node 10 and the cloud computing environment 50 can communicate with any type of computerized device (e.g., using a web browser) over any type of network or network-addressable connection, or combination thereof.

[0044] Referring now to Figure 3, one set of functional abstraction layers provided by cloud computing environment 50 (Figure 2) is shown. It should be understood that the components, layers, and functions shown in Figure 3 are intended to be merely exemplary, and that embodiments of the present disclosure are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0045] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include a mainframe 61, a RISC (Reduced Instruction Set Computer) architecture-based server 62, a server 63, a blade server 64, a storage device 65, and a network and networking component 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0046] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71; virtual storage 72; virtual networks 73, including, for example, virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0047] In one example, management layer 80 may provide several functions, as described below. Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks and protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides allocation and management of cloud computing resources so that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-provisioning and procurement of cloud computing resources where future requirements are predicted according to SLAs.

[0048] Workload tier 90 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this tier include one of: mapping and navigation 91; software development and lifecycle management 92; virtual classroom instruction delivery 93; data analytics processing 94; transaction processing 95; and CRMFA 96.

[0049] 4A-4G illustrate an example system 400 for multi-factor authentication consistent with some embodiments of the present disclosure. System 400 can be configured to implement CRMFA to enable multi-factor authentication during varying network availability. For example, CRMFA can provide a cryptographically random value used for MFA, which can enable various MFA devices to operate during times when the network is unavailable. System 400 can include one or more of: authentication server 410; one or more networks, including, for example, networks 420-1 and 420-2 (collectively, “networks 420”); authenticator app 430; and target machine 440.

[0050] Authentication server 410 may be a computer system configured to perform one or more CRMFA operations. Authentication server 410 may be a single computer with I / O, memory, and processing, such as computer system 100. Authentication server 410 may also be an abstracted resource based on multiple computers, such as cloud computing environment 50. Authentication server 410 may be configured to process one or more MFA operations. Specifically, authentication server 410 may operate by executing associated cryptographic algorithms to generate various encrypted files (e.g., secure hash algorithms, cryptographic hash functions, RIPEMD functions). Authentication server 410 may also be configured to generate one or more random values ​​(e.g., random strings, random characters, random numbers).

[0051] Network 420 may be configured as a singular network, such as a local area network, a wide area network, or another related network. Network 420 may be configured as a wired network (e.g., IEEE 802.3). Network 420 may be configured as a wireless network (e.g., IEEE 802.11). Network 420 may include multiple separate networks, such as networks 420-1 and 420-2 used for different MFA devices in system 400. For example, authenticator app 430 may communicate via network 420-1, and network 420-1 may be a cellular network. Continuing the example, target machine 440 may communicate via network 420-2, and network 420-2 may be a wired network. As a result, authenticator app 430 and target machine 440 may not communicate directly with each other during performance online MFA; for example, communication may be performed indirectly through authentication server 410.

[0052] Authenticator app 430 may be an application, service, software, hardware, or other combination running on a secondary computing device. Authenticator app 430 may be part of a computer system, such as a laptop PC, smartphone, tablet computer, or other related computer (e.g., computer system 100). Authenticator app 430 may be configured to provide an additional factor of online MFA operations to a user. For example, authenticator app 430 may receive a second factor from authentication server 410 and, in response, present the second factor through a display (not shown) for the user to provide to target machine 440. Authenticator app 430 may be configured to perform public key cryptography or asymmetric cryptography. For example, authenticator app 430 may include public key 432 and private key 434, and authenticator app 430 may provide public key 432 to another computing device for use in encrypting data that can later be decrypted using private key 434.

[0053] Target machine 440 may be a computer system, such as a server, laptop, desktop computer, or other secure computer system (e.g., a computer protected by a username and password). In addition to being protected by a first factor (e.g., a username and password), target machine 440 may be configured to perform one or more MFA techniques. Specifically, target machine 440 may receive a second factor (e.g., a second factor challenge) from authentication server 410, and target machine 440 may be configured to prompt (e.g., a user, a secondary computer) for the second factor. Target machine 440 may be configured to receive the second factor and compare it to authenticate access. In some embodiments, target machine 440 may be configured to receive the second factor and send it to authentication server 410 for verification. If authentication server 410 returns a success response to target machine 440, the second factor authenticated access may be successful. Target machine 440 may be configured to perform public key or asymmetric cryptography. For example, target machine 440 may include a public key 442 and a private key 444, and target machine 440 may provide public key 442 to other computing devices for use in encrypting data that may later be decrypted using private key 444. Public key 442 may also be used by other computing devices to verify data signatures, e.g., data cryptographically signed by target machine 440 using private key 444.

[0054] System 400 may also be configured to execute CRMFA to provide MFA during a network outage. In some embodiments, CRMFA may be executed without any user interaction. Specifically, system 400 may operate without prompting the user or without the user knowing that any information is being exchanged for offline MFA purposes. For example, various information may be exchanged for offline MFA while network 420 is fully operational.

[0055] FIG. 4A illustrates an example system 400 configured to perform multi-factor authentication during varying network availability, consistent with some embodiments of the present disclosure. During time interval 470, authenticator app 430 and target machine 440 may have network connectivity with authentication server 410. Time interval 470 may be a time period coinciding with active network communication, such as when target machine 440, authenticator app 430, or a combination thereof, sends (or receives) network packets to (or from) authentication server 410. Time interval 470 may be separate for each of multiple MFA devices. For example, time interval 470 may be initiated by target machine 440 communicating its availability to authentication server 410. Then, at a time after the initiation, authentication server 410 may send an online target status communication to authenticator app 430. For example, after receiving availability status from target machine 440, authentication server 410 may send online target status to authenticator app 430. During time interval 470, authenticator app 430 may also send public key 432 to authentication server 410; authentication server 410 may use public key 432 to generate an encrypted file that only authenticator app 430 can decrypt (e.g., using private key 434). During time interval 470, target machine 440 may send public key 442 to authentication server 410; authentication server 410 may use public key 442 to generate an encrypted file that only target machine 440 can decrypt (e.g., using private key 444).

[0056] The online MFA operation may be performed during time interval 470. For example, time interval 470 may begin with target machine 440 receiving a request for login (e.g., including receiving a username and password and verifying the username and password). In response to receiving the request, target machine 440 may be configured to send a second factor request to authentication server 410. In response to receiving the second factor request, authentication server 410 may send the second factor to target machine 440 and also to authenticator app 430.

[0057] During time interval 472, authentication server 410 may be configured to generate random values ​​and encrypt the random values. Specifically, authentication server 410 may be configured to generate a set of authenticator random values ​​450-1, 450-2, and up to 450-N (collectively, “authenticator random values ​​450”) and a set of one or more target random values ​​460-1, 460-2, and up to 460-N (collectively, “target random values ​​460”). In some embodiments, the random values ​​(e.g., authenticator random values ​​450 or target random values ​​460, or a combination thereof) may be in the form of a passphrase that may be memorable or important to the user. For example, authenticator random value 450-1 may be a passphrase, such as "David has two dogs Jinx and Whisper," "Leo-enjoys-security-puzzles," or "Philip|once|hiked|a|mountain," or another series of letters, numbers, characters, or words. Furthermore, authentication server 410 may be configured to encrypt the random value by generating an encrypted file containing the random value using one or more encryption algorithms. Specifically, authentication server 410 may be configured to generate a set of one or more authenticator encrypted files 452-1, 452-2, through 452-N (collectively, "authenticator encrypted files 452") and a set of one or more target encrypted files 462-1, 462-2, through 462-N (collectively, "target encrypted files 462").

[0058] The encrypted file may be in a predefined format (e.g., JavaScript Object Notation Web Token ("JWT")). The predefined format may include encrypted information (e.g., a payload) and unencrypted information. In FIGS. 4A-4G, encrypted portions may be indicated by dotted lines, and unencrypted portions may be indicated by solid lines.

[0059] Specifically, authenticator encrypted file 452 may include unencrypted header 454. Header 454 may include a unique identifier or index for identifying a particular authenticator encrypted file 452, e.g., authenticator encrypted file 452-1 may include header 454-1 with index "001," authenticator encrypted file 452-2 may include header 454-2 with index "002," etc. The encrypted portion of authenticator encrypted file 452 may include authenticator random value 450, e.g., authenticator encrypted file 452-1 may include authenticator random value 450-1, authenticator encrypted file 452-2 may include authenticator random value 450-2, etc. The encrypted portion may also include an expiration value, for example expiration value 456-1 encrypted in authenticator encrypted file 452-1.

[0060] Similarly, target encrypted file 462 may include an unencrypted header 464. Header 464 may include a unique identifier or index to identify a particular target encrypted file 462; for example, target encrypted file 462-1 may include header 464-1 with index "001," target encrypted file 462-2 may include header 464-2 with index "002," etc. Headers 464 may correspond to headers 454, such that a given header 464 has the same index or value as a given header 454. The encrypted portion of target encrypted file 462 may include target random value 460; for example, target encrypted file 462-1 may include target random value 460-1, target encrypted file 462-2 may include target random value 460-2, etc. The encrypted portion of target encrypted file 462 may also include an expiration value, e.g., expiration value 466-1 encrypted in authenticator encrypted file 452-1. The encrypted portion of target encrypted file 462 may also include target machine public key 442.

[0061] Authenticator encrypted file 452 and target encrypted file 462 may be encrypted using different encryption algorithms. For example, authenticator app 430 may be configured to decrypt only encrypted files encrypted using a first encryption algorithm, and target machine 440 may be configured to decrypt only encrypted files encrypted using a second encryption algorithm. Based on compatibility between authenticator app 430 and target machine 440, each authenticator encrypted file 452 may be encrypted using the first encryption algorithm, and each target encrypted file 462 may be encrypted using the second encryption algorithm.

[0062] Each of the encrypted files may be encrypted with a value. Specifically, each authenticator encrypted file 452 may be encrypted with authenticator public key 432. Furthermore, each target encrypted file 462 may be encrypted with a corresponding authenticator random value 450; for example, target encrypted file 462-1 may be encrypted with authenticator random value 450-1, target encrypted file 462-2 may be encrypted with authenticator random value 450-2, etc.

[0063] During time interval 474, the encrypted file may be transmitted to another MFA device. Time interval 474 may be part of time interval 472. Specifically, authentication server 410 may transmit authenticator encrypted file 452 generated during time interval 472 to authenticator app 430 over network 420-1. In some embodiments, authentication server 410 may transmit public key 442 of target machine 440 to authenticator app 430 over network 420-1. Furthermore, authentication server 410 may transmit target encrypted file 462 to target machine 440 over network 420-2.

[0064] 4B-4G may illustrate performance of multi-factor authentication other than network availability. For example, FIGS. 4B-4G may illustrate multi-factor authentication between authenticator app 430 and target machine 440 without communication with authentication server 410, e.g., during periods when network 420 is not operational or unavailable. 4B-4G may illustrate time intervals 480, 482, 484, 486, 488, and 490, which may be consecutive or contemporaneous (e.g., time interval 480 may occur before time interval 482, and time intervals 484 and 488 may occur partially or approximately contemporaneously).

[0065] 4B illustrates an example system 400 that performs multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. FIG. 4B illustrates a time interval 470, which may occur after, for example, authentication server 410 provides authenticator encrypted file 452 to authenticator app 430 and after authentication server 410 provides target encrypted file 462 to target machine 440. During time interval 480, target machine 440 may attempt to communicate with authentication server 410 and may fail, for example, due to a network outage or unavailability. During time interval 480, target machine 440 may attempt to communicate with authentication server 410 in response to receiving a valid login and password (or other valid first factor).

[0066] FIG. 4C illustrates an example system 400 for performing multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. During time interval 482, target machine 440 may provide a copy of target encrypted file 462-1 to authenticator app 430. In some embodiments, providing the copy of target encrypted file 462-1 may also include cryptographically signing the copy. For example, target machine 440 may cryptographically sign the copy of target encrypted file 462-1 with private key 444. In some embodiments, during time interval 482, target machine 440 may also provide a copy of target machine public key 442 to authenticator app 430. Providing by target machine 440 may be performed over a secondary network (not shown), such as a local network, wireless network, personal area network, or other associated network. Providing by target machine 440 may also be performed visually. For example, target machine 440 may include a display (not shown) capable of providing a graphical user interface (GUI) to a user. Target machine 440 may generate a machine-readable image (e.g., a barcode, a two-dimensional barcode, a matrix barcode, a quick response code) representing target encrypted file 462-1 or target machine public key 442, or a combination thereof. The machine-readable image may be displayed through the display of target machine 440 so that a secondary computer with an attached digital camera (not shown) running authenticator app 430 may capture target encrypted file 462-1 or target machine public key 442, or a combination thereof.

[0067] 4D illustrates an example system 400 for performing multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. During time interval 484, authenticator app 430 may decrypt authenticator encrypted file 452-1 using authenticator private key 434. Authenticator app 430 may select authenticator encrypted file 452-1 for decryption based on the received target encrypted file 462-1. For example, authenticator app 430 may identify an index value in header 464-1 in target encrypted file 462-1 and match the index value with a corresponding index value in header 454-1 in authenticator encrypted file 452-1. In response to decrypting authenticator encrypted file 452-1, authenticator app 430 may have access to authenticator random value 450-1 and expiration value 456-1. The authenticator app 430 may be configured to determine whether the authenticator encrypted file 452-1 has expired by comparing the expiration value 456-1 to a time value (e.g., the system time of the computer system executing the authenticator app 430). If the expiration value 456-1 is less than the time value, the authenticator app 430 may continue the CRMFA. If the expiration value 456-1 is equal to or greater than the time value, the authenticator app 430 may not continue the CRMFA. If the expiration value 456-1 is equal to or greater than the time value, the authenticator app 430 may request a new target encrypted file 462 from the target machine 440.

[0068] 4E illustrates an example system 400 that performs multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. During time interval 486, authenticator app 430 may use authenticator random value 450-1 to decrypt target encrypted file 462-1. Additionally, authenticator app 430 may verify target encrypted file 462-1. Specifically, authenticator app 430 may compare target machine public key 442 received during time interval 482 with target machine public key 442 decrypted during time interval 486 (e.g., if the target public keys match, authenticator app 430 may determine that target encrypted file 462-1 has not been modified since it was provided by authentication server 410). In some embodiments, authenticator app 430 may verify target encrypted file 462-1 using a digital signature algorithm (e.g., RSA, DSA). For example, authenticator app 430 may be configured to perform cryptographic verification of target encrypted file 462-1 using public key 442 received from authentication server 410. In response to decrypting target encrypted file 462-1, authenticator app 430 may have access to target random value 460-1.

[0069] FIG. 4F illustrates an example system 400 that performs multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. During time interval 488, authenticator app 430 may provide random values ​​to target machine 440. Specifically, authenticator app 430 may directly transmit authenticator random value 450-1 and target random value 460-1 to target machine 440. For example, authenticator app 430 may establish a network connection, such as a wireless network connection, with target machine 440 for the transmission of the random values. Authenticator app 430 may indirectly provide authenticator random value 450-1 and target random value 460-1 to target machine 440. Specifically, authenticator app 430 may run on a user's client device (e.g., a smartphone). Authenticator app 430 may render both authenticator random value 450-1 and target random value 460-1 on the client device's display (not shown), and the user may read the client device's display and enter authenticator random value 450-1 and target random value 460-1 into a target machine's 440 keyboard (not shown).

[0070] FIG. 4G illustrates an example system 400 for performing multi-factor authentication other than network availability, consistent with some embodiments of the present disclosure. During time interval 490, target machine 440 may use authenticator random value 450-1 to decrypt target encrypted file 462-1. The target machine may use the decrypted target encrypted file 462-1 to obtain expiration value 466-1 and determine whether target encrypted file 462-1 has expired (e.g., whether expiration value 466-1 is a date / timestamp earlier than the current time). If target encrypted file 462-1 has not expired, target machine 440 may authenticate the second factor by comparing a provided version of target random value 460-1 (provided by authenticator app 430) with the decrypted version of target random value 460-1. If the provided version of target random value 460-1 and the decrypted version of target random value 460-1 match, target machine 440 may verify the login request and, as a result, unlock target machine 440 (e.g., allow the login request).

[0071] 5 illustrates an example method 500 of multi-factor authentication by an authentication server consistent with some embodiments of the present disclosure. Method 500 may generally be implemented with fixed-function hardware, configurable logic, logic instructions, etc., or any combination thereof. For example, the logic instructions may include assembler instructions, ISA instructions, machine instructions, machine-dependent instructions, microcode, state setting data, configuration data for an integrated circuit, state information for personalizing an electronic circuit, or other structural components specific to hardware (e.g., a host processor, central processing unit / CPU, microcontroller, etc.), or combinations thereof. Method 500 may be performed by an authentication server, such as authentication server 410.

[0072] Starting at step 505, an authenticator payload may be obtained at step 510. The authenticator payload may be obtained by receiving an authenticator random value from a random number generator. The authenticator payload may be obtained by directly generating a random value. The authenticator payload may be obtained by appending another value to the authenticator random value, such as an expiration value. In some embodiments, multiple authenticator payloads may be obtained, where each payload has a different authenticator random value. The authenticator payload may be obtained in response to receiving a request for performing online MFA, such as receiving a request for a second factor from an authenticator app or a target machine, or a combination thereof.

[0073] In step 520, an authenticator encrypted file may be generated. The authenticator encrypted file may be generated by executing an encryption algorithm, such as a hash algorithm. The authenticator payload may be provided as input to the encryption algorithm. As a result, the authenticator encrypted file may include the authenticator payload. The authenticator payload may be encrypted using a public key algorithm. Specifically, the authenticator payload may be encrypted with a public key and may be decryptable with a corresponding private key. The public key may be associated with an authenticator application (e.g., the public key of the authenticator application and decryptable by a corresponding private key possessed by the authenticator application). In some embodiments, multiple authenticator encrypted files may be generated, with each authenticator encrypted file for encrypting a different authenticator payload.

[0074] At step 530, a target payload may be obtained. The target payload may be obtained by receiving a target random value from a random number generator. The target payload may be obtained by directly generating a random value. In some embodiments, multiple target payloads may be obtained, each payload having a different target random value. The target payload may be obtained by appending another value to the target random value, such as an expiration value. The expiration value appended to the target random value may be the same as the expiration value appended to the authenticator random value. The target payload may be obtained in response to receiving a request for online MFA execution, such as receiving a request for a second factor from an authenticator app, a target machine, or a combination thereof.

[0075] In step 540, a target encrypted file may be generated. The target encrypted file may be generated by executing an encryption algorithm, such as a hash algorithm. The encryption algorithm that is part of the generation in step 540 may be the same as the encryption algorithm that was part of the generation in step 520. The target payload may be provided as input to the encryption algorithm. As a result, the target encrypted file may include the target payload. The target payload may be encrypted using the random value obtained in step 510. For example, the target encrypted file may be encrypted using an authenticator random value. In some embodiments, multiple target encrypted files may be generated, where each target encrypted file is for encrypting a different target payload.

[0076] At step 550, a network connection may be identified. The network connection may be from an authenticator application, such as a cellular network that receives a request from a client device to connect to the authenticator network (e.g., an authenticator network connection). The network connection may be from a target machine, such as a network that receives a request from the target machine to connect to the target network (e.g., a target network connection). The network connection may facilitate communication between an authentication server and one or more other MFA devices (e.g., an authenticator app, a target machine). The network connection may be concurrent with other network connections, such as while another network connection with another MFA device is active. If the network connection is identified (“Yes” at step 550), an encrypted file may be transmitted at step 560. After transmitting the encrypted file, method 500 may continue at step 560 by monitoring to identify network connections. If there is no identified network connection (“NO” at step 550 ), method 500 may end at step 595 .

[0077] 6 illustrates an exemplary method 600 of multi-factor authentication by a target machine consistent with some embodiments of the present disclosure. Method 600 may generally be implemented with fixed-function hardware, configurable logic, logic instructions, etc., or any combination thereof. For example, the logic instructions may include assembler instructions, ISA instructions, machine instructions, machine-dependent instructions, microcode, state setting data, configuration data for an integrated circuit, state information for personalizing electronic circuitry, or other structural components specific to hardware (e.g., a host processor, a central processing unit / CPU, a microcontroller, etc.), or a combination thereof. Method 600 may be executed by a target machine, such as target machine 440.

[0078] Starting at step 605, a login request may be received at step 610. The login request may include a first element, such as an identifier and a password. The login request may be from a user, such as the user entering a username and password into a login prompt provided by the target machine. The login request may also be from a secondary computer. For example, a smartphone may operate by sending an access request to the target machine over a local area network or a personal area network. The first element may be verified, such as by verifying the username and password.

[0079] In step 620, a network failure may be determined. The network failure may be the target machine's inability to communicate with the authentication server. Specifically, the target machine may attempt to connect to the authentication server. For example, the target machine may attempt to establish a network connection with the authentication server in response to the login request to request a second factor to perform an online MFA operation. The network failure may be the target machine not receiving a response from the authentication server, for example, the authentication server being temporarily offline. The network failure may be the target machine's inability to send a communication to the authentication server, for example, the target machine not having network access or the target machine being unable to send network packets to the authentication server.

[0080] If there is no network failure ("NO" at step 630), method 600 may end at step 695. If there is a network failure ("YES" at step 630), method 600 may continue at step 640 by providing a target encrypted file copy to an authenticator application. Providing the copy of the target encrypted file may include establishing a network connection with a client app (e.g., an authenticator app) running on a secondary client device (e.g., a user's laptop computer). Providing the copy of the target encrypted file may include transmitting the copy over a local area network (e.g., a Wi-Fi connection, a Bluetooth connection) that was the source of the access or login request, or a combination thereof. Providing the copy of the target encrypted file may include selecting a target encrypted file from a set of target encrypted files stored on the target machine. The selection may be based on an unencrypted portion, such as an index, of the target encrypted file. Providing the target encrypted file copy may include providing a target machine public key (e.g., the target machine public key provided to another computing device to perform public key encrypted communications). Providing the target encrypted file copy to an authenticator application may include rendering a quick response code (or other visual representation) of the target encrypted file for easy capture by a client computer operating the authenticator application.

[0081] At step 650, the target machine may monitor for a response. Monitoring for a response may be through a network connection with the authenticator app. Monitoring for a response may include monitoring for input from an input device of the target machine (e.g., mouse movements, keyboard keystrokes, touchscreen input). Monitoring for a response may include monitoring for a response that includes random values, such as an authenticator random value and a target random value. The type of response may be predetermined based on a CRMFA application programming interface (API). For example, a first API may specify that a first string or series of values ​​is the authenticator random value and that a second string or series of values ​​is the target random value. The first API may also specify that a predetermined character or string is used as a delimiter, such as a period or comma. The first API may also specify specific character lengths to be used for the various random values. If a response that does not include a random value is received ("No" at step 660), method 600 may end at step 695.

[0082] If a response including a random value is received (“Yes” at step 660), method 600 may continue at step 670 by performing a decryption operation. The decryption operation may be performed using a random value (e.g., an authenticator random value) received from the authenticator app. The decryption operation may be performed on a target encrypted file. A payload (target payload) of the target encrypted file may be obtained based on performing the decryption operation. The target payload may include the target random value. At step 680, a verification operation may be performed. The verification operation may include comparing the received target random value with the target random value encrypted in the target encrypted file. The verification operation may also include unlocking the target machine. Specifically, unlocking the target machine based on the two copies of the target random value being the same. After performing the verification operation at step 680, method 600 may end at step 695.

[0083] 7 illustrates an example method 700 of multi-factor authentication by an authentication application consistent with some embodiments of the present disclosure. Method 700 may generally be implemented with fixed-function hardware, configurable logic, logic instructions, etc., or any combination thereof. For example, the logic instructions may include assembler instructions, ISA instructions, machine instructions, machine-dependent instructions, microcode, state setting data, configuration data for an integrated circuit, state information for personalizing electronic circuitry, or other structural components specific to hardware (e.g., a host processor, a central processing unit / CPU, a microcontroller, etc.), or a combination thereof. Method 700 may be performed by a client device, particularly by an application configured to perform authentication, such as a CRMFA (e.g., authenticator app 430).

[0084] Starting at step 705, at step 710, an encrypted file copy (hereinafter "file copy") may be received by an authenticator app. For example, a target machine may send the file copy to a client device configured to run the authenticator app in response to a login request. The file copy may be received over a network. For example, the file copy may be sent over a network connection between the target machine and the authenticator app. The file copy may also be received without a network connection. For example, the bits of data that make up the encrypted file copy may be rendered by a display of the target machine, and a camera communicatively connected to the client device may capture the bits of data.

[0085] At step 720, the authenticator encrypted file may be decrypted. Specifically, a decryption algorithm may be used to decrypt the authenticator encrypted file stored by the client device executing the authenticator app. The authenticator encrypted file may be decrypted using public key decryption (e.g., the decryption algorithm may use a private key stored by the authenticator app). The authenticator encrypted file may be decrypted to determine an authenticator random value for use in decrypting the received file copy. Specifically, the authenticator encrypted file may contain the authenticator random value used by the authentication server to encrypt the target encrypted file (and consequently, the target encrypted file copy). If an authenticator random value cannot be determined ("No" at step 730), method 700 may end at step 795.

[0086] If the authenticator random value is determined (“YES” at step 730), the file copy may be decrypted at step 740. Specifically, a decryption operation may be performed to successfully decrypt the target encrypted file copy. The key for the target encrypted file copy may be the authenticator random value, and the authenticator app may utilize a decryption algorithm by providing the target encrypted file copy and the authenticator random value as inputs to the decryption algorithm. The decryption of the file copy may include determining a target random value. Specifically, a target payload including a target random value may be obtained based on decrypting the target encrypted file copy. If the target random value is not determined (“NO” at step 750), method 700 may end at step 795.

[0087] If the target random value is determined (“Yes” at step 750), method 700 may continue at step 760 by providing a random value to the target machine. Providing the random value may include generating a string or other data structure. Specifically, the predefined API may specify a particular data structure or other associated format for presenting the random value. For example, given an authenticator random value of “3470234” and a target random value of “HE0O923N,” the value “3470234.HE0O923N” may be a compliant format for providing to the target machine. Providing the random value may include providing the random value to a user, e.g., displaying the random value on a display of the client device running the authenticator app. Providing the random value may include sending two separate messages in a predefined order. For example, the target machine and authenticator application may agree on a network communication scheme that specifies a first network transmission containing the authenticator random value and a second network transmission containing the target random value, or vice versa. After the random value is provided by the authenticator app in step 760, method 700 may end at step 795.

[0088] The present invention may be a system, method, computer program product, or computer program, or any combination thereof, at any level of technical detail that may be integrated. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0089] The computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction-execution device. The computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette 登録商標 , hard disk, random access memory (RAM), read only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device such as punch cards or raised structures in grooves in which instructions are recorded, or any suitable combination thereof. As used herein, computer-readable storage medium should not be interpreted as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over electrical wires.

[0090] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to an individual computing device / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may be comprised of copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing device / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to the individual computing device / processing device for storage in a computer-readable storage medium.

[0091] Computer-readable program instructions for carrying out operations of the present invention may be either assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, such as object-oriented programming languages, e.g., Smalltalk, C++, etc., or conventional procedural programming languages ​​(e.g., the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any kind of network, such as a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., over the Internet using an Internet Service Provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the invention.

[0092] Aspects of the present invention are described herein with reference to flowchart illustrations or block diagrams of methods, apparatus (systems), and computer program products or computer programs, or combinations thereof, according to embodiments of the invention. It will be understood that each block of the flowchart illustrations or block diagrams or combinations thereof, and combinations of blocks in the flowchart illustrations or block diagrams or combinations thereof, can be implemented by computer-readable program instructions.

[0093] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowchart diagrams or the block diagrams, or a combination thereof, to produce a machine. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer-programmable data processing apparatus or other device, or a combination thereof, to function in a particular manner, such that a computer-readable storage medium having stored instructions includes an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowchart diagrams or the block diagrams, or a combination thereof.

[0094] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on a computer, other programmable data processing apparatus, or other device, implement the functions / acts identified in one or more blocks of the flowchart diagrams or block diagrams, or a combination thereof, to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process.

[0095] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products or computer programs according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing one or more specified logical functions. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be accomplished as a single step performed simultaneously, substantially simultaneously, partially, or fully in a time-overlapping manner, depending on the functionality involved, or the blocks may be performed in the reverse order. It should be noted that each block of the block diagrams or flowchart diagrams or combinations thereof, and combinations of multiple blocks in the block diagrams or flowchart diagrams or combinations thereof, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations, or may execute a combination of special-purpose hardware and computer instructions.

[0096] The description of various embodiments of the present disclosure has been presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used in this specification have been selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. obtaining a first authenticator payload including a first authenticator random value; generating a first authenticator encrypted file using a first encryption algorithm with the authenticator public key as an encryption key, wherein the first authenticator encrypted file includes the first authenticator payload, and the authenticator public key is associated with a client authenticator application; obtaining a first target payload including a first target random value; and generating a first target encrypted file based on a second encryption algorithm and using the first authenticator random value, wherein the first target encrypted file includes the first target payload; the client authenticator application is configured to decrypt the first authenticator encrypted file with a private key corresponding to the authenticator public key to obtain the first authenticator random value, and to unlock the first target encrypted file using the obtained first authenticator random value; method.

2. identifying, by an authentication server, an authenticator network connection with the client authenticator application; transmitting, by the authentication server, the first authenticator encrypted file to the client authenticator application in response to the authenticator network connection; Identifying a target network connection with a target machine by the authentication server; and transmitting, by the authentication server, the first target encrypted file to the target machine in response to the target network connection; The method of claim 1 further comprising:

3. The method of claim 2 , wherein the target network connection is identified simultaneously with the identifying of the authenticator network connection.

4. receiving, by the target machine, a login request; wherein the login request includes a valid identifier; and The login request includes a valid password; determining, by the target machine, a network failure, wherein the network failure comprises the target machine being unable to communicate with the authentication server; and providing a first copy of the first target encrypted file to the client authenticator application by the target machine; The method of claim 2 further comprising:

5. the first target encrypted file includes a first target machine public key copy of a target machine public key, and providing the first copy of the first target encrypted file providing, by the target machine, a second target machine public key copy of the target machine public key to the client authenticator application; Including, wherein, in response to decrypting the first target encrypted file, the client authenticator application is configured to compare the first target machine public key copy of a target machine public key with a second target machine public key copy of the target machine public key. The method of claim 4.

6. receiving, by the client authenticator application, the first copy of the first target encrypted file; performing, by the client authenticator application, a first decryption operation on a first authenticator encrypted file based on an authenticator private key, wherein the authenticator private key corresponds to the authenticator public key; determining, by the client authenticator application, the first authenticator random value based on the first decryption operation; performing, by the client authenticator application, a second decryption operation on the first copy of the first target encrypted file based on the first authenticator random value; determining, by the client authenticator application, the first target random value for the first copy of the target encrypted file based on the second decryption operation; and preparing, by the client authenticator application, the first authenticator random value and the first target random value for the first copy of the first target encrypted file; The method of claim 4 further comprising:

7. the client authenticator application comprising a screen configured to display information to a user, wherein providing the first authenticator random value and the first target random value comprises: displaying the first authenticator random value and the first target random value by the screen; Including, The method of claim 6.

8. receiving, by the target machine, the first authenticator random value and the first target random value of the first copy of the first target encrypted file from the client authenticator application; performing, by the target machine, a third decryption operation on the first target encrypted file based on the first authenticator random value; determining, by the target machine, the first target random value of the first target encrypted file based on the third decryption operation; and performing a verify operation by the target machine by comparing the first target random value of the first target encrypted file with the first target random value of the first copy of the first target encrypted file. The method of claim 6 further comprising:

9. the verifying operation includes determining that the first target random value of the first target encrypted file matches a first target random value of the first copy of the first target encrypted file, the method comprising: unlocking the target machine by the target machine based on the login request and based on the verification operation; Including, The method of claim 8.

10. the first target encrypted file includes a first expiration value, and the verifying operation determining, by the target machine, an expiration status of the first target encrypted file based on the first expiration value; Including, The method of claim 8.

11. 11. The method of claim 10, wherein the first expiration value is part of the first target payload, and determining the expiration status of the first target encrypted file occurs after the third decryption operation.

12. The method described in claim 1, wherein unlocking the first target encrypted file is performed when there is no network connection between the client authenticator application and a target machine having the first target encrypted file.

13. 10. The method of claim 1, wherein obtaining the first authenticator payload is in response to receiving a request for online multi-factor authentication from a target machine.

14. 14. The method of claim 13, further comprising communicating the first authenticator encrypted file to the client authenticator application by an authentication server.

15. obtaining a second authenticator payload including a second authenticator random value; generating a second authenticator encrypted file based on the second encryption algorithm and using the authenticator public key, wherein the second authenticator encrypted file includes the second authenticator payload; obtaining a second target payload including a second target random value; and generating a second target encrypted file based on the second encryption algorithm and using the second authenticator random value, wherein the second target encrypted file includes the second target payload; The method of claim 1 further comprising:

16. identifying, by an authentication server, an authenticator network connection with the client authenticator application; transmitting, by the authentication server, the first authenticator encrypted file and the second authenticator encrypted file to the client authenticator application in response to the authenticator network connection; identifying a target network connection with a target machine by said authentication server; and transmitting, by the authentication server, the first target encrypted file and the second target encrypted file to the target machine in response to the target network connection.

16. The method of claim 15, further comprising:

17. 1. A system comprising: a memory containing one or more instructions; and a processor communicatively coupled to the memory wherein the processor, in response to reading the one or more instructions, obtaining a first authenticator payload including a first authenticator random value; generating a first authenticator encrypted file using a first encryption algorithm with the authenticator public key as an encryption key, wherein the first authenticator encrypted file includes the first authenticator payload, and the authenticator public key is associated with a client authenticator application; obtaining a first target payload including a first target random value; and generating a first target encrypted file based on a second encryption algorithm and using the first authenticator random value, wherein the first target encrypted file includes the first target payload; It is structured as follows: the client authenticator application is configured to decrypt the first authenticator encrypted file with a private key corresponding to the authenticator public key to obtain the first authenticator random value, and to unlock the first target encrypted file using the obtained first authenticator random value; The system.

18. 20. The system of claim 17, wherein obtaining the first authenticator payload is in response to receiving a request for online multi-factor authentication from a target machine.

19. A computer program comprising: obtaining a first authenticator payload including a first authenticator random value; generating a first authenticator encrypted file using a first encryption algorithm with the authenticator public key as an encryption key, wherein the first authenticator encrypted file includes the first authenticator payload, and the authenticator public key is associated with a client authenticator application; obtaining a first target payload including a first target random value; and generating a first target encrypted file based on a second encryption algorithm and using the first authenticator random value, wherein the first target encrypted file includes the first target payload; causing a computer to execute each step of the method, the client authenticator application is configured to decrypt the first authenticator encrypted file with a private key corresponding to the authenticator public key to obtain the first authenticator random value, and to unlock the first target encrypted file using the obtained first authenticator random value; The computer program.

20. 20. The computer program product of claim 19, wherein obtaining the first authenticator payload is in response to receiving a request for online multi-factor authentication from a target machine.

Images