Host login method, apparatus, device, and storage medium
By using a DLL file that employs multiple authentication methods during the host login process, including whitelist authentication, dynamic code authentication, and password authentication, the problem of easily cracked usernames and passwords is solved, the host security and authentication efficiency are improved, and a disaster recovery solution is provided.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BAIDU (CHINA) CO LTD
- Filing Date
- 2022-11-28
- Publication Date
- 2026-05-29
AI Technical Summary
Existing host login methods based on usernames and passwords are easily cracked, leading to reduced host security.
A custom DLL file is used to indicate multiple authentication methods, including whitelist authentication, dynamic code authentication, and password authentication, to perform multi-factor authentication on login requests. Users are only allowed to log in if all authentication methods pass.
It improves host security by enhancing the ability to identify unauthorized logins through multi-factor authentication, reducing the risk of dynamic codes being cracked, and providing disaster recovery capabilities in abnormal situations.
Smart Images
Figure CN115913729B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, specifically to the fields of security protection and cloud computing, and in particular to a host login method, apparatus, device and storage medium. Background Technology
[0002] In related technologies, login to the host is typically based on a username and password. After the host is powered on, the user can enter a username and password. The host's login authentication module authenticates the username and password, and allows the user to log in to the host after successful authentication. Summary of the Invention
[0003] This disclosure provides a host login method, apparatus, device, and storage medium.
[0004] According to one aspect of this disclosure, a host login method is provided, comprising: in response to a login request initiated by a user, loading a custom DLL file, the DLL file being used to indicate the authentication method of the login request, wherein the authentication method is multiple; authenticating the login request based on each of the multiple authentication methods to obtain an authentication result for each authentication method; and allowing the user to log in to the host if the authentication result for each authentication method is successful.
[0005] According to another aspect of this disclosure, a host login device is provided, comprising: a loading module, configured to load a custom DLL file in response to a login request initiated by a user, the DLL file being used to indicate the authentication method of the login request, wherein the authentication method is multiple; an authentication module, configured to authenticate the login request based on each of the multiple authentication methods to obtain an authentication result for each authentication method; and a processing module, configured to allow the user to log in to the host if the authentication result for each authentication method is successful.
[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to said at least one processor; wherein the memory stores instructions executable by said at least one processor, said instructions being executed by said at least one processor to enable said at least one processor to perform the method as described in any of the foregoing aspects.
[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the method according to any of the preceding aspects.
[0008] According to another aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method according to any of the preceding aspects.
[0009] The technical solution disclosed herein can improve the security of the host computer.
[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description
[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:
[0012] Figure 1 This is a schematic diagram based on the first embodiment of the present disclosure;
[0013] Figure 2 This is a schematic diagram illustrating an exemplary application scenario according to embodiments of this disclosure;
[0014] Figure 3 This is a schematic diagram according to the second embodiment of the present disclosure;
[0015] Figure 4 This is a schematic diagram according to the third embodiment of the present disclosure;
[0016] Figure 5 This is a schematic diagram according to the fourth embodiment of the present disclosure;
[0017] Figure 6 This is a schematic diagram of an electronic device used to implement the host login method of the embodiments of this disclosure. Detailed Implementation
[0018] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.
[0019] In related technologies, the method of authenticating host login based on username and password can reduce host security because passwords are easy to crack.
[0020] To improve the security of the host, this disclosure provides the following embodiments.
[0021] Figure 1Based on a schematic diagram of the first embodiment of this disclosure, this embodiment provides a host login method, the method including:
[0022] 101. In response to a login request initiated by a user, load a custom DLL file, wherein the DLL file is used to indicate the authentication method of the login request, and the authentication method is multiple.
[0023] 102. Based on each of the multiple authentication methods, authenticate the login request separately to obtain the authentication result of each authentication method.
[0024] 103. If the authentication result of each authentication method is successful, the user is allowed to log in to the host.
[0025] The host can be a physical host, a cloud host, a virtual host that can be remotely logged in, etc.
[0026] After the host starts up, it can display a login interface to the user, who can then initiate a login request based on the login interface.
[0027] After a user initiates a login request, the host's login authentication module (or login authentication component) can authenticate the login request.
[0028] Taking a host operating system of Windows as an example, the login authentication module can specifically be the winlogon program.
[0029] The winlogon program, WindowsLogonProcess (winlogon.exe), is a core system process in the Windows operating system used to manage user login and logout.
[0030] For example, after a user starts the host, the host's winlogon program can display a login interface. The user can enter their username, password, etc., and generate a login request by clicking the "Login" button. The winlogon program can then authenticate the login request.
[0031] After receiving a login request, the login authentication module can load a custom dynamic link library (DLL) file and use the custom DLL to authenticate the login request.
[0032] A DLL is a library containing code and data that can be used by multiple programs simultaneously. When multiple programs use the same function, a DLL can reduce the amount of code that is duplicated in disk and physical memory.
[0033] Taking the login authentication module as an example, the DLL file that authenticates login requests can be the CredentialProvider component.
[0034] The CredentialProvider component is a DLL loaded by winlogon.exe, which describes the credentials it needs to collect, including the authentication method. Furthermore, this authentication method information is modifiable. The default setting is a single authentication method, meaning authentication is based on the username and password entered by the user.
[0035] In this embodiment, the content of the CredentialProvider component can be modified to include content related to multiple authentication methods. Specifically, this can be achieved by modifying the source code of the CredentialProvider component, for example, by modifying the getserialization and reportresult functions, so that the modified source code includes content related to multiple authentication methods.
[0036] A DLL file compiled from the modified source code can be called a custom DLL file. A custom DLL file contains information on multiple authentication methods, thus enabling the indication of multiple authentication methods.
[0037] After loading the custom DLL file, the login request can be authenticated based on each of the multiple authentication methods indicated by the custom DLL file, and the authentication result for each method can be obtained. The authentication result includes authentication successful or authentication failed.
[0038] If all authentication methods pass, the login request is considered successful, allowing the user to log in to the host. Conversely, if at least one authentication method fails, the login request fails, denying the user access to the host.
[0039] Allowing a user to log in to the host can involve displaying the host's operating system interface (desktop) to the user, after which the user can interact with applications installed on the operating system. Denying a user's login to the host can involve displaying a login failure message to the user.
[0040] In this embodiment, employing multiple authentication methods to authenticate login requests enhances host security. Furthermore, providing various authentication methods based on a custom DLL ensures compatibility with various existing operating systems, improving universality.
[0041] To facilitate understanding of the embodiments of this disclosure, the application scenarios of the embodiments of this disclosure are described below.
[0042] Figure 2 This is a schematic diagram illustrating an exemplary application scenario according to embodiments of this disclosure. The system corresponding to this application scenario can be referred to as an account reinforcement system, such as... Figure 2 As shown, the account reinforcement system includes: server 201 and client 202.
[0043] Client-side (202) deployments can be made on each protected host, including personal computers (PCs), mobile devices (such as mobile phones and laptops), smart home appliances (such as smart TVs and smart speakers), and wearable devices (such as smartwatches and smart bracelets). Server-side (201) deployments can be made on a server, which can be a local server or a cloud server. The server can manage one or more hosts.
[0044] like Figure 2 As shown, server 201 may include: a management platform, a database, and an authentication center. The management platform manages clients, for example, by sending commands to clients to enable or disable account hardening; additionally, administrators can configure whitelists on the management platform, which can also synchronize the whitelists to clients. The database stores account information configured by the management platform, including, for example, usernames and their corresponding related information (such as mobile phone numbers). The authentication center receives authentication requests sent by the login authentication component on the host, authenticates the requests based on the account information, and synchronizes the authentication results to the login authentication component. Referring to subsequent descriptions, the authentication center primarily performs dynamic code authentication.
[0045] The client 202 is deployed on the host, which includes a login authentication component. Taking a Windows operating system as an example, the login authentication component is the winlogon program.
[0046] The client retrieves the whitelist from the server and writes it to a pre-specified whitelist file. To enhance security, the server can encrypt the whitelist and send the encrypted whitelist to the client, which then writes the encrypted whitelist to the whitelist file.
[0047] The client can also install custom DLL files. The host operating system's registry includes configuration information that records information about the DLL files to be loaded. By default, the DLL files to be loaded are default DLL files, meaning they only include DLL files with a single authentication method. In this embodiment, after the client is installed on the host, it can modify the aforementioned configuration information, changing the DLL file information recorded in the configuration information to information about a custom DLL file. Thus, the configuration information indicates that the DLL file to be loaded is a custom DLL file. Since the configuration information records information about a custom DLL file, it can be considered that a custom DLL file was installed by the client.
[0048] The winlogon program can load custom DLL files and authenticate login requests based on various authentication methods indicated by the custom DLL files.
[0049] Multiple authentication methods are available, including whitelist authentication, dynamic code authentication, and password authentication.
[0050] For whitelist authentication, the winlogon program can obtain the whitelist from the whitelist file and perform whitelist authentication based on the whitelist.
[0051] For dynamic code authentication, the winlogon program can send an authentication request to the server-side authentication center. After obtaining the dynamic code authentication result, the authentication center sends (synchronizes) the dynamic code authentication result to the winlogon program.
[0052] For password authentication, which checks whether the username and password entered by the user match, a password authentication process using relevant technologies can be employed.
[0053] The execution order of the above three authentication methods is not limited. However, considering efficiency and other issues, whitelist authentication can be performed first; after whitelist authentication is successful, dynamic code authentication can be performed; after dynamic code authentication is successful, password authentication can be performed.
[0054] In conjunction with the above application scenarios, this disclosure also provides the following host login method.
[0055] Figure 3 Based on the schematic diagram of the second embodiment of this disclosure, this embodiment provides a host login method. This embodiment takes a host operating system of Windows as an example, and the corresponding login authentication module is the winlogon program, such as... Figure 3 As shown, and in combination Figure 4 The overall architecture process shown includes the following methods:
[0056] 301. The winlogon program, in response to a login request initiated by a user, loads a custom DLL file, wherein the DLL file is used to indicate the authentication method of the login request, and the authentication method is multiple.
[0057] After the host computer starts up, the winlogon program can provide a login interface to the user. (See reference...) Figure 4 Users can enter their username and password on the login page and click the login button to initiate a login request, which includes the username and password.
[0058] Once the winlogon program starts, it can read the configuration information in the registry and load DLL files based on that configuration information.
[0059] Combination Figure 2 After the client is installed on the host, it can receive commands from the server. For example, after receiving the command to enable account hardening, the client can modify the configuration information in the registry and change the DLL file to be loaded as indicated in the configuration information to a custom DLL file. Based on the modified configuration information of the client, the winlogon program can load the custom DLL file, thus realizing the installation of the custom DLL file.
[0060] In addition, the server can send a whitelist to the client, and the client writes the whitelist to a preset file so that the winlogon program can read the whitelist from the preset file.
[0061] In this embodiment, a custom DLL file is loaded based on the configuration information in the registry, and multiple authentications are performed based on the custom DLL file, which enables compatible development and adapts to different versions of the Windows operating system.
[0062] The various authentication methods can include: whitelist authentication, dynamic code authentication, and password authentication. Based on these three authentication methods, the following can be performed:
[0063] 302. The winlogon program performs whitelist authentication based on the whitelist obtained from the client and the username, and determines whether the whitelist authentication is successful. If successful, execute 303; otherwise, execute 306.
[0064] For whitelist authentication, it can include:
[0065] If the whitelist is in a normal state, and the username included in the login request belongs to a username recorded in the whitelist, then the whitelist authentication result is determined to be successful; or...
[0066] If the whitelist is in an abnormal state and the time in the abnormal state reaches a first preset duration, the whitelist authentication result is determined to be successful.
[0067] The whitelist being in a normal state means that a whitelist exists on the host and can be updated normally.
[0068] For example, if the server is functioning normally and communication between the server and client is normal, the server can periodically transmit a whitelist to the client, and the client can periodically update its local whitelist, for example, once per minute. The whitelist can have a timestamp, and whether the whitelist has been updated can be determined based on whether the timestamp has been updated. For example, if the preset period is one minute, if the time difference between the whitelist's timestamp and the current time is greater than one minute, it indicates that the timestamp has stopped updating, meaning the corresponding whitelist has stopped updating, and the whitelist can be considered to be in an abnormal state. Conversely, if the timestamp is updated periodically, it indicates that the whitelist is in a normal state.
[0069] If the whitelist is in a normal state, it can be determined whether the username in the login request belongs to the username recorded in the whitelist. If it does, the whitelist authentication is passed; otherwise, the whitelist authentication is not passed.
[0070] Whitelist authentication may encounter abnormal situations, which may include: server-side abnormalities (such as server crashes), network abnormalities between the server and the client, and client-side abnormalities (such as the client exiting). Correspondingly, the whitelist will be in an abnormal state, which may manifest as the whitelist not existing on the host; or the whitelist no longer being updated, meaning the whitelist timestamp remains in the past.
[0071] If the whitelist is in an abnormal state, it can be determined whether the abnormal state has lasted for a preset duration (e.g., 20 minutes). If it has, the whitelist authentication is considered successful to avoid problems such as being unable to use the host due to abnormal conditions.
[0072] refer to Figure 4 The whitelist obtained by the client from the server can be encrypted, such as a whitelist encrypted with Advanced Encryption Standard (AES). The winlogon program can decrypt the encrypted whitelist using a preset key to obtain the decrypted whitelist, and then use the decrypted whitelist for whitelist authentication.
[0073] In this embodiment, when the whitelist is in a normal state, whitelist authentication can be performed based on whether the username belongs to the username recorded in the whitelist; when the whitelist is in an abnormal state, whitelist authentication can be passed by default after a certain period of time to achieve disaster recovery function and avoid the inability to log in to the host due to abnormal situations.
[0074] 303. The winlogon program receives the dynamic code authentication result sent by the server and determines whether the dynamic code authentication is successful. If it is, it executes 304; otherwise, it executes 306.
[0075] After confirming that the whitelist authentication is successful, the winlogon program can trigger the server to perform dynamic code authentication and obtain the dynamic code authentication result from the server.
[0076] Specifically, this may include: sending a dynamic code authentication request to the server, the dynamic code authentication request containing the username, so that the server generates a first dynamic code based on the dynamic code authentication request and sends the first dynamic code to the mobile phone used by the user; receiving a second dynamic code input by the user and sending the second dynamic code to the server, so that the server determines a dynamic code authentication result based on the first dynamic code and the second dynamic code; and receiving the dynamic code authentication result sent by the server.
[0077] refer to Figure 4 The winlogon program can send a dynamic code authentication request to the server, carrying the username. Upon receiving the request, the server can retrieve the corresponding mobile phone number from the database. The server can also generate a dynamic code and send it as an SMS to the mobile phone number via a message server. Furthermore, the server can manage the dynamic codes, such as setting their expiration time and binding them to the system time.
[0078] After receiving the dynamic code on their mobile phone, users can enter the dynamic code into the login interface and send it to the winlogon program.
[0079] To distinguish them, the dynamic code generated by the server and transmitted to the mobile phone can be called the first dynamic code, and the dynamic code entered by the user can be called the second dynamic code.
[0080] After receiving the second dynamic code, the winlogon program can transmit it to the server. Upon receiving the second dynamic code, the server can compare it with the first dynamic code. If they are the same, the dynamic code authentication is successful; otherwise, the dynamic code authentication fails, and the server will synchronize the authentication result to the winlogon program.
[0081] Before transmitting the second dynamic code, the winlogon program can encrypt the second dynamic code and transmit the encrypted second dynamic code to the server. The server then uses a preset key to decrypt the second dynamic code.
[0082] In addition, if the dynamic code has an expiration time, it is also necessary to determine whether the dynamic code has expired. If the dynamic code has not expired and the generated dynamic code (first dynamic code) and the received dynamic code (second dynamic code) are consistent, the dynamic code authentication is confirmed to be successful.
[0083] For dynamic code authentication, solutions can also be provided for abnormal situations, including: server-side abnormalities (such as server crashes), network abnormalities between the server and the client, and client-side abnormalities (such as client exits). In such cases, a server restart can be triggered, or a retry expiration mechanism can be used. That is, if a dynamic code authentication result cannot be obtained from the server after a certain period of time (such as 20 minutes), the dynamic code authentication is considered successful.
[0084] Since information on the host is easily cracked, in this embodiment, dynamic code authentication is performed on the server side, which can improve security compared to dynamic code authentication on the host side.
[0085] In addition, solutions for abnormal situations are provided for dynamic code authentication, which can have disaster recovery capabilities to avoid being unable to log in to the host.
[0086] 304. The winlogon program performs password authentication based on the username and password, and determines whether the password authentication is successful. If successful, proceed to 305; otherwise, proceed to 306.
[0087] After the dynamic code authentication is successful, the winlogon program can perform password authentication. For example, it can compare the username and password entered by the user with the username and password stored in its own database. If they match, the password authentication is successful; otherwise, it fails.
[0088] 305. The winlogon program allows the user to log in to the host.
[0089] For example, the host operating system interface can be shown to the user, after which the user can operate the applications installed on the host operating system.
[0090] 306. The winlogon program denies the user from logging into the host.
[0091] For example, displaying a login failure message to the user.
[0092] In this embodiment, three authentication methods are used for host login, which improves security compared to a single authentication method. By setting a whitelist for authentication, the username in the login request can be compared with the usernames recorded in the whitelist, allowing for faster identification of unauthorized logins and improving authentication efficiency. Dynamic code authentication is performed by the server, with the host receiving the authentication result. Compared to host-side authentication, server-side authentication reduces the risk of dynamic codes being cracked, further enhancing security. Additionally, this embodiment provides a disaster recovery solution for abnormal situations, preventing login failures in abnormal circumstances. Furthermore, both the whitelist transmitted from the server to the host and the dynamic code transmitted from the host to the server can be encrypted during transmission and storage, preventing data leakage and further improving security.
[0093] Figure 5 The schematic diagram is based on the fourth embodiment of the present disclosure. This embodiment provides a host login device 500, which includes: a loading module 501, an authentication module 502, and a processing module 503.
[0094] The loading module 501 is used to load a custom DLL file in response to a login request initiated by a user. The DLL file is used to indicate the authentication method of the login request, and the authentication method is multiple. The authentication module 502 is used to authenticate the login request based on each of the multiple authentication methods to obtain the authentication result of each authentication method. The processing module 503 is used to allow the user to log in to the host if the authentication result of each authentication method is successful.
[0095] In this embodiment, employing multiple authentication methods to authenticate login requests enhances host security. Furthermore, providing various authentication methods based on a custom DLL ensures compatibility with various existing operating systems, improving versatility.
[0096] In some embodiments, the loading module 501 is further configured to:
[0097] Based on the configuration information in the registry, a custom DLL file is loaded. The configuration information is configured by the client and is used to indicate that the DLL file to be loaded is the custom DLL file.
[0098] In this embodiment, a custom DLL file is loaded based on the configuration information in the registry, and multiple authentications are performed based on the custom DLL file, which enables compatible development and adapts to different versions of the Windows operating system.
[0099] In some embodiments, the multiple authentication methods include: whitelist authentication, dynamic code authentication, and password authentication; the login request includes a username and password; the authentication module 502 is further configured to perform at least one of the following:
[0100] For whitelist authentication, the whitelist authentication result is determined based on the whitelist obtained by the client and the username.
[0101] For dynamic code authentication, receive the dynamic code authentication result sent by the server;
[0102] For password authentication, the password authentication result is determined based on the username and the password.
[0103] In this embodiment, three authentication methods are used for host login, which can improve security compared to a single authentication method.
[0104] In some embodiments, the authentication module 502 is further configured to:
[0105] If the whitelist is in a normal state, and the username contained in the login request belongs to a username recorded in the whitelist, the whitelist authentication result is determined to be successful; or...
[0106] If the whitelist is in an abnormal state and the time in the abnormal state reaches a preset duration, the whitelist authentication result is determined to be successful.
[0107] In this embodiment, when the whitelist is in a normal state, whitelist authentication can be performed based on whether the username belongs to the username recorded in the whitelist; when the whitelist is in an abnormal state, whitelist authentication can be passed by default after a certain period of time to achieve disaster recovery function and avoid the inability to log in to the host due to abnormal situations.
[0108] In some embodiments, the authentication module 502 is further configured to:
[0109] A dynamic code authentication request is sent to the server, the dynamic code authentication request containing the username, so that the server generates a first dynamic code based on the dynamic code authentication request and sends the first dynamic code to the mobile phone used by the user.
[0110] The system receives the second dynamic code input by the user and sends the second dynamic code to the server, so that the server determines the dynamic code authentication result based on the first dynamic code and the second dynamic code.
[0111] Receive the dynamic code authentication result sent by the server.
[0112] Since information on the host is easily cracked, in this embodiment, dynamic code authentication is performed on the server side, which can improve security compared to dynamic code authentication on the host side.
[0113] It is understood that the same or similar content in different embodiments of this disclosure can be referred to each other.
[0114] It is understood that the terms "first" and "second" in the embodiments of this disclosure are only used for distinction and do not indicate the degree of importance or the order of events.
[0115] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.
[0116] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device 600 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.
[0117] like Figure 6 As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the electronic device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.
[0118] Multiple components in electronic device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of displays, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0119] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as the host login method. For example, in some embodiments, the host login method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the host login method described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the host login method by any other suitable means (e.g., by means of firmware).
[0120] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0121] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable interconnection apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0122] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0123] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0124] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.
[0125] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem, addressing the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.
[0126] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.
[0127] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.
Claims
1. A host login method, applied to the winlogon program of the host's Windows operating system, comprising: In response to a login request initiated by a user, a custom DLL file is loaded. The DLL file is used to indicate the authentication method of the login request, and the authentication method can be multiple. The DLL file is obtained by modifying and compiling the source code of the credential providing component; the custom DLL file is obtained by the client responding to the server's command and modifying the configuration information in the registry. The configuration information corresponds to the default DLL file by default, and the default DLL file only includes a single authentication method. The login request is authenticated based on each of the multiple authentication methods to obtain the authentication result for each method. If the authentication result of each of the above authentication methods is successful, the user is allowed to log in to the host; The multiple authentication methods include: whitelist authentication, wherein the whitelist corresponding to the whitelist authentication is written into a preset file by the client, and the whitelist is obtained by the client from the server; If the whitelist is in an abnormal state for a preset duration, the whitelist authentication is confirmed to be successful. The abnormal state of the whitelist includes: server-side abnormality, network abnormality between the server and the client, or client-side abnormality.
2. The method according to claim 1, wherein, The various authentication methods also include: dynamic code authentication and password authentication; The login request includes a username and password; The process of authenticating the login request based on each of the multiple authentication methods to obtain the authentication result for each method includes at least one of the following: For whitelist authentication, the whitelist authentication result is determined based on the whitelist obtained by the client and the username. For dynamic code authentication, receive the dynamic code authentication result sent by the server; For password authentication, the password authentication result is determined based on the username and the password.
3. The method according to claim 2, wherein, The process of determining the whitelist authentication result based on the whitelist obtained from the client and the username includes: If the whitelist is in a normal state and the username contained in the login request belongs to the username recorded in the whitelist, the whitelist authentication result is determined to be successful.
4. The method according to claim 2, wherein, The dynamic code authentication result sent by the receiving server includes: A dynamic code authentication request is sent to the server, the dynamic code authentication request containing the username, so that the server generates a first dynamic code based on the dynamic code authentication request and sends the first dynamic code to the mobile phone used by the user. The system receives the second dynamic code input by the user and sends the second dynamic code to the server, so that the server determines the dynamic code authentication result based on the first dynamic code and the second dynamic code. Receive the dynamic code authentication result sent by the server.
5. A host login device, applied to the winlogon program of the host's Windows operating system, comprising: A loading module is used to load a custom DLL file in response to a login request initiated by a user. The DLL file is used to indicate the authentication method of the login request, and the authentication method can be multiple. The DLL file is obtained by modifying and compiling the source code of the credential providing component; the custom DLL file is obtained by the client responding to the server's command and modifying the configuration information in the registry. The configuration information corresponds to the default DLL file by default, and the default DLL file only includes a single authentication method. The authentication module is used to authenticate the login request based on each of the multiple authentication methods to obtain the authentication result of each authentication method; The processing module is configured to allow the user to log in to the host if the authentication result of each authentication method is successful. The multiple authentication methods include: whitelist authentication, wherein the whitelist corresponding to the whitelist authentication is written into a preset file by the client, and the whitelist is obtained by the client from the server; If the whitelist is in an abnormal state for a preset duration, the whitelist authentication is confirmed to be successful. The abnormal state of the whitelist includes: server-side abnormality, network abnormality between the server and the client, or client-side abnormality.
6. The apparatus according to claim 5, wherein, The various authentication methods also include: dynamic code authentication and password authentication; The login request includes a username and password; The authentication module is further configured to perform at least one of the following: For whitelist authentication, the whitelist authentication result is determined based on the whitelist obtained by the client and the username. For dynamic code authentication, receive the dynamic code authentication result sent by the server; For password authentication, the password authentication result is determined based on the username and the password.
7. The apparatus according to claim 6, wherein, The authentication module is further used for: If the whitelist is in a normal state and the username contained in the login request belongs to the username recorded in the whitelist, the whitelist authentication result is determined to be successful.
8. The apparatus according to claim 6, wherein, The authentication module is further used for: A dynamic code authentication request is sent to the server, the dynamic code authentication request containing the username, so that the server generates a first dynamic code based on the dynamic code authentication request and sends the first dynamic code to the mobile phone used by the user. The system receives the second dynamic code input by the user and sends the second dynamic code to the server, so that the server determines the dynamic code authentication result based on the first dynamic code and the second dynamic code. Receive the dynamic code authentication result sent by the server.
9. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-4.
10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-4.
11. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-4.