CN106850518B

CN106850518B - Security authentication method and device

Info

Publication number: CN106850518B
Application number: CN201510892229.5A
Authority: CN
Inventors: 邓青; 申军立; 张尧; 陈龙; 付若尘
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2015-12-07
Filing date: 2015-12-07
Publication date: 2020-05-12
Anticipated expiration: 2035-12-07
Also published as: CN106850518A

Abstract

The invention discloses a security authentication method and a security authentication device. Wherein, the method comprises the following steps: receiving an operation request sent by a specified account, wherein the operation request is used for indicating the specified account to execute specified operation; acquiring the type of a specified account; when the type of the designated account is a sub-account which is subordinate to the primary account, sending a security verification request for requesting verification of the designated operation to first trusted equipment or second trusted equipment, wherein the first trusted equipment is trusted equipment registered by the primary account, and the second trusted equipment is trusted equipment registered by the sub-account; and receiving a verification result returned after the first trusted device or the second trusted device performs one-key verification on the security verification request, wherein the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

Description

Security authentication method and device

Technical Field

The invention relates to the technical field of internet, in particular to a security authentication method and device.

Background

The safety verification of the PC terminal aiming at the high-risk operation of the user in the related technology mainly has two approaches: 1. the existing terminal (such as a computer) is installed with the digital certificate to become a trusted device, and the disadvantage is that the operation can only be carried out at the existing terminal, and the relevant operation can be carried out if the digital certificate needs to be reinstalled when the device is replaced. And. In the related art, the security verification scene of a seller mainly carries out security prevention and control through a certificate, and the certificate has certain experience problems, such as complex installation, compatibility of a browser operating system and the like. In the future, the browser may not support the control, so that the certificate cannot be used, and the active seller and the sub-account in the whole network cannot be normally used. 2. The short message or the dynamic password is received through a terminal (such as a mobile phone), and the received information is input on the PC to pass the verification, so that the defects that the verification is required each time, the operation needs to be switched on the PC and the mobile phone and the information needs to be input manually, the steps are long and complicated, and the input is easy to be wrong.

In view of the above problems, no effective solution has been proposed.

Disclosure of Invention

According to an aspect of an embodiment of the present application, there is provided a security authentication method, including: receiving an operation request sent by a specified account, wherein the operation request is used for indicating the specified account to execute specified operation; acquiring the type of a specified account; when the type of the designated account is a sub-account which is subordinate to the primary account, sending a security verification request for requesting verification of the designated operation to first trusted equipment or second trusted equipment, wherein the first trusted equipment is trusted equipment registered by the primary account, and the second trusted equipment is trusted equipment registered by the sub-account; and receiving a verification result returned after the first trusted device or the second trusted device performs one-key verification on the security verification request, wherein the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

According to another aspect of the embodiments of the present application, there is also provided a security authentication method, including: the method comprises the steps that a trusted device of a specified account receives a security verification request which is sent by a server and used for requesting verification of specified operation; the specified operation is a specified operation executed by a specified account; when the designated account is a sub-account subordinate to the primary account, the trusted device includes: the system comprises a first trusted device or a second trusted device, wherein the first trusted device is a trusted device registered by a primary account, and the second trusted device is a trusted device registered by a sub-account; the trusted device performs one-key verification on the security verification request; the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

According to another aspect of the embodiments of the present application, there is also provided a security authentication apparatus, including: the first receiving module is used for receiving an operation request sent by a specified account, wherein the operation request is used for indicating the specified account to execute specified operation; the acquisition module is used for acquiring the type of the specified account; the system comprises a first sending module and a second sending module, wherein the first sending module is used for sending a security verification request for requesting verification of a specified operation to a first trusted device or a second trusted device when the type of a specified account is a sub-account subordinate to a primary account, the first trusted device is a trusted device registered by the primary account, and the second trusted device is a trusted device registered by the sub-account; and the second receiving module is used for receiving a verification result returned after the first trusted device or the second trusted device performs one-key verification on the security verification request, wherein the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

According to another aspect of the embodiments of the present application, there is also provided a security authentication apparatus, located in a trusted device, including: the receiving module is used for receiving a security verification request which is sent by the server and used for requesting to verify the specified operation; the specified operation is a specified operation executed by a specified account; when the designated account is a sub-account subordinate to the primary account, the trusted device includes: the system comprises a first trusted device or a second trusted device, wherein the first trusted device is a trusted device registered by a primary account, and the second trusted device is a trusted device registered by a sub-account; the verification module is used for performing one-key verification on the security verification request; the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

In the embodiment of the application, when the designated account number for performing the designated operation is a sub-account number under the primary account number, a security verification request for requesting verification of the designated operation is sent to the first trusted device or the second trusted device, and the first trusted device or the second trusted device performs one-key verification on the security verification request, the security verification request for performing the designated operation can be independently initiated through the sub-account number without authorization of the primary account number, and the first trusted device or the second trusted device verifies the security verification request in a one-key verification manner, so that the operation of inputting an account number password is avoided, and after the verification is performed through the first trusted device or the second trusted device, identity authentication is not required when the operation is performed again, thereby achieving the purpose of simplifying the verification process, and further achieving the technical effect of rapid security verification, and further solve the technical problems of complicated and inconvenient safety authentication mode in the related technology.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:

fig. 1 is a block diagram of a hardware structure of a computer terminal of a security authentication method according to an embodiment of the present application;

fig. 2 is a first flowchart of a security authentication method according to embodiment 1 of the present application;

fig. 3 is a flowchart ii of a security authentication method according to embodiment 1 of the present application;

fig. 4 is a flowchart three of a security authentication method according to embodiment 1 of the present application;

fig. 5 is a fourth flowchart of a security authentication method according to embodiment 1 of the present application;

fig. 6 is a flowchart five of a security authentication method according to embodiment 1 of the present application;

FIG. 7 is a diagram of a PC-side prompt to verify that a request has been issued to a trusted device in accordance with an alternative embodiment of the present application;

FIG. 8 is a schematic diagram of a trusted device receiving an authentication request in accordance with an alternative embodiment of the present application;

FIG. 9 is a schematic diagram of a sub-account applying for primary account help verification in accordance with an alternative embodiment of the present application;

fig. 10 is a schematic diagram of a trusted device on a PC side that prompts for a verification request to be issued to a primary account number according to an alternative embodiment of the present application;

FIG. 11 is a schematic illustration of a trusted device of a primary account number receiving a verification request in accordance with an alternative embodiment of the present application;

FIG. 12 is a schematic illustration of a verification center page in accordance with an alternative embodiment of the present application;

fig. 13 is a schematic flowchart of a trusted device for registering a primary account number by a rights issuer according to an alternative embodiment of the present application;

