Multi-factor authentication device scheduling method and system under linux

Abstract

The application discloses a Linux full-scene multi-factor authentication device scheduling method and system, and belongs to the technical field of multi-factor authentication device scheduling.The application comprises the following steps: when a multi-factor authentication service receives an authentication request initiated by an application to a PAM framework, distinguishing whether the current belongs to a graphic scene or a non-graphic scene through a service attribute value of the PAM framework; according to the distinguishing result of whether the current belongs to the graphic scene or the non-graphic scene, executing a corresponding authentication device interaction mode, including: when the current belongs to the non-graphic scene, adopting a text interaction mode to guide a user to complete multi-factor authentication device authentication through man-machine interaction; when the current belongs to the graphic scene, adopting a special instruction interaction mode to guide the user to complete the multi-factor authentication device authentication through man-machine interaction.The application aims to realize full-scene multi-factor authentication device scheduling, has high compatibility with third-party applications with authentication requirements, does not need to be modified, and supports flexible configuration.

Description

Technical Field

[0001] This invention relates to security authentication technology in the field of desktop operating systems, specifically to a multi-factor authentication device scheduling method and system under Linux for all scenarios. Background Technology

[0002] With the accelerated pace of digital transformation, businesses and individuals are increasingly reliant on online services and digital tools in their daily lives. However, the frequent occurrence of cybercrime has made security issues increasingly serious, and traditional single-password authentication methods are no longer sufficient to cope with complex and ever-changing cyberattacks. Hackers easily steal sensitive information through brute-force attacks, phishing attacks, and other methods, causing huge financial and reputational losses to businesses and individuals. In this context, Multi-Factor Authentication (MFA) has become a key means to improve security. MFA effectively reduces the risk of unauthorized access by introducing additional verification factors, typically including knowledge factors (such as passwords), ownership factors (such as mobile phones, tokens), and biometric factors (such as fingerprints, facial recognition). Even if the password is leaked, attackers still need to go through additional verification steps, significantly increasing the difficulty of intrusion. Linux systems are mainly used in servers, cloud computing, and other fields, generally adopting a non-graphical installation mode. The authentication framework uses the PAM (Pluggable Authentication Module) framework. The data communication method of the PAM framework is relatively simple, only supporting text-based interaction, resulting in a poor user experience on graphically installed operating systems. Linux systems may trigger authentication operations in various scenarios, including login, screen locking, privilege escalation, third-party applications, and non-graphical applications. However, physical authentication devices cannot execute authentication requests concurrently, leading to device preemption issues. Furthermore, Linux lacks a unified protocol standard for multi-factor authentication. Different hardware manufacturers typically provide corresponding device drivers, and these drivers offer varying operational interfaces. Therefore, most commercially available products only support two-factor authentication—the system's default password authentication and the device driver's authentication function—and cannot flexibly add support for other authentication devices. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a multi-factor authentication device scheduling method and system under Linux for all scenarios, addressing the aforementioned problems of the prior art. This invention aims to achieve multi-factor authentication device scheduling for all scenarios, has high compatibility with third-party applications with authentication requirements, requires no modification, and supports flexible configuration.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0005] A multi-factor authentication device scheduling method under Linux for all scenarios includes the following steps: When the multi-factor authentication service receives an authentication request initiated by an application to the PAM framework, it distinguishes between a graphical or non-graphical scenario based on the PAM_SERVICE attribute value of the PAM framework; according to the distinction between a graphical and non-graphical scenario, it executes the corresponding authentication device interaction mode, including using a text interaction mode for human-computer interaction to guide the user to complete the authentication of the multi-factor authentication device when the current scenario is non-graphical; and using a special command interaction mode for human-computer interaction to guide the user to complete the authentication of the multi-factor authentication device when the current scenario is graphical, wherein the special command interaction mode uses commands and data of a specified format to realize data interaction between the PAM framework and the application that initiated the authentication request.

