Face recognition injection risk recognition method and computing device

Abstract

The invention provides a face recognition injection risk identification method, which comprises the following steps that: a client obtains information of an available camera of equipment where the client is located and sends the information to a server, and the server judges whether a face recognition injection risk exists or not according to the information of the available camera and returns a result to the client. By analyzing the information of the available cameras, whether video injection attacks exist or not can be identified more efficiently compared with video analysis.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of computer technology application technology, and more particularly, to a face recognition injection risk identification method and computing device. Background Art

[0002] With the development of technology, identity authentication through face recognition has been widely used. In particular, HyperText Markup Language 5 (H5) face recognition technology does not require additional installation of applications, and face recognition can be completed using a browser. It is widely used in the fields of user identity authentication in online banking, e-commerce, and remote office systems. Among them, H5 applications refer to online application services accessed through browsers.

[0003] However, compared with face recognition in applications, H5-side face recognition is more vulnerable to face recognition video injection attacks due to the limitations of browser open capabilities. The related art lacks a low-cost method for detecting face recognition injection attacks. Summary of the invention

[0004] The purpose of this specification is to provide a face recognition injection risk identification method and computing device.

[0005] In a first aspect, the present specification provides a face recognition injection risk identification method, which is applied to a server, and the method comprises:

[0006] Get the information of available cameras of the device where the client is located uploaded by the client;

[0007] Determining whether the client has a risk of face recognition injection based on the information of the available cameras;

[0008] The determination result is returned to the client.

[0009] A second aspect of the present specification provides a face recognition injection risk identification method, which is applied to a client, and the method includes:

[0010] Get the information of available cameras of the client device;

[0011] Sending the available camera information to the server;

[0012] Receive a determination result of whether there is a risk of facial recognition injection sent by a server; the determination result is determined by the server according to information of the available camera.

[0013] The third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the face recognition injection risk identification method described in the first aspect or the second aspect.

[0014] The fourth aspect of this specification provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the face recognition injection risk identification method described in the first aspect or the second aspect is implemented.

[0015] The fifth aspect of this specification provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the face recognition injection risk identification method described in the first aspect or the second aspect.

[0016] This specification provides a method for identifying face recognition injection risks. The client obtains information about available cameras on the device and sends it to the server. The server determines whether there is a face recognition injection risk based on the information about the available cameras and returns the result to the client.

[0017] By analyzing the information from available cameras, it is possible to more efficiently identify whether a video injection attack exists than by analyzing the video itself. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0019] Figure 1 is a schematic diagram of an application scenario in an embodiment;

[0020] Figure 2 is a flow chart of a method for identifying risk of face recognition injection in one embodiment;

[0021] Figure 3 is a block diagram of a face recognition injection risk identification device in one embodiment;

[0022] Figure 4 It is a block diagram of a face recognition injection risk identification device in another embodiment. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0024] Video injection attack refers to an attack method that deceives the face recognition system by injecting fake video data into the face recognition system. In related technologies, compared with native applications (Native App), face recognition on the H5 side is more susceptible to video injection attacks. Analysis of video injection attacks shows that compared with native applications, browsers have weaker security protection capabilities, and attackers are more likely to attack through simple methods, such as using a virtual camera to import pre-recorded face videos to attack. Among them, a virtual camera refers to a camera simulated by software.

[0025] For easy understanding, let’s first introduce the H5 end.

[0026] H5 refers to online applications accessed through a browser, and H5 face recognition refers to face recognition technology implemented through web pages.

[0027] The H5 terminal can realize the browser-based access to application capabilities. Specifically, HTML5 enables web pages to be independent of the client's native application functions through offline access, local storage, application programming interface (API), cross-platform compatibility, responsive design, and hardware access capabilities.

[0028] Offline access refers to the web page access that a user can perform when the device is not connected to the network. For example, in the related art, resources can be cached through scripts that run independently of the web page to achieve offline access.

[0029] Local storage refers to storing data on the device of the web application user, which allows the web application to store data like the client, making the acquisition of data no longer completely dependent on the server.

[0030] API refers to a set of predefined functions, classes, methods, protocols, etc., through which some functions can be encapsulated. H5 terminals generally provide a rich set of APIs, allowing web applications to have the same rich functions as native applications.

[0031] Cross-platform compatibility means that H5 applications are implemented based on browsers, so there is no need to develop them separately for different operating systems during development.

[0032] Responsive design means that web applications can adapt to the screen size of various devices, making the web pages accessible on a variety of terminals.