fig. 14 is a schematic flow chart of a trusted device for registering a sub-account with a rights issuer according to an alternative embodiment of the present application;

FIG. 15 is a schematic flow chart diagram of a security authentication method according to an alternative embodiment of the present application;

fig. 16 is a first flowchart of a security authentication method according to embodiment 2 of the present application;

fig. 17 is a block diagram i of the configuration of a security authentication apparatus according to embodiment 3 of the present application;

fig. 18 is a block diagram of the configuration of a security authentication apparatus according to embodiment 3 of the present application;

fig. 19 is a block diagram iii of the configuration of a security authentication apparatus according to embodiment 3 of the present application;

fig. 20 is a block diagram of the configuration of a security authentication apparatus according to embodiment 3 of the present application;

fig. 21 is a block diagram showing the structure of a security authentication apparatus according to embodiment 3 of the present application;

fig. 22 is a block diagram six of the configuration of a security authentication apparatus according to embodiment 3 of the present application;

fig. 23 is a block diagram showing the structure of a security authentication apparatus according to embodiment 4 of the present application;

fig. 24 is a block diagram of a computer terminal according to an embodiment of the present application.

Detailed Description

In order to make the technical solutions of the present invention better understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

To facilitate understanding of the present invention, terms referred to in the embodiments of the present invention are briefly explained as follows:

the seller has multiple accounts: namely a primary account number and a sub-account number of a seller, a primary account number is used by a shop owner, and a sub-account number is used by a shop employee to assist in managing the shop.

The trusted device: whether the environment of the terminal equipment logged in by the account is safe or not is analyzed according to the data model, if the environment is safe, the equipment is trusted equipment, namely, the environment of one equipment is safe, the equipment can be called as trusted equipment, and the trusted equipment needs to be registered and authorized through an authorization center to replace a digital certificate, short message verification and a dynamic password to receive a security verification request.

Example 1

There is also provided, in accordance with an embodiment of the present application, a method embodiment for secure authentication, it being noted that the steps illustrated in the flowchart of the drawings may be performed in a computer system such as a set of computer-executable instructions and that, although a logical order is illustrated in the flowchart, in some cases the steps illustrated or described may be performed in an order different than here.

The method provided by the embodiment 1 of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking an example of the security authentication method running on a computer terminal, fig. 1 is a hardware structure block diagram of the computer terminal according to the embodiment of the present application. As shown in fig. 1, the computer terminal 10 may include one or more (only one shown) processors 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission module 106 for communication functions. It will be understood by those skilled in the art that the structure shown in fig. 1 is only an illustration and is not intended to limit the structure of the electronic device. For example, the computer terminal 10 may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.

The memory 104 may be configured to store software programs and modules of application software, such as program instructions/modules corresponding to the security authentication method in the embodiment of the present application, and the processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implementing the vulnerability detection method of the application program. The memory 104 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory located remotely from the processor 102, which may be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission module 106 is used to receive or transmit data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission module 106 includes a Network adapter (NIC) that can be connected to other Network devices through a base station to communicate with the internet. In one example, the transmission module 106 may be a Radio Frequency (RF) module, which is used for communicating with the internet in a wireless manner.

Under the operating environment, the application provides a security authentication method as shown in fig. 2. Fig. 2 is a first flowchart of a security authentication method according to embodiment 1 of the present application, where the method includes steps S202 to S208:

step S202, receiving an operation request sent by a specified account, wherein the operation request is used for indicating the specified account to execute specified operation;

it should be noted that the above-mentioned specified operation may be a specified type of operation, and the specified type of operation may be a risky operation, such as a dangerous operation, but may also be a non-risky operation, i.e., a safe operation, but is not limited thereto. The operation with risk may refer to an operation performed by the specified account with security problem, may be an operation performed in a network environment or a device with security problem, or may be an operation performed by the specified account with risk, but is not limited thereto.

Because the operation type of the designated operation is different, different processing may be performed on the designated operation, for example, for a secure operation, the device logged in by the designated account may be notified to directly pass through the secure operation without performing verification, but for an operation with a risk, security verification needs to be performed on the operation, so in an embodiment of the present application, fig. 3 is a second flowchart of a security authentication method according to embodiment 1 of the present application, as shown in fig. 3, after step S202, the following steps may also be performed:

step S302, obtaining the operation type of the specified operation;

step S304, under the condition that the operation type is the designated type, triggering to acquire the type of the designated account;

step S306, sending second indication information to the terminal logged by the specified account if the specified operation is not the specified type, where the second indication information is used to indicate that the terminal logged by the specified account passes through the specified operation.

It should be noted that the specified type may refer to an operation with a risk, and in this step, a request for security verification may be initiated only when the operation with the risk is present, and in a case that the specified operation is definitely not present with a risk, the terminal logged in by the specified account is directly notified to release the specified operation, so that the steps of verification are saved, and the efficiency of verification is improved.

Step S204, acquiring the type of the specified account;

it should be noted that the type of the specified account may be a primary account, or may be a sub-account under the primary account, for example, in electronic commerce, a seller may have many accounts, a store owner of a store of the seller has one account to manage the store, and each employee of the store also has one account to assist in managing the store, in this example, the account used by the store owner may be referred to as the primary account, and the account used by each employee may be referred to as the sub-account, in this scenario, the specified operation may be to publish a product, edit product information, modify a product price, and the like.

It should be noted that, an environment of one device is safe and trusted, and may be referred to as a trusted device, and in the case that the device is a trusted device, verification of a specified operation may not be required, and a specified account may register a trusted device corresponding to the specified account, and it should be noted that one specified account may also register one or more trusted devices, and the trusted device may be a computer terminal, a tablet computer, or a mobile phone, and is not limited thereto. Taking a trusted device as a mobile phone as an example, assuming that the network environment, the operating environment, and other environments of the mobile phone are all secure, an account is designated as an account of a user login webpage, and if the webpage is logged in on the mobile phone a through the account and the webpage is also logged in on the mobile phone B through the account, both the mobile phone a and the mobile phone B can be trusted devices of the account.

In order to save the verification process, the specified operation may be verified by the above-mentioned trusted device, but before verification using the trusted device, the trusted device needs to be registered, so, in an embodiment of the present application, fig. 4 is a flowchart three of a security authentication method according to embodiment 1 of the present application, as shown in fig. 4, before step S204, the method further includes: step S402, sending first indication information to a terminal logged in by the specified account if there is no trusted device corresponding to the specified account or the one-key authentication function is not started, where the first indication information is used to indicate that the specified account registers the trusted device corresponding to the specified account. The trusted device corresponding to the specified account may be instructed to be registered for use in the present or subsequent authentication, either by absence of the trusted device or by presence of the trusted device but without the one-key authentication being enabled.