[0006] Optionally, when the PAM framework and the application initiating the authentication request interact through instructions and data in a specified format, the instructions and data in the specified format include three types of instructions: "authentication mode", "whether to bind user", and "authentication type". The "authentication mode" is used to specify whether the logical relationship between multiple authentication types is "AND" or "OR". The "whether to bind user" is used to determine whether an account name needs to be selected first. The "authentication type" is used to specify the required authentication method, which includes some or all of the following: password, fingerprint, finger vein, face, UKey, and iris.

[0007] Optionally, the special instruction interaction mode enables data interaction between the PAM framework and the application initiating the authentication request through instructions and data in a specified format, including: first, determining whether "user binding" requires selecting an account name first; if so, displaying the user interface to obtain the user's selected account name; then, generating a corresponding authentication program based on the authentication method specified in "authentication type" to guide the user through authentication; and then performing corresponding logical operations on all authentication results according to "authentication mode" to obtain the final authentication result as either successful or unsuccessful.

[0008] Optionally, when the multi-factor authentication service receives an authentication request from an application to the PAM framework, it also includes creating a unique and priority-based session ID for the session of the application that initiated the authentication request, and avoiding the problem of authentication device preemption by maintaining a request pool. Newly created authentication requests will be placed into the request pool for unified management.

[0009] Optionally, the strategy of placing all newly created authentication requests into a request pool for unified management includes: comparing the priority of the newly created authentication request with the priority of the current request in the request pool; if the priority of the newly created authentication request is higher than the priority of the current request in the request pool, then the current request in the request pool is suspended, and the newly created authentication request is used as the new current request in the request pool to occupy authentication device resources, and the suspended authentication request is resumed after the new current request is served; if the current request in the request pool still has not completed the authentication operation after a set time, then the current request in the request pool is removed from the request pool and the authentication device is released. The system processes and returns error information to the multi-factor authentication service. If the current authentication request is successful, it returns the final authentication result to the multi-factor authentication service and releases the authentication device resources corresponding to the current request. If the multi-factor authentication service is detected to have exited abnormally, the corresponding session and authentication request are closed. If the authentication request is currently in progress, the authentication device resources corresponding to the authentication request are released. If the application is detected to be suspended, the authentication request corresponding to the application is put back into the request pool and the authentication device resources are released. After the current request ends normally or exits abnormally, the system selects the highest priority authentication request that is not suspended from the request pool as the new current request.

[0010] Optionally, it also includes using a multi-factor authentication device service to provide an API abstraction layer for the multi-factor authentication service, through which different authentication device driver interfaces are transformed into a unified interface to achieve unified management of multiple authentication devices.

[0011] Optionally, when different authentication device driver interfaces are transformed into a unified interface through the API abstraction layer to achieve unified management of multiple authentication devices, the unified interface includes the following three interfaces: Start Authentication: The input data of this interface is a JSON string, used to send customized data for different authentication devices to start authentication; Authentication Status Signal: This signal contains a feature ID, status, and message, where the feature ID is the identifier of the feature data recognized by the authentication device. If the feature ID is the same as the feature ID recorded by the user, the authentication is successful; otherwise, the authentication fails; the status includes device idle, device busy, device verifying, device identifying, device disabled, etc., and the message is a readable description of the status; Stop Authentication: Used to release authentication device resources.

[0012] In addition, the present invention provides a multi-factor authentication device scheduling system for all scenarios under Linux, including a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the multi-factor authentication device scheduling method for all scenarios under Linux.

[0013] In addition, the present invention provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the Linux-based multi-factor authentication device scheduling method under all scenarios via a processor.

[0014] In addition, the present invention also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the Linux full-scenario multi-factor authentication device scheduling method via a processor.