[0033] In addition, the browser can also directly access the hardware functions through APIs, etc. For example, the browser can access the camera through the API. This allows web applications to complete face authentication.

[0034] However, the openness of browsers also makes it easier for attackers to perform video injection attacks through virtual cameras.

[0035] Specifically, attackers can configure and simulate camera devices through the operating system or third-party software. When face recognition is required, the browser will request permission to use the camera, and attackers can provide the camera to web applications through the API on the H5 side. Video injection attacks can then be implemented through virtual cameras.

[0036] The identification methods of face recognition injection risks used in related technologies are often complex. For example, it is usually possible to determine whether the person currently performing face recognition is a real person based on face recognition video data through a video content analysis algorithm based on machine learning, and then determine whether there is a video injection attack. This method requires a lot of calculations and is costly, especially for scenarios such as H5-end face recognition, which are more susceptible to video injection attacks.

[0037] Based on this, this specification provides a method for identifying face recognition injection risks. The client obtains information about available cameras on the device and sends it to the server. The server determines whether there is a face recognition injection risk based on the information about the available cameras and returns the result to the client.

[0038] By analyzing the information from available cameras, it is possible to more efficiently identify whether a video injection attack exists than by analyzing the video itself.

[0039] Next, a face recognition injection risk identification method shown in this specification will be described.

[0040] First, the system architecture of the application scenario in this manual is described. Figure 1 As shown, this manual involves users, devices where the client is located, and servers.

[0041] Users can operate the device where the client is located and interact with the client, such as performing face recognition.

[0042] As mentioned above, the method in this specification can be applied to H5 end face recognition, so the client can be an online application accessed through a browser. In addition, although the above description of the problems existing in the related art is made through the browser scenario, it can be understood that the method in this specification can also be applied to other scenarios, such as the client can also be a native application installed on the device.

[0043] The client device is the device used by the user to browse the client, which can be a smart phone, computer, tablet computer and other devices.

[0044] The server corresponds to the client. The method in this specification determines the risk of facial recognition injection through the collaborative working mechanism of the client and the server, which is more secure than determining it only through the client. In particular, when the client is an online application accessed through a browser, the browser code can be directly read by attackers due to the openness of the browser, making the determination of facial recognition injection risk through the browser less secure. It is safer to complete the detection of facial recognition injection risk through the server.

[0045] Next, we will combine Figure 2 Let's explain the face recognition injection risk identification method shown in this specification.

[0046] Step 201: The client obtains information about available cameras of the device where the client is located.

[0047] The available cameras refer to the cameras that can be used on the device. The information of the available cameras may include the name and / or manufacturer of the available cameras. The name of the camera may include the name of the camera displayed on the device and / or the specific model of the camera.

[0048] As for the specific implementation of step 201, the information of all available cameras on the device can be obtained through an API provided by the browser that can obtain the available cameras on the device. For example, a list of all available cameras on the device can be obtained through navigator.mediaDevices.enumerateDevices(). By calling this API, a list of all media input and output devices on the device can be returned, and then devices classified as cameras can be filtered out through category filtering, thereby obtaining information of all available cameras. Of course, this example does not limit this specification.

[0049] As for the specific execution time of step 201, it can be executed when the user opens the client, for example, when the client is an online application accessed through a browser, the method can be executed when the user opens a web page. In addition, the method can also be executed when the user turns on the face recognition function.

[0050] Step 203: Send the available camera information to the server.

[0051] Correspondingly, the server executes step 213 (not shown in the figure): the server obtains the information of the available cameras of the device where the client is located uploaded by the client.

[0052] Since the server is responsible for determining whether there is a risk of face recognition injection in this method, the client needs to upload the information of available cameras to the server in this step.

[0053] Step 215: The server determines whether the client has a risk of facial recognition injection based on the information of the available cameras.

[0054] The type and source of the camera are rarely verified in related technologies, resulting in video injection attackers usually not changing the name of the camera or forging the camera's information (such as the manufacturer, etc.). Therefore, it is possible to determine whether there is a risk of facial recognition injection by analyzing the information of the available cameras.

[0055] As for the specific method of determining whether there is a risk of facial recognition injection, in an optional implementation, the information of the available cameras includes the name and / or manufacturer of the camera as described above. Common virtual cameras generally include specific tags, such as "OBS", "Virtual Camera", etc. Moreover, the manufacturer in the camera information is generally different from that of ordinary cameras and is a specific manufacturer. Therefore, it is possible to identify whether the information of the available cameras contains specific characters, strings, etc. to identify whether it is a virtual camera. The specific characters and strings are the characters or strings that the preset virtual cameras generally include.