It should be noted that, in the case that there is a trusted device corresponding to the specified account, step S204 may be directly performed to perform a specific verification process.

Step S206, when the type of the specified account is a sub-account subordinate to the primary account, sending a security verification request for requesting verification of the specified operation to a first trusted device or a second trusted device, where the first trusted device is a trusted device registered by the primary account, and the second trusted device is a trusted device registered by the sub-account;

in an optional embodiment of the present application, in a case that a second trusted device corresponding to the sub-account already exists and the function of one-key verification is already turned on, the step S206 may be represented as: and selecting a trusted device from the first trusted device and the second trusted device according to a preset priority, and sending a security verification request to the selected trusted device. In the case that there is no second trusted device corresponding to the sub-account, the step S206 may be as follows: the security verification request is sent to the first trusted device. That is, in the case where there is no second trusted device corresponding to the sub-account, the security verification request may be transmitted to the first trusted device registered with the primary account, but is not limited thereto.

It should be noted that the first trusted device may be registered in the following manner: verifying the primary account number and the password corresponding to the primary account number; under the condition of successful verification, judging whether the primary account number is bound with the specified equipment or not; verifying the verification code input into the specified equipment under the condition of binding the specified equipment; and under the condition that the short message verification is successful, registering the specified equipment as the first trusted equipment.

It should be noted that registering the first trusted device may be performed by an authority. In the event of unsuccessful verification, the primary account number may be directed to bind the specified device.

Optionally, the first trusted device has a survival time, and the specified device is taken as the first trusted device during the survival time. That is, after the designated device is registered as the first trusted device, the designated device may not need to be verified again during the time-to-live. The time-to-live may be set by the authorization center at the time of registration, or a default time-to-live may be used, for example, within a default of 14 days, the designated device does not need to be securely authenticated.

In an alternative embodiment of the present application, any user who hits a risk rule needs to perform a secondary security verification even on the trusted device after the designated device is the trusted device. Thus, after registering the designated device as the first trusted device, the process of registering further comprises: and in the case that the number of times of executing the operation with the same operation type as the specified operation is detected to exceed the preset number of times within the preset time, triggering the specified device to be subjected to security verification, wherein after the security verification is passed, the specified device is taken as the first trusted device continuously. The security performance is better improved by the secondary security verification method.

The predetermined time may be preset by the user according to different scenes, or may be a default value, which is not limited to this.

Similar to registering a first trusted device with a primary account, registering a trusted device with a secondary account is also required, and in one embodiment of the present application, a second trusted device may be registered in the following manner: verifying the sub-account and the password corresponding to the sub-account; under the condition of successful verification, sending an authorization application request to a primary account number to which the sub-account number belongs; and under the condition that the authorization of the primary account number passes, registering the specified device as the second trusted device.

It should be noted that registering the second trusted device may be performed by an authority. Registering the second trusted device for the sub-account requires an authorization confirmation through the primary account, and the primary account can master operations of all the sub-accounts. The second trusted device also has a time-to-live during which the designated device is treated as the second trusted device. That is, after the designated device is registered as the second trusted device, the designated device may not need to be verified again during the time-to-live. The time-to-live may be set by the authorization center at the time of registration, or a default time-to-live may be used, for example, within a default of 14 days, the designated device does not need to be securely authenticated.

In an alternative embodiment of the application, similar to registering as the first trusted device, any user hitting a risk rule needs to perform a secondary security verification even on the second trusted device, by being behind the designated device as the second trusted device. Thus, after registering the designated device as the second trusted device, the process of registering further comprises: and in the case that the number of times of executing the operation with the same operation type as the specified operation is detected to exceed the preset number of times within the preset time, triggering the specified device to be subjected to security verification, wherein after the security verification is passed, the specified device is taken as the second trusted device. The security performance is better improved by the secondary security verification method.

In another embodiment of the present application, fig. 5 is a fourth flowchart of a security authentication method according to embodiment 1 of the present application, and as shown in fig. 5, the method further includes:

step S502, when the type of the specified account is the primary account, sending the security verification request to the first trusted device.

It should be noted that when the type of the designated account is a sub-account, the security verification request may be selectively sent to the first trusted device, or may also be selectively sent to the second trusted device; and sending a security verification request to the first trusted device under the condition that the type of the designated account is the primary account. Therefore, although the sub-account number belongs to the primary account number, the sub-account number and the primary account number are independent from each other in the security verification process, that is, independent operation can be performed regardless of the primary account number or the sub-account number, and for the sub-account number, the server does not need to request the primary account number to assign the authority to the sub-account number.

Step S208, receiving a verification result returned after the first trusted device or the second trusted device performs one-key verification on the security verification request, where the one-key verification is a verification process triggered after the dedicated button on the trusted device receives the trigger instruction.

It should be noted that the verification result may include: confirming the verification is passed or rejected.

Fig. 6 is a fifth flowchart of a security authentication method according to embodiment 1 of the present application, and as shown in fig. 6, after the verification passes, the method further includes: step S602, instructing the terminal logged in by the specified account to pass all operations from the specified account. After the verification is confirmed to pass, all operations from the specified account can be directly released without performing security verification within a certain time period, and then after the verification passes through the trusted device, the operations do not need to be verified every time, so that the user experience is improved.

By the method, when the designated account number for performing the designated operation is a sub-account number subordinate to the primary account number, a security verification request for requesting verification of the designated operation is sent to the first trusted device or the second trusted device, and the first trusted device or the second trusted device performs one-key verification on the security verification request, the security verification request for performing the designated operation can be independently initiated through the sub-account number without authorization of the primary account number, and the first trusted device or the second trusted device verifies the security verification request in a one-key verification manner, so that the operation of inputting an account number password is avoided, and after verification is performed through the first trusted device or the second trusted device, identity authentication is not required when the operation is performed again, so that the purpose of simplifying a verification process is achieved, and the technical effect of rapid security verification is achieved, and further solve the technical problems of complicated and inconvenient safety authentication mode in the related technology.