[0015] Compared with existing technologies, this invention has the following main advantages: When the multi-factor authentication service receives an authentication request from an application to the PAM framework, it distinguishes between a graphical and non-graphical scenario based on the service attribute values ​​of the PAM framework. Based on this distinction, it executes the corresponding authentication device interaction method. Specifically, in a non-graphical scenario, it uses a text-based interaction mode to guide the user through the multi-factor authentication device authentication; in a graphical scenario, it uses a special command interaction mode to guide the user through the multi-factor authentication device authentication. This invention improves the user experience for authentication needs in multiple scenarios, various authentication devices, and multi-session authentication under Linux. Its advantages include: 1) High compatibility with third-party applications requiring authentication under Linux, requiring no modification. 2) Flexible configuration is supported for various authentication scenarios. 3) For authentication scheduling of exclusive devices, scheduling can be performed based on the session to which the authentication request belongs and the type of authentication request. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0017] Figure 2 This is a schematic diagram of the scheduling strategy for the request pool in an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram illustrating the working principle of the Multi-Factor Authentication Device Service (MFA Authentication Device Service) in an embodiment of the present invention.

[0019] Figure 4 This is a schematic diagram of the overall layered architecture in an embodiment of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solution of the present invention, the technical solution of the present invention will be further described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0021] like Figure 1As shown, the multi-factor authentication device scheduling method under Linux in this embodiment includes the following steps: When the multi-factor authentication service receives an authentication request initiated by an application to the PAM framework, it distinguishes between a graphical or non-graphical scenario based on the PAM_SERVICE attribute value of the PAM framework; according to the distinction between a graphical and non-graphical scenario, it executes the corresponding authentication device interaction method, including using a text interaction mode for human-computer interaction to guide the user to complete the authentication of the multi-factor authentication device when the current scenario is non-graphical; and using a special command interaction mode for human-computer interaction to guide the user to complete the authentication of the multi-factor authentication device when the current scenario is graphical. In the special command interaction mode, data interaction between the PAM framework and the application initiating the authentication request is achieved through specified format commands and data. This multi-factor authentication device scheduling method under Linux in this embodiment, through the above steps, can solve the problem of poor performance in graphical scenarios while being compatible with non-graphical scenarios. Graphical scenarios include login, screen lock, privilege escalation, and third-party graphical applications, while non-graphical scenarios include sudo and login.

[0022] This embodiment uses the Multi-Factor Authentication (MFA) service, a PAM module, to address the multi-scenario problem. It consists of three stages: scenario differentiation, request-response, and human-computer interaction. In the scenario differentiation stage, the PAM_SERVICE attribute value provided by the PAM framework is used to distinguish between graphical and non-graphical scenarios. Commonly used attribute values ​​are as follows:

[0023] lightdm: Launcher (graphical scene);

[0024] screensaver: Lock screen interface (graphical scene);

[0025] polkit-1: Privilege Escalation Interface (Graphical Scene);

[0026] Sudo: Switch to another user (non-graphical scenarios);

[0027] login: Login program (non-graphical scenario).

[0028] In the request-response phase, for non-graphical scenarios, a traditional text-based response is used. For example, for UKey device authentication, if the UKey device is not detected as inserted, the response is "Please insert the UKey device"; if the UKey device is detected as inserted, the response is "Authenticating UKey, please enter the PIN code." This text information is directly displayed on the screen as a human-computer interaction prompt. For graphical scenarios, human-computer interaction should be conducted using a combination of icons, animations, or text. Text information should not be directly displayed to the user. To allow the requester to better parse or understand the response data, a message header + JSON data format is used. The message header is a special verification identifier, mainly to indicate to the requester that subsequent data is not text data and needs to be parsed according to JSON format. The JSON format mainly contains instructions and data. This embodiment implements data interaction between the PAM framework and the application initiating the authentication request through specified format instructions and data. The specified format instructions and data include three types of instructions: "Authentication Mode", "Whether to Bind User", and "Authentication Type". Among them, "Authentication Mode" REQ_CMD_NOTIFY_AUTH_MODE: is used to specify whether the logical relationship between multiple authentication types is "AND" or "OR". In AND mode, all authentication types need to pass, while in OR mode, only one authentication method needs to be activated. "Whether to Bind User" REQ_CMD_AUTH_SWITCHABLE: is used to determine whether an account name needs to be selected first. "Authentication Type" REQ_CMD_NOTIFY_AUTH_TYPE: is used to specify the required authentication method, which includes some or all of the following: password, fingerprint, finger vein, face, UKey, and iris scan.