[0056] OBS: refers to OBS Studio. The full name of OBS is Open Broadcaster Software, which is a video recording and live broadcast software that is often used to create virtual cameras. Virtual Camera refers to virtual cameras.

[0057] In other words, when the information of available cameras includes the name and / or manufacturer of the camera, step 215 specifically includes: determining whether the client has a risk of facial recognition injection by determining whether the name and / or manufacturer of the camera includes preset keywords, and the preset keywords are used to indicate that the camera is a virtual camera.

[0058] The preset keywords may be characters or strings as described above, that is, characters or strings generally included in a virtual camera. The preset keywords may be determined based on the names and manufacturers of various existing virtual cameras.

[0059] Through preset keywords, it is possible to quickly determine whether there are any available cameras that match the name, model, and manufacturer of the known virtual camera, thereby conveniently, quickly, and inexpensively determining whether there is a risk of facial recognition injection.

[0060] In addition, when the client is an online application accessed through a browser, in addition to identifying whether there is a face recognition injection risk through camera information, it is also possible to identify whether there is a face recognition injection risk based on browser information.

[0061] Specifically, in some scenarios, users are restricted to access only through mobile terminals, or restricted to access only through computers. When the device actually used by the user for face recognition does not match the restricted device type, it indicates that there may be face recognition video injection behavior. Based on the browser's user agent (UA), it can be determined what type of device client the browser currently used to access the client is, such as a mobile terminal client, or a computer client, or a smart watch client, etc. Then, it can be determined whether there is a risk of face recognition injection based on whether the browser's UA matches the preset browser UA.

[0062] In other words, the above method also includes: the server obtains the UA of the browser sent by the client; when the sent browser UA does not match the preset browser UA, it is determined that there is a risk of facial recognition injection. Correspondingly, the client obtains and sends the browser UA to the server, so that the server determines whether there is a risk of facial recognition injection based on whether the sent browser UA matches the preset browser UA.

[0063] Among them, the preset browser UA is also the browser UA that the user needs to use in the current scenario. In addition, since a variety of information can be obtained through UA, such as operating system information, device type (desktop device or mobile device, which may record the specific device model), etc. In addition to the above-mentioned identification of whether it is the device type required for the current scenario based on UA, it is also possible to identify whether it is the operating system information required for the current scenario, etc. For example, if the current scenario limits access to a mobile browser, the obtained browser UA can be matched with the UA corresponding to the preset mobile browser to determine whether there is a risk of facial recognition injection. When it is determined through UA that the user accesses through the PC, it is determined that there is a risk of facial recognition injection.

[0064] It should also be noted that the above mentioned two methods for detecting face recognition injection risks. In order to ensure security, if any of the two methods detects that there is a face recognition injection risk, it can be determined that there is a face recognition injection risk, thereby improving security as much as possible.

[0065] Step 217: The server returns the determination result to the client.

[0066] Correspondingly, the client executes step 207 (not shown in the figure). Specifically, step 207 includes: the client receives a determination result sent by the server whether there is a risk of facial recognition injection; the determination result is determined by the server based on the information of the available cameras.

[0067] After the server obtains the determination result of whether there is a risk of facial recognition injection, it can return the determination result to the client.

[0068] In addition, when the determination result indicates that there is a risk of facial recognition injection, while returning the determination result, the server can also: reject the facial recognition request of the client to ensure the user's account security.

[0069] Correspondingly, the client receives the determination result from the server. If the determination result indicates that there is a risk of facial recognition injection, the corresponding determination result can be displayed to the user based on the determination result. Information corresponding to the determination result can also be displayed, such as: displaying information indicating that there are security risks in facial recognition, rejecting the user's authentication request, and / or prompting the user to perform additional identity authentication. This allows the user to get feedback.

[0070] When it is determined that the result indicates that there is no risk of facial recognition injection, after obtaining the facial authentication video uploaded by the user through the client, it is possible to further analyze whether there is an injection attack at present based on the machine learning-based video content analysis algorithm in the relevant technology, thereby better protecting the security of the user account.

[0071] In other words, the server can perform: when the determination result indicates that there is no risk of facial recognition injection, determine whether the facial recognition video uploaded by the client has an injection attack according to a preset machine learning algorithm. The preset machine learning algorithm is an algorithm for analyzing whether the facial recognition video has an injection attack.

[0072] In this case, since a part of the attackers can be screened out through the method provided in this specification, the amount of video that needs to be processed when analyzing the video through the machine learning algorithm in the subsequent steps is reduced, thereby accelerating the identification of face recognition injection risks.