Taking an example that a certain store employee logs in a certain webpage through a computer, assuming that a trusted device of an account (sub-account) used by the employee is a mobile phone a, a trusted device of an account (primary account) used by a store owner is a mobile phone B, and both the mobile phone a and the mobile phone B have already started a one-key authentication function, in this embodiment, when the employee logs in the webpage through the computer to perform an operation of putting up a commodity, the obtained account used by the employee is the sub-account, an authorization request can be preferentially sent to the mobile phone a, and after the mobile phone a receives the authorization request, a user can approve or reject the operation of the employee's putting up the commodity by only clicking a one-key authentication button on the mobile phone a. The mobile phone B can be selected to apply for help verification, that is, an authorization request can be sent to the mobile phone B, and after the mobile phone B receives the authorization request, the user can agree or refuse to put on the shelf the commodity of the employee only by clicking a one-key verification button on the mobile phone B. When a shop owner performs the operation of shelving the commodities through a computer login page, the acquired account number used by the shop owner is a primary account number, and then an authorization request is directly sent to the mobile phone B, so that after the mobile phone B receives the authorization request, the user can realize the operation of agreeing or refusing the shelving of the shop owner only by clicking a one-key verification button on the mobile phone B. The verification is carried out through a one-key verification function of the verification of the mobile phone A or the mobile phone B belonging to the trusted equipment, and the verification is carried out in a short message verification mode without downloading a certificate, so that the shop management efficiency is improved.

For a better understanding of the present application, the present application is further explained below with reference to alternative embodiments.

The application provides a selectable security authentication method, which mainly comprises the following steps:

step 1, when a primary account logs in or performs a high-risk operation (which is equivalent to a specified type of operation or a specified operation in the foregoing embodiment), if the primary account registers a trusted device (such as a mobile phone), the server side sends an authentication request to the trusted device of the primary account (which is equivalent to step S502 in the foregoing embodiment), and then, as shown in fig. 7, the PC side prompts that the authentication request has been sent to the trusted device, and the trusted device receives a corresponding authentication request, as shown in fig. 8, prompts that the authentication request needs to be confirmed on the trusted device, and waits for a user to confirm whether the user performs an operation himself. If the primary account number does not register the trusted device, the trusted device needs to be booted and opened (corresponding to step S402).

And 2, logging in the sub-account or performing high-risk operation, if the sub-account has trusted equipment, sending an authorization request to the trusted equipment corresponding to the sub-account (same as the step 1), and if the sub-account has no trusted equipment, sending an authorization request to the trusted equipment corresponding to the primary account and guiding the user to add the trusted equipment.

Step 3, when performing security verification on the sub-account, an authorization request (equivalent to the security verification request in the above embodiment) may be selected to be sent to the primary account, that is, a request for performing help verification on the primary account may be selected, as shown in fig. 9, a primary account help verification may be selected by clicking a temporary primary account verification application button in fig. 9, and then, as shown in fig. 10, the PC side prompts that the authorization request has been sent to the primary account, and prompts that the trusted mobile phone needs to be opened by the primary account for confirmation, at this time, an effective verification time may be set, and if the authorization request is not processed after the verification time is exceeded, the authorization request is invalidated. Then, as shown in fig. 11, a verification request is prompted on the trusted device of the primary account number to be confirmed, and confirmation of authorization of the primary account number is waited.

Step 4, if a push (push) request is not received, the authentication center page (as shown in fig. 12) can be entered to manually load the authentication request, the authentication request can be set to be valid within 5 minutes, and the authentication request is invalid if the authentication request is not processed for more than 5 minutes. The situation that the trusted device cannot receive the authentication request and cannot pass the security authentication can be caused by the instability of the network environment or system reasons. The data is updated in real time, and the inquiry request to the server can effectively reduce the abnormal condition.

Step 5, after the operation of the PC device is verified, the security verification is not required again in the current user session (within 24 hours) (equivalent to step S602 in the above embodiment).

And 6, if the PC equipment is added as the trusted equipment, the equipment does not need to be subjected to security verification within 14 days by default.

And 7, increasing the frequency of making security policies, and performing secondary security verification on any user who hits the risk rules even on the trusted device. For example: and (4) performing high-risk operation for more than N times within 30 minutes, and triggering security verification on the trusted equipment again.

It should be noted that, in alternative embodiments of the present application, the size of the step number does not represent the order of executing the steps.

In an alternative embodiment of the present application, fig. 13 is a schematic flowchart of a process of registering, by a rights issuer, a trusted device of a primary account according to the alternative embodiment of the present application, and as shown in fig. 13, the registration process includes:

step S1302, judging whether the primary account number and the password corresponding to the primary account number are successfully verified; if the verification fails, step S1304 is executed, and if the verification succeeds, step S1306 is executed;

step S1304, the primary account number fails to open the authorization center;

step 1306, judging whether the primary account number is bound with a mobile phone; in the case of yes, step S1308 is performed; in the case of no, step S1310 is performed;

step S1308, verifying the verification code input to the mobile phone; in the case where the verification is successful, step S1312 is performed; in the case where the verification is not successful, step S1304 is executed;

step 1310, guiding the primary account number to bind the mobile phone;

step S1312, the primary account number successfully opens the authorization center;

in step S1314, the mobile phone (current device) is used as the trusted device of the primary account.

The process of registration corresponds to the process of registering the trusted device of the primary account number in the above embodiment.

Fig. 14 is a flowchart illustrating a process of registering a trusted device of a sub-account by a rights issuer according to an alternative embodiment of the present application, where, as shown in fig. 14, the registration process includes:

step S1402, judging whether the sub-account and the password corresponding to the sub-account are successfully verified; in the case where the verification fails, step S1404 is performed, and in the case where the verification succeeds, step S1406 is performed;

step S1404, the sub-account fails to open the authorization center;

step S1406, sending an authorization application to the primary account to which the sub-account belongs;

step S1408, judging whether the authorization of the primary account number passes; in case of a pass, step S1410 is executed; in the case of no passage, step S1404 is performed;

step 1410, the sub-account number successfully opens the authorization center;

in step S1412, the mobile phone (current device) is used as the trusted device of the sub-account.

The process of registration is equivalent to the process of registering the trusted device of the sub-account in the above embodiment.

The present application provides another optional method of security authentication, fig. 15 is a schematic flowchart of a security authentication method according to an optional embodiment of the present application, and as shown in fig. 15, the method mainly includes the following steps:

step S1502, the PC requests the server to perform high risk operation (corresponding to step S202 in the above embodiment);

step S1504, the server judges whether the operation has risk; if there is a risk, step S1506 is executed, and if there is no risk, step S1508 is executed;

step S1506, the server determines whether the account performing the operation registers the trusted mobile phone, and starts one-key verification; if yes, go to step S1510, if no, go to step S1512;

step S1508, the PC directly releases the operation (equivalent to step S306 in the above embodiment);

step S1510, the server determines whether the account is a primary account; if the account number is the primary account number, step S1514 is executed, and if the account number is not the primary account number, step S1516 is executed;

step S1512, the PC prompts guidance registration as a trusted mobile phone (equivalent to step S402 in the foregoing embodiment);

step S1514, the server sends an authentication request to the trusted handset (equivalent to sending a security authentication request to the second trusted device in step S206 and step S502);