[0029] During the human-computer interaction phase, the receiver (graphical program) should present different human-computer interaction methods based on the response data. "Authentication Mode" (REQ_CMD_NOTIFY_AUTH_MODE): In AND mode, only the interactive icon, image, or animation corresponding to the current authentication type should be displayed; in OR mode, the supported authentication types should be displayed in a certain order for the user to choose from. "User Binding" (REQ_CMD_AUTH_SWITCHABLE): If not enabled, the authentication interface is displayed directly; if enabled, the user selection interface is displayed. "Authentication Type" (REQ_CMD_NOTIFY_AUTH_TYPE): Different images or animations are displayed to prompt different authentication types. For example, a fingerprint icon can be displayed for fingerprint authentication; a user's avatar can be captured and displayed dynamically in real time for facial authentication. In this embodiment, the PAM framework and the application initiating the authentication request can interact via specified format instructions and data under the special instruction interaction mode. This includes: first, determining whether "user binding" requires selecting an account name first; if so, displaying the user interface to obtain the user's selected account name; then, generating the corresponding authentication program based on the authentication method specified in "authentication type" to guide the user through authentication; and then performing corresponding logical operations on all authentication results according to "authentication mode" to obtain the final authentication result as either successful or unsuccessful.

[0030] Linux is a multi-tasking scheduling system. To address the issue of physical authentication devices being preempted when multiple authentication requests occur concurrently, this embodiment, upon receiving an authentication request from an application to the PAM framework, further includes creating a unique and prioritized session ID for the application's session. A request pool is maintained to mitigate authentication device preemption; newly created authentication requests are placed in this pool for unified management. This embodiment assigns a unique session ID for identification each time authentication begins. Since a system may run multiple sessions simultaneously, each session may require temporary access to authentication device resources for authentication operations. This embodiment provides an MFA authentication service module that receives authentication requests from the MFA PAM module and creates a unique session ID upon request initiation.

[0031] like Figure 2As shown, the strategy for unified management of newly created authentication requests in this embodiment includes: comparing the priority of the newly created authentication request with the priority of the current request in the request pool; if the priority of the newly created authentication request is higher than the priority of the current request in the request pool, the current request in the request pool is suspended, and the newly created authentication request is used as the new current request in the request pool to occupy authentication device resources, and the suspended authentication request is resumed after the new current request is completed; if the current request in the request pool has not completed the authentication operation after a set time, the current request in the request pool is removed from the request pool, the authentication device resources are released, and an error message is returned to the multi-factor authentication service; if the current request authentication is completed, the final authentication result is returned to the multi-factor authentication service, and the authentication device resources corresponding to the current request are released; if the multi-factor authentication service is detected to have exited abnormally, the corresponding session and authentication request are closed; if the authentication request is a currently in progress, the authentication device resources corresponding to the authentication request are released; if the application is detected to be suspended (e.g., the tty terminal is switched via ctrl+alt+fn, causing the login session logind...), the strategy includes: suspending the application (e.g., switching the tty terminal via ctrl+alt+fn, causing the login session logind...). If a session switch occurs, the authentication request corresponding to the application is returned to the request pool and the authentication device resources are released. After the current request ends normally or exits abnormally, the authentication request that is not suspended and has the highest priority is selected from the request pool as the new current request.