[0073] In this manual, by analyzing the information of available cameras, virtual cameras can be effectively identified without additional hardware or complex video analysis. Compared with machine learning-based methods, it is cheaper, easier to implement, and more efficient.

[0074] This specification also provides a face recognition injection risk identification device, such as Figure 3 As shown, the device comprises:

[0075] An acquisition module 310 is used to acquire information of available cameras of a device where the client is located uploaded by the client;

[0076] A first determination module 320, configured to determine whether the client has a risk of face recognition injection according to information of the available cameras;

[0077] The returning module 330 is configured to return the determination result to the client.

[0078] In an optional embodiment, the information of the available cameras includes the name and / or manufacturer of the camera; the first determination module 320 is specifically used to determine whether the client has a risk of facial recognition injection by determining whether the name and / or manufacturer of the camera includes preset keywords, and the preset keywords are used to indicate that the camera is a virtual camera.

[0079] In an optional implementation, the client is an online application accessed through a browser.

[0080] In an optional implementation, the method further includes a second determination module 340 (not shown in the figure), which is used to obtain the UA of the browser sent by the client; when the sent browser UA does not match the preset browser UA, it is determined that there is a risk of facial recognition injection.

[0081] In an optional implementation, the device further includes a rejection module 350 (not shown in the figure), which is used to reject the face recognition request of the client when there is a risk of face recognition injection.

[0082] This manual also provides a face recognition injection risk identification method, such as Figure 4 As shown, the device comprises:

[0083] An acquisition module 410 is used to acquire information about available cameras of the device where the client is located;

[0084] A sending module 420 is used to send the information of the available cameras to the server;

[0085] The receiving module 430 is used to receive a determination result of whether there is a risk of facial recognition injection sent by the server; the determination result is determined by the server according to the information of the available cameras.

[0086] In an optional implementation, the client is an online application accessed through a browser.

[0087] In an optional implementation, the acquisition module 410 is further used to acquire and send the browser UA to the server, so that the server determines whether there is a face recognition injection risk based on whether the sent browser UA matches the preset browser UA.

[0088] In an optional embodiment, the device also includes a rejection module 440 (not shown in the figure), which is used to display information indicating that there are security risks in facial recognition, reject the user's authentication request, and / or prompt the user to perform additional identity authentication when there is a risk of facial recognition injection.

[0089] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0090] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

[0091] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this specification does not exclude that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0092] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

[0093] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0094] This specification is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0095] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0096] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0097] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0098] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0099] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0100] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0101] One or more embodiments of the present specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0102] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0103] The above description is only an example of one or more embodiments of the present specification and is not intended to limit one or more embodiments of the present specification. For those skilled in the art, one or more embodiments of the present specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification shall be included in the scope of the claims.

Claims

1. A face recognition injection risk identification method, applied to a server, comprising: Get the information of available cameras of the device where the client is located uploaded by the client; Determining whether the client has a risk of face recognition injection based on the information of the available cameras; The determination result is returned to the client.

2. The method according to claim 1, wherein the information of the available cameras includes the name and / or manufacturer of the cameras; The determining, according to the information of the available cameras, whether the client has a risk of face recognition injection includes: By determining whether the name and / or manufacturer of the camera includes a preset keyword, it is determined whether the client has a face recognition injection risk, and the preset keyword is used to indicate that the camera is a virtual camera.

3. The method according to claim 1, wherein the client is an online application accessed through a browser.

4. The method according to claim 3, further comprising: Get the browser's user agent UA sent by the client; When the sent browser UA does not match the preset browser UA, it is determined that there is a risk of face recognition injection.

5. The method according to claim 1, further comprising: When the determination result indicates that there is no risk of facial recognition injection, it is determined whether there is an injection attack in the facial authentication video uploaded by the client according to a preset machine learning algorithm.

6. A face recognition injection risk identification method, applied to a client, the method comprising: Get the information of available cameras of the client device; Sending the available camera information to the server; Receive a determination result of whether there is a risk of facial recognition injection sent by a server; the determination result is determined by the server according to information of the available camera. The method according to claim 6 , wherein the client is an online application accessed through a browser.

8. The method according to claim 7, further comprising: The browser UA is obtained and sent to the server, so that the server determines whether there is a risk of face recognition injection according to whether the sent UA matches the preset browser UA.

9. The method according to claim 6, in the case where there is a risk of facial recognition injection, the method further comprises: Display information indicating that there are security risks in face recognition, rejecting the user's authentication request, and / or prompting the user to perform additional identity authentication.

10. A computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 9 is implemented.

Images