step S1516, judge whether the subaccount registers the credible mobile phone, and open the one-key verification; if yes, go to step S1514, if no, go to step S1518;

step S1518, the server sends an authentication request to the trusted mobile phone of the primary account (which is equivalent to sending a security authentication request to the first trusted device in step S206);

step S1520, the mobile phone end confirms or rejects the verification request, and uploads the result back to the server; if the mobile phone end is not processed after timeout or rejected, executing step S1522; if the mobile phone side agrees with the verification request, executing step S1524;

step S1522, informing the PC terminal to refuse the operation;

step 1524, the PC is notified to release the operation successfully.

It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present invention is not limited by the order of acts, as some steps may occur in other orders or concurrently in accordance with the invention. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required by the invention.

Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present invention.

Example 2

According to an embodiment of the present application, there is also provided a security authentication method, and fig. 16 is a first flowchart of a security authentication method according to embodiment 2 of the present application, where the method includes:

step S1602, a trusted device of a specific account receives a security verification request sent by a server to request verification of a specific operation; wherein, the specified operation is the specified operation executed by the specified account; when the designated account is a sub-account subordinate to the primary account, the trusted device includes: the first trusted device is a trusted device registered by the primary account number, and the second trusted device is a trusted device registered by the sub-account number;

Step S1604, the trusted device performs one-key verification on the security verification request; wherein, the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

It should be noted that the trusted device, the first trusted device, and the second trusted device in this embodiment are equivalent to the trusted device, the first trusted device, and the second trusted device in embodiment 1 described above, and the process of the first trusted device of the registered primary account and the process of the second trusted device of the registered sub-account are equivalent to the process in embodiment 1, and are not described here again.

Through the steps, the first trusted device or the second trusted device is used for carrying out safety verification on the operation of the sub-account through one-key verification without inputting an account password, so that the purpose of simplifying a verification process is achieved, the technical effect of quick safety verification is achieved, and the technical problems that a safety authentication mode in the related technology is complicated, inconvenient and quick are solved.

It should be noted that the primary account and the sub-account can be operated independently, when the sub-account is operated, the sub-account does not need the primary account to assign a right to the sub-account, the sub-account can send a security verification request to the trusted device in terms of the operation, and when the primary account is operated, the authorization of the sub-account does not need to be obtained, which is specifically expressed in an embodiment of the present application: when the designated account is the primary account, the trusted device includes: the first trusted device.

Example 3

According to an embodiment of the present invention, there is further provided an apparatus for implementing the above-mentioned security authentication method, and fig. 17 is a first structural block diagram of a security authentication apparatus according to embodiment 3 of the present application, and as shown in fig. 17, the apparatus includes:

a first receiving module 1702, configured to receive an operation request sent by a specified account, where the operation request is used to instruct the specified account to perform a specified operation;

Because the operation type of the designated operation is different, different processing may be performed on the designated operation, for example, for a security operation, the device logged in by the designated account may be notified to directly pass through the security operation without performing verification, but for an operation with a risk, security verification needs to be performed on the operation, so in an embodiment of the present application, fig. 18 is a block diagram of a second structure of a security authentication apparatus according to embodiment 3 of the present application, and as shown in fig. 18, the apparatus further includes:

an obtaining module 1802, configured to obtain an operation type of the specified operation;

a triggering module 1804, connected to the obtaining module 1802, for triggering and determining the type of the specified account when the operation type is the specified type;

a third sending module 1806, connected to the triggering module 1804, configured to send second indication information to the terminal logged by the specified account if the specified operation is not the specified type, where the second indication information is used to indicate that the terminal logged by the specified account passes through the specified operation.

It should be noted that the specified type may refer to an operation with a risk, the triggering module 1804 may initiate a request for security verification when it is known that the operation has a risk, and the third sending module 1806 directly notifies the terminal logged in by the specified account to pass the specified operation without performing security verification under the condition that the specified operation is definitely not at risk, so that the steps of verification are saved, and the efficiency of verification is improved.

An obtaining module 1704, connected to the first receiving module 1702, configured to obtain the type of the specified account;

In order to save the verification process, the specified operation may be verified by the above-mentioned trusted device, but before verification using the trusted device, the trusted device needs to be registered, so, in an embodiment of the present application, fig. 19 is a block diagram of a third configuration of the security authentication apparatus according to embodiment 3 of the present application, and as shown in fig. 19, the above-mentioned apparatus further includes: a second sending module 1902, configured to send, in the absence of a trusted device corresponding to the specified account or in a case where the one-key authentication function is not started, first indication information to a terminal to which the specified account is logged in; the first indication information is used for indicating the specified account to register the trusted device corresponding to the specified account.

A first sending module 1706, connected to the obtaining module 1704, configured to send, to a first trusted device or a second trusted device, a security verification request for requesting verification of the specified operation when the type of the specified account is a sub-account that is subordinate to a primary account, where the first trusted device is a trusted device registered by the primary account, and the second trusted device is a trusted device registered by the sub-account;

fig. 20 is a block diagram of a fourth configuration of a security authentication apparatus according to embodiment 3 of the present application, and as shown in fig. 20, the first sending module 1706 may include:

a first sending unit 2002, configured to, in a case where the second trusted device corresponding to the sub-account already exists and the one-key authentication function has been turned on, select a trusted device from the first trusted device and the second trusted device according to a preset priority, and send a security authentication request to the selected trusted device; wherein the preset priority comprises: the first trusted device has a lower priority than the second trusted device. That is, in a case where a second trusted device corresponding to the sub-account already exists and the one-touch authentication function is already turned on, the first transmitting unit 2002 may select to transmit the security authentication request to one trusted device from among the first trusted device and the second trusted device, and may preferentially select to transmit the security authentication request to the second trusted device.

A second sending unit 2004, configured to send the security verification request to the first trusted device in a case where the second trusted device corresponding to the sub-account does not exist. That is, in the case where there is no second trusted device corresponding to the sub-account, the second transmitting unit 2004 may transmit the security verification request to the first trusted device registered with the primary account, but is not limited thereto.

Since the first trusted device needs to be pre-registered, in an embodiment of the present application, fig. 21 is a block diagram of a configuration of a security authentication apparatus according to embodiment 3 of the present application, and as shown in fig. 21, the apparatus further includes: a first registration module 2102 for registering the first trusted device with the primary account number, wherein the first registration module 2102 may include: a first verification unit 2104 configured to verify the primary account number and a password corresponding to the primary account number; a determining unit 2106, connected to the first verifying unit 2104, configured to determine, if the verification is successful, whether the primary account number is bound to a specified device; a second verification unit 2108, connected to the determination unit 2106, for verifying the verification code input into the specified device in the case of binding the specified device; the registering unit 2110 is connected to the second verifying unit 2108, and is configured to register the specified device as the first trusted device if the short message verification is successful.

It should be noted that the process of registering the first trusted device may also be performed by an authorization center, that is, the first registration module 2102 may exist in the authorization center. In the event of unsuccessful verification, the primary account number may be directed to bind the specified device.

It should be noted that, after the designated device is registered as a first trusted device, any user who hits the risk rule needs to perform a secondary security verification even on the trusted device, and the first registration module 2102 may further include: and the triggering unit is used for triggering the specified equipment to be subjected to security verification when detecting that the number of times of executing the operation with the same operation type as the specified operation exceeds a preset number of times within preset time, wherein after the security verification is passed, the specified equipment is continuously used as the first trusted equipment. The safety performance can be better improved through the mode of secondary safety verification by the trigger unit.

Similar to the first trusted device, it is also necessary to register the second trusted device, in an embodiment of the present application, fig. 22 is a block diagram six of a structure of a security authentication apparatus according to embodiment 3 of the present application, and as shown in fig. 22, the apparatus further includes: a second registration module 2202, configured to register the second trusted device with the sub-account, where the second registration module 2202 may include: an authentication unit 2204, configured to authenticate the sub-account and the password corresponding to the sub-account; a sending unit 2206, connected to the verifying unit 2204, and configured to send an authorization application request to the primary account to which the sub-account belongs if the verification is successful; a registering unit 2208, connected to the sending unit 2206, configured to register the specified device as the second trusted device if the primary account number authorization passes.

It should be noted that registering the second trusted device for the sub-account needs to be confirmed by authorization of the primary account, and the primary account can master operations of all the sub-accounts. The second trusted device also has a time-to-live, similar to the first trusted device, during which the designated device is treated as the second trusted device. That is, after the designated device is registered as the second trusted device, the designated device may not need to be verified again during the time-to-live. The time-to-live may be set by the authorization center at the time of registration, or a default time-to-live may be used, for example, within a default of 14 days, the designated device does not need to be securely authenticated.

In an alternative embodiment of the application, similar to registering as the first trusted device, any user hitting a risk rule needs to perform a secondary security verification even on the second trusted device, by being behind the designated device as the second trusted device. The second registration module 2202 may further include: and the triggering unit is used for triggering the designated equipment to be subjected to security verification when detecting that the number of times of executing the operation with the same operation type as the designated operation exceeds a preset number of times within preset time, wherein after the security verification is passed, the designated equipment is continuously used as the second trusted equipment. The triggering unit adopts the secondary safety verification mode to better improve the safety performance.

It should be noted that the first sending module 1706 is further configured to send the security verification request to the first trusted device when the type of the specified account is a primary account.

It should be noted that, when the type of the designated account is a sub-account, the first sending module 1706 may select to send the security verification request to the first trusted device, or may select to send the security verification request to the second trusted device; in the case where the type of the specified account is a primary account, first sending module 1706 may send a security verification request to the first trusted device. Therefore, although the sub-account number belongs to the primary account number, the sub-account number and the primary account number are independent from each other in the security verification process, that is, independent operation can be performed regardless of the primary account number or the sub-account number, and for the sub-account number, the server does not need to request the primary account number to assign the authority to the sub-account number.

A second receiving module 1708, connected to the first sending module 1706, configured to receive a verification result returned after the first trusted device or the second trusted device performs one-key verification on the security verification request, where the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

It should be noted that the verification result may include: confirming the verification is passed or rejected. After the verification is confirmed to pass, all operations from the specified account can be directly released without safety verification within a certain time period, and then after the verification passes through the trusted device, the operations do not need to be verified every time, so that the user experience is improved.

By the device, when the designated account number for performing the designated operation is the sub-account number under the primary account number, a security verification request for requesting to verify the designated operation is sent to the first trusted device or the second trusted device, and the first trusted device or the second trusted device performs one-key verification on the security verification request, the security verification request for performing the designated operation can be independently initiated through the sub-account number without authorization of the primary account number, and the first trusted device or the second trusted device verifies the security verification request in a one-key verification manner, so that the operation of inputting an account number password is avoided, and after verification is performed through the first trusted device or the second trusted device, identity authentication is not required when the operation is performed again, so that the purpose of simplifying a verification process is achieved, and the technical effect of rapid security verification is achieved, and further solve the technical problems of complicated and inconvenient safety authentication mode in the related technology.

Example 4

According to an embodiment of the present invention, there is further provided an apparatus for implementing the security authentication method of embodiment 2, and fig. 23 is a block diagram of a security authentication apparatus according to embodiment 4 of the present application, and as shown in fig. 23, the apparatus includes:

a receiving module 2302, configured to receive a security verification request sent by a server and used for requesting verification of a specified operation; the specified operation is a specified operation executed by a specified account; when the designated account is a sub-account subordinate to the primary account, the trusted device includes: the first trusted device is a trusted device registered by the primary account number, and the second trusted device is a trusted device registered by the sub-account number;

The verification module 2304 is connected with the receiving module 2302 and is used for performing one-key verification on the security verification request; wherein, the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

The apparatus is located in a trusted device, and may be a first trusted device or a second trusted device, but is not limited thereto.

Through the device, the first trusted device or the second trusted device is used for carrying out safety verification on the operation of the sub-account through one-key verification without inputting an account password, so that the aim of simplifying a verification process is fulfilled, the technical effect of quick safety verification is achieved, and the technical problems that a safety authentication mode in the related technology is complicated, inconvenient and quick are solved.

Example 5

The embodiment of the invention can provide a computer terminal which can be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal may also be replaced with a terminal device such as a mobile terminal.

Optionally, in this embodiment, the computer terminal may be located in at least one network device of a plurality of network devices of a computer network.

In this embodiment, the computer terminal may execute the program code of the following steps in the security authentication method for the application program: receiving an operation request sent by a specified account, wherein the operation request is used for indicating the specified account to execute specified operation; acquiring the type of a specified account; when the type of the designated account is a sub-account which is subordinate to the primary account, sending a security verification request for requesting verification of the designated operation to first trusted equipment or second trusted equipment, wherein the first trusted equipment is trusted equipment registered by the primary account, and the second trusted equipment is trusted equipment registered by the sub-account; and receiving a verification result returned after the first trusted device or the second trusted device performs one-key verification on the security verification request, wherein the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

Alternatively, fig. 24 is a block diagram of a computer terminal according to an embodiment of the present application. As shown in fig. 24, the computer terminal a may include: one or more processors (only one of which is shown), memory, and a transmission module.

The memory may be used to store software programs and modules, such as program instructions/modules corresponding to the security authentication method and apparatus in the embodiments of the present invention, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, the method for detecting a system vulnerability attack is implemented. The memory may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory may further include memory remotely located from the processor, and these remote memories may be connected to terminal a through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The processor can call the information and the application program stored in the memory through the transmission module to execute the following steps: receiving an operation request sent by a specified account, wherein the operation request is used for indicating the specified account to execute specified operation; acquiring the type of a specified account; when the type of the designated account is a sub-account which is subordinate to the primary account, sending a security verification request for requesting verification of the designated operation to first trusted equipment or second trusted equipment, wherein the first trusted equipment is trusted equipment registered by the primary account, and the second trusted equipment is trusted equipment registered by the sub-account; and receiving a verification result returned after the first trusted device or the second trusted device performs one-key verification on the security verification request, wherein the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

By adopting the embodiment of the invention, when the designated account number for carrying out the designated operation is the sub-account number under the primary account number, the security verification request for requesting to verify the designated operation is sent to the first trusted device or the second trusted device, and the first trusted device or the second trusted device carries out the one-key verification on the security verification request, the security verification request for carrying out the designated operation can be independently initiated through the sub-account number without authorization of the primary account number, and the first trusted device or the second trusted device verifies the security verification request in the one-key verification way, so that the operation of inputting the account number password is avoided, and after the verification is carried out through the first trusted device or the second trusted device, the identity authentication is not required when the operation is carried out again, thereby achieving the purpose of simplifying the verification process, and further realizing the technical effect of rapid security verification, and further solve the technical problems of complicated and inconvenient safety authentication mode in the related technology.

It can be understood by those skilled in the art that the structure shown in fig. 24 is only an illustration, and the computer terminal may also be a terminal device such as a smart phone (e.g., an Android phone, an iOS phone, etc.), a tablet computer, a palmtop computer, a Mobile Internet Device (MID), a PAD, and the like. Fig. 24 is a diagram illustrating a structure of the electronic device. For example, the computer terminal a may also include more or fewer components (e.g., network interfaces, display devices, etc.) than shown in fig. 24, or have a different configuration than shown in fig. 24.

Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by a program instructing hardware associated with the terminal device, where the program may be stored in a computer-readable storage medium, and the storage medium may include: flash disks, Read-Only memories (ROMs), Random Access Memories (RAMs), magnetic or optical disks, and the like.

Example 6

In this embodiment, the computer terminal may execute the program code of the following steps in the security authentication method for the application program: receiving a security verification request which is sent by a server and used for requesting to verify the specified operation; wherein, the specified operation is the specified operation executed by the specified account; performing one-key verification on the security verification request; wherein, the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

It should be noted that, when the specified account is a sub-account under the primary account, the trusted device includes: the device comprises a first trusted device or a second trusted device, wherein the first trusted device is a trusted device registered by the primary account number, and the second trusted device is a trusted device registered by the sub-account number. The computer terminal may act as the trusted device.

The structure of the computer terminal is similar to that in embodiment 5, and includes a processor, a memory, and a transmission module, and the specific functions are similar, and the processor can call the information and the application program stored in the memory through the transmission module to execute the following steps: receiving a security verification request which is sent by a server and used for requesting to verify the specified operation; wherein, the specified operation is the specified operation executed by the specified account; performing one-key verification on the security verification request; wherein, the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

Through the embodiment, the operation of the sub-account is verified through one-key verification by adopting the first trusted device or the second trusted device, the account password does not need to be input, and the purpose of simplifying the verification process is achieved, so that the technical effect of quick safety verification is achieved, and the technical problem that the safety authentication mode in the related technology is complicated, inconvenient and quick is solved.

Example 7

The embodiment of the invention also provides a storage medium. Optionally, in this embodiment, the storage medium may be configured to store a program code executed by the security authentication method provided in the first embodiment.

Optionally, in this embodiment, the storage medium may be located in any one of computer terminals in a computer terminal group in a computer network, or in any one of mobile terminals in a mobile terminal group.

Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: receiving an operation request sent by a specified account, wherein the operation request is used for indicating the specified account to execute specified operation; acquiring the type of a specified account; when the type of the designated account is a sub-account which is subordinate to the primary account, sending a security verification request for requesting verification of the designated operation to first trusted equipment or second trusted equipment, wherein the first trusted equipment is trusted equipment registered by the primary account, and the second trusted equipment is trusted equipment registered by the sub-account; and receiving a verification result returned after the first trusted device or the second trusted device performs one-key verification on the security verification request, wherein the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

Alternatively, the storage medium is configured to store program code for performing the steps of: receiving a security verification request which is sent by a server and used for requesting to verify the specified operation; wherein, the specified operation is the specified operation executed by the specified account; performing one-key verification on the security verification request; wherein, the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction. When the specific account is a sub-account subordinate to the primary account, the trusted device includes: the device comprises a first trusted device or a second trusted device, wherein the first trusted device is a trusted device registered by the primary account number, and the second trusted device is a trusted device registered by the sub-account number. The computer terminal may act as the trusted device.

The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.

In the above embodiments of the present invention, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the embodiments provided in the present application, it should be understood that the disclosed technology can be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, units or modules, and may be in an electrical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.

The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and decorations can be made without departing from the principle of the present invention, and these modifications and decorations should also be regarded as the protection scope of the present invention.

Claims

1. A method of secure authentication, comprising:

receiving an operation request sent by a specified account, wherein the operation request is used for indicating the specified account to execute specified operation;

acquiring the type of the specified account;

when the type of the specified account is a sub-account subordinate to a primary account, sending a security verification request for requesting verification of the specified operation to first trusted equipment or second trusted equipment, wherein the first trusted equipment is trusted equipment registered by the primary account, and the second trusted equipment is trusted equipment registered by the sub-account through authorization of the primary account;

and receiving a verification result returned after the first trusted device or the second trusted device performs one-key verification on the security verification request, wherein the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

2. The method of claim 1, further comprising:

and when the type of the specified account is a primary account, sending the security verification request to the first trusted device.

3. The method of claim 1, wherein sending a security verification request to the first trusted device or the second trusted device requesting verification of the specified operation comprises:

under the condition that the second trusted device corresponding to the sub-account exists and the one-key verification function is started, selecting a trusted device from the first trusted device and the second trusted device according to a preset priority, and sending a security verification request to the selected trusted device;

sending the security verification request to the first trusted device in the absence of the second trusted device corresponding to the sub-account.

4. The method of claim 3, wherein the first trusted device has a lower priority than the second trusted device.

5. The method of claim 1, wherein prior to obtaining the type of the specified account number, the method further comprises:

and sending first indication information to a terminal logged by the specified account under the condition that the trusted device corresponding to the specified account does not exist or the one-key verification function is not started, wherein the first indication information is used for indicating the specified account to register the trusted device corresponding to the specified account.

6. The method according to claim 1, wherein after receiving the operation request sent by the specific account, the method further comprises:

acquiring the operation type of the specified operation;

under the condition that the operation type is a specified type, triggering to acquire the type of the specified account;

and sending second indication information to the terminal logged by the specified account under the condition that the specified operation is not of the specified type, wherein the second indication information is used for indicating the terminal logged by the specified account to pass the specified operation.

7. The method of claim 1, wherein the primary account number registers the first trusted device by:

verifying the primary account number and a password corresponding to the primary account number;

under the condition of successful verification, judging whether the primary account number is bound with the specified equipment or not;

verifying the verification code input into the specified equipment under the condition of binding the specified equipment;

registering the designated device as the first trusted device if the verification is successful.

8. The method of claim 7, wherein the first trusted device has a time-to-live, wherein the designated device is treated as the first trusted device for the time-to-live.

9. The method of claim 7, wherein after registering the designated device as the first trusted device, the method further comprises:

and in a preset time, under the condition that the number of times of executing the operation with the same operation type as the specified operation is detected to exceed a preset number of times, triggering the specified device to be subjected to security verification, wherein after the security verification is passed, the specified device is continuously used as the first trusted device.

10. The method of claim 1, wherein the sub-account number registers the second trusted device by:

verifying the sub-account and the password corresponding to the sub-account;

under the condition of successful verification, sending an authorization application request to a primary account number to which the sub-account number belongs;

and under the condition that the authorization of the primary account number passes, registering the specified device as the second trusted device.

11. The method according to any one of claims 1 to 10, wherein the verification result comprises: confirming the verification is passed or rejected.

12. The method according to claim 11, wherein after the validation is passed, the terminal logged in by the specified account is instructed to pass all operations from the specified account.

13. A method of secure authentication, comprising:

the method comprises the steps that a trusted device of a specified account receives a security verification request which is sent by a server and used for requesting verification of specified operation; the specified operation is a specified operation executed by the specified account; when the specified account is a sub-account subordinate to the primary account, the trusted device includes: the first trusted device is a trusted device registered by the primary account number, and the second trusted device is a trusted device registered by the sub-account number through authorization of the primary account number;

the trusted device performs one-key verification on the security verification request; the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

14. The method of claim 13, comprising: when the designated account is the primary account, the trusted device includes: the first trusted device.

15. A security authentication apparatus, comprising:

the system comprises a first receiving module, a second receiving module and a third receiving module, wherein the first receiving module is used for receiving an operation request sent by a specified account, and the operation request is used for indicating the specified account to execute specified operation;

the acquisition module is used for acquiring the type of the specified account;

a first sending module, configured to send, to a first trusted device or a second trusted device, a security verification request for requesting verification of the specified operation when the type of the specified account is a sub-account subordinate to a primary account, where the first trusted device is a trusted device registered by the primary account, and the second trusted device is a trusted device registered by the sub-account through authorization of the primary account;

and the second receiving module is used for receiving a verification result returned after the first trusted device or the second trusted device performs one-key verification on the security verification request, wherein the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

16. The apparatus of claim 15, wherein the first sending module is further configured to send the security verification request to the first trusted device when the type of the specified account is a primary account.

17. The apparatus of claim 15, wherein the first sending module comprises:

a first sending unit, configured to, when the second trusted device corresponding to the sub-account already exists and the one-key authentication function has been started, select a trusted device from the first trusted device and the second trusted device according to a preset priority, and send a security authentication request to the selected trusted device; wherein the preset priority comprises: the priority of the first trusted device is lower than the priority of the second trusted device;

a second sending unit, configured to send the security verification request to the first trusted device when the second trusted device corresponding to the sub-account does not exist.

18. The apparatus of claim 15, further comprising:

the second sending module is used for sending first indication information to a terminal logged in by the specified account under the condition that the trusted device corresponding to the specified account does not exist or the one-key verification function is not started; the first indication information is used for indicating the specified account to register the trusted device corresponding to the specified account.

19. The apparatus of claim 15, further comprising:

the acquisition module is used for acquiring the operation type of the specified operation;

the triggering module is used for triggering and judging the type of the specified account under the condition that the operation type is the specified type;

and a third sending module, configured to send second indication information to the terminal logged by the specified account if the specified operation is not the specified type, where the second indication information is used to indicate that the terminal logged by the specified account passes the specified operation.

20. The apparatus of claim 15, further comprising: a first registration module, configured to register the first trusted device with the primary account, where the first registration module includes:

the first verification unit is used for verifying the primary account number and the password corresponding to the primary account number;

the judging unit is used for judging whether the primary account number is bound with the specified equipment or not under the condition of successful verification;

a second verification unit, configured to verify a verification code input to the specified device in a case where the specified device is bound;

a registering unit, configured to register the designated device as the first trusted device if the verification is successful.

21. The apparatus of claim 20, wherein the first trusted device has a time-to-live, and wherein the designated device is treated as the first trusted device for the time-to-live.

22. The apparatus of claim 20, wherein the first registration module further comprises:

and the triggering unit is used for triggering the specified equipment to be subjected to security verification when detecting that the number of times of executing the operation with the same operation type as the specified operation exceeds a preset number of times within preset time, wherein after the security verification is passed, the specified equipment is continuously used as the first trusted equipment.

23. The apparatus of claim 15, further comprising: a second registration module, configured to register the second trusted device with the sub-account, where the second registration module includes:

the verification unit is used for verifying the sub-account and the password corresponding to the sub-account;

a sending unit, configured to send an authorization application request to a primary account to which the sub-account belongs, if the verification is successful;

and the registration unit is used for registering the specified device as the second trusted device under the condition that the authorization of the primary account number passes.

24. The apparatus according to any one of claims 15 to 23, wherein the verification result comprises: confirming the verification is passed or rejected.

25. An apparatus for secure authentication, located in a trusted device, the apparatus comprising:

the receiving module is used for receiving a security verification request which is sent by the server and used for requesting to verify the specified operation; the specified operation is a specified operation executed by a specified account; when the specified account is a sub-account subordinate to the primary account, the trusted device includes: the first trusted device is a trusted device registered by the primary account number, and the second trusted device is a trusted device registered by the sub-account number through authorization of the primary account number;

the verification module is used for performing one-key verification on the security verification request; the one-key verification is a verification process triggered after a special button on the trusted device receives a trigger instruction.

26. The apparatus of claim 25, wherein when the designated account number is the primary account number, the trusted device comprises: the first trusted device.