[0032] Multi-factor authentication (MFA) services require authentication device drivers to perform the final authentication operation. However, the interfaces of different authentication device drivers are not consistent. To solve the problem that the inconsistency of different authentication device driver interfaces makes it impossible to use authentication devices from different hardware manufacturers at the same time, this embodiment also includes using a multi-factor authentication device service to provide an API abstraction layer for the multi-factor authentication service. The API abstraction layer transforms the different authentication device driver interfaces into a unified interface to achieve unified management of multiple authentication devices.

[0033] like Figure 3As shown in this embodiment, when different authentication device driver interfaces are transformed into a unified interface through the API abstraction layer to achieve unified management of multiple authentication devices, the unified interface includes the following three interfaces: Start Authentication (IdentifyStart): The input data for this interface is a JSON string, used to send customized data to different authentication devices to start authentication; Authentication Status Signal (IdentifyStatus): This signal contains a feature ID, status, and a message, where the feature ID is the identifier of the feature data recognized by the authentication device. If the feature ID is the same as the feature ID recorded by the user, authentication is successful; otherwise, authentication fails; Status (IdentifyStop) includes situations such as device idle, device busy, device verifying, device identifying, and device disabled. The message is a readable description of the status; Stop Authentication: Used to release authentication device resources.

[0034] The system architecture of the multi-factor authentication device scheduling method under Linux in this embodiment is as follows: Figure 4 As shown, the system architecture can be divided into four layers from bottom to top: device compatibility layer, authentication service, system PAM authentication framework, and application. The authentication application performs authentication through the PAM framework. The mfa_pam.so added to the system authentication process stack forwards the authentication request to the authentication service. The authentication service (including system applications and third-party applications) tracks the authentication request by creating an authentication session and sends it to the system PAM authentication framework. The system PAM authentication framework submits the request to the authentication service according to the authentication configuration of the current system. The authentication service integrates the multi-factor authentication service and multi-factor authentication device service of this embodiment. After processing by the authentication service, it sends the request to the device adapter of the corresponding device type. The device adapter queues all requests and performs queuing and preemption based on the request session activation status and authentication application type. It can be seen that the multi-factor authentication device scheduling method under Linux in this embodiment can improve the user experience for authentication needs in multiple scenarios, diverse authentication devices, and multi-session authentication under Linux. The advantages are as follows: 1) High compatibility with third-party applications with authentication needs under Linux, without modification. 2) Flexible configuration is supported for various authentication scenarios. 3) For authentication scheduling of exclusive devices, scheduling can be performed based on the session to which the authentication request belongs and the type of authentication request.

[0035] In addition, this embodiment also provides a Linux-based multi-factor authentication device scheduling system for all scenarios, including a microprocessor and a memory connected to each other, wherein the microprocessor is programmed or configured to execute the Linux-based multi-factor authentication device scheduling method for all scenarios.

[0036] In addition, this embodiment also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the Linux-based multi-factor authentication device scheduling method under all scenarios via a processor.

[0037] In addition, this embodiment also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the Linux full-scenario multi-factor authentication device scheduling method through a processor.

[0038] Those skilled in the art will understand that the technical solutions provided by the embodiments of this application may take the form of a method, system, or computer program product. Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create an implementation for the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0039] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A multi-factor authentication device scheduling method for all scenarios under Linux, characterized in that, The process includes the following steps: When the multi-factor authentication service receives an authentication request from an application to the PAM framework, it distinguishes between a graphical and non-graphical scenario based on the PAM_SERVICE attribute value of the PAM framework; based on the distinction, it executes the corresponding authentication device interaction method, including using a text interaction mode to guide the user through the multi-factor authentication device authentication when the scenario is non-graphical; and using a special command interaction mode to guide the user through the multi-factor authentication device authentication when the scenario is graphical. In the special command interaction mode, the PAM framework and the application that initiated the authentication request interact through commands and data in a specified format. When the PAM framework and the application initiating the authentication request interact through instructions and data in a specified format, the instructions and data in the specified format include three types of instructions: "authentication mode", "whether to bind user", and "authentication type". The "authentication mode" is used to specify whether the logical relationship between multiple authentication types is "AND" or "OR". The "whether to bind user" is used to determine whether an account name needs to be selected first. The "authentication type" is used to specify the required authentication method, which includes some or all of the following: password, fingerprint, finger vein, face, UKey, and iris scan. The special instruction interaction mode enables data interaction between the PAM framework and the application initiating the authentication request through instructions and data in a specified format. This includes: first, determining whether "user binding" requires selecting an account name first; if so, displaying the user interface to obtain the user's selected account name; then, generating the corresponding authentication program based on the authentication method specified in "authentication type" to guide the user through authentication; and finally, performing corresponding logical operations on all authentication results according to "authentication mode" to obtain the final authentication result as either successful or unsuccessful.

2. The multi-factor authentication device scheduling method under Linux for all scenarios as described in claim 1, characterized in that, When the multi-factor authentication service receives an authentication request from an application to the PAM framework, it also includes creating a unique and priority-based session ID for the session of the application that initiated the authentication request, and avoiding the problem of authentication device preemption by maintaining a request pool. All newly created authentication requests will be put into the request pool for unified management.

3. The multi-factor authentication device scheduling method under Linux for all scenarios as described in claim 2, characterized in that, The strategy of placing newly created authentication requests into a request pool for unified management includes: comparing the priority of the newly created authentication request with the priority of the current request in the request pool; if the priority of the newly created authentication request is higher than the priority of the current request in the request pool, the current request in the request pool is suspended, and the newly created authentication request is used as the new current request in the request pool to occupy authentication device resources, and the suspended authentication request is resumed after the new current request is completed; if the current request in the request pool has not completed the authentication operation within a set time, the current request in the request pool is removed from the request pool, the authentication device resources are released, and an error message is returned to the multi-factor authentication service; if the current request completes authentication, the final authentication result is returned to the multi-factor authentication service, and the authentication device resources corresponding to the current request are released; if the multi-factor authentication service is detected to have exited abnormally, the corresponding session and authentication request are closed, and if the authentication request is currently in progress, the authentication device resources corresponding to the authentication request are released; if the application is detected to have been suspended, the authentication request corresponding to the application is put back into the request pool and the authentication device resources are released; after the current request ends normally or exits abnormally, the authentication request that is not suspended and has the highest priority is selected from the request pool as the new current request.

4. The multi-factor authentication device scheduling method under Linux for all scenarios as described in claim 1, characterized in that, It also includes using a multi-factor authentication device service to provide an API abstraction layer for the multi-factor authentication service. Through the API abstraction layer, different authentication device driver interfaces are transformed into a unified interface to achieve unified management of multiple authentication devices.

5. The multi-factor authentication device scheduling method under Linux for all scenarios as described in claim 4, characterized in that, When different authentication device driver interfaces are transformed into a unified interface through the API abstraction layer to achieve unified management of multiple authentication devices, the unified interface includes the following three interfaces: Start Authentication: The input data of this interface is a JSON string, used to send customized data for different authentication devices to start authentication; Authentication Status Signal: This signal contains a feature ID, status, and message, where the feature ID is the identifier of the feature data recognized by the authentication device. If the feature ID is the same as the feature ID recorded by the user, the authentication is successful; otherwise, the authentication fails; the status includes device idle, device busy, device verifying, device identifying, and device disabled, and the message is a readable description of the status; Stop Authentication: Used to release authentication device resources.

6. A multi-factor authentication device scheduling system under Linux for all scenarios, comprising interconnected microprocessors and memory, characterized in that, The microprocessor is programmed or configured to execute the multi-factor authentication device scheduling method under Linux for all scenarios as described in any one of claims 1 to 5.

7. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the Linux full-scenario multi-factor authentication device scheduling method as described in any one of claims 1 to 5 via a processor.

8. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the Linux full-scenario multi-factor authentication device scheduling method as described in any one of claims 1 to 5 via a processor.

Images