CN106453352A - Single-system multi-platform authentication method - Google Patents

Abstract

The invention discloses a single-system multi-platform identity verification method, comprising the following steps: S1, the server obtains the user name and user password used by the client computer to log in; S2, the server receives the access request and ciphertext sent by the client computer; S3, the server Verify the ciphertext, enter step S4 after the verification is successful, and execute the first adjustment plan if the verification is unsuccessful; S4, the server parses the ciphertext, and determines whether there is an error in the current operation according to the protocol content of each client, if there is no error, then enter step S5, Otherwise, execute the second adjustment solution; S5. The server returns a receipt for allowing the client to access the restricted resource, and re-encrypts the message. The identity verification method of the present invention will not leave customer information on the server, adopts the encryption method to circulate, modify the characters, use the crawler engine to hit the database, or use expired ciphertexts will generate attack warnings, which can effectively reduce the risk of using the cache and use the session session The resulting session fixation attack risk.

Description

A single-system multi-platform authentication method

technical field

The invention belongs to the technical field of identity verification, in particular to a single-system multi-platform identity verification method.

Background technique

There are four authentication methods in the Web: Basic, Form, Digest, SSL:

1. Basic (proposed by HTTP 1.0)

After the client requests a certain resource, the server will send a 401 (unauthorized) response with Realm information in the response indicating that Basic authentication is used.

After the browser receives this response, a box will pop up to enter the user name and password. Click Cancel to cancel the authentication, and click OK to submit the user name and password to the server. The way to submit is to add in the HTTP header:

WWW-Authorization: Basic XXXXXXXX

Basic is followed by the BASE64 encoding of the username and password. In client programming, this content is constructed as:

String cre＝userName+":"+password

Base64encode(cre);

add to request header with "WWW-Authroization".

2. Form

Form is to submit data in the form of Form on the page, GET or POST. You can also use AJAX to submit authentication information.

3. Digest (HTTP 1.1 is the most basic)

To prevent replay attacks, digest access authentication is used. After the client sends a request, it receives a 401 message, which also includes a unique string: nonce, which is different for each request. Such as,

HTTP/1.1 401 Unauthorized

WWW-Authenticate:Digest

realm="xxxxxxx",

qop="auth,auth-int",

nonce="--base code--",

opaque="--base code--"

At this time, the client returns the digest of the user name, password, nonce, HTTP Method and URI as the check value based on the hash (MD5 by default) to the server. The 5 parts that the response header must include:

realm: realm, different realms may have different passwords

nonce: challenge value

username: username

digest-uri: Request URI

response: summary section

The server side calculates a new digest based on the received information plus the stored password and compares it with the digest in the request, because the nonce will change every time, so it is difficult to achieve replay attacks.

4. SSL

The SSL protocol is located between TCP/IP and application protocols, and ensures the security of data communication based on the public key system. The SSL protocol can be divided into two layers: SSL Record Protocol (SSL Record Protocol): It is built on a reliable transmission protocol (such as TCP) and provides support for basic functions such as data encapsulation, compression, and encryption for high-level protocols. SSL Handshake Protocol (SSLHandshake Protocol): It is built on the SSL record protocol and is used for identity authentication, negotiation of encryption algorithms, and exchange of encryption keys before the actual data transmission begins.

The services provided by the SSL protocol mainly include:

1) Authenticate users and servers to ensure that data is sent to the correct client and server;

2) Encrypt data to prevent data from being stolen;

3) Maintain data integrity and ensure that data is not changed during transmission.

The biggest problem among the above four basic authentication methods is that identity authentication can only be maintained at the level of data encryption and sessions, but cannot synchronize system content between different platforms. Secondly, it is impossible to identify whether the user's login failure behavior and session failure process are caused by wrong operations or attacks.

Contents of the invention

The purpose of the present invention is to overcome the deficiencies of the prior art, to provide a method that does not leave customer information on the server, adopts an encryption method to circulate, modify characters, use a crawler engine to hit a library, or use an expired ciphertext to generate an attack warning, which can effectively reduce The risk of using cache and the risk of session fixation attack caused by using session session can improve the efficiency and security of authentication in a single-system multi-platform authentication method.

The purpose of the present invention is achieved through the following technical solutions: a single-system multi-platform identity verification method, comprising the following steps:

S1. The server obtains the user name and user password used by the client to log in, and then accesses the database to find out whether the user exists. If it exists, it provides the ciphertext for the user, otherwise it prompts an error and requires the client to log in again;

S2. The server receives the access request for restricted resources sent by the client, and receives the ciphertext submitted by the user;

S3. The server verifies the ciphertext, and proceeds to step S4 after the verification is successful, and executes the first adjustment scheme if the verification is unsuccessful;

S4, the server parses the ciphertext, queries the content of the relevant fields according to the information of the client requesting access, and determines whether there is an error in the current operation according to the protocol content of each client, if there is no error, then enter step S5, otherwise execute the second adjustment plan;

S5. The server returns a receipt for allowing the client computer to access the restricted resource, re-encrypts the ciphertext, and resends the encrypted ciphertext to the client computer.

Further, the step S1 specifically includes the following sub-steps:

S11, the server obtains the user name and user password used when the client logs in, accesses the database to find out whether the user exists, if it exists, executes step S12, otherwise prompts an error and requires the client to log in again;

S12, extracting the client object from the database, extracting the token field, if the token field is empty, then execute step S13, otherwise execute step S14;

S13. Using the put method, add the identification information of the current client, the current time stamp, and the platform information of the currently logged-in client into a string-string graph, encrypt the string-string graph into ciphertext, and insert cache;

S14, parse the token field, restore the token field to plaintext, extract the agent field from the header of the message requesting login, access the specified field as a key value, and modify it to the specified content; then modify the LastLogin field to the current timestamp; after modification Then encrypt it into ciphertext and put it in the cache;

S15. Return the login success information, and add the ciphertext to the header of the returned message as the ciphertext credential for the client to request to access the idle resource.

Further, the encryption process of step S13 includes the following sub-steps:

S131. To obtain the device type of the client, you can use the content in the DeviceFamily namespace to obtain it, and use the put method to add a string—in the string map SecretMap, the key value is: device;

S132, obtain the time when the current program package is installed, you can use the content in the Package namespace to obtain, use the put method to add a string—in the string map SecretMap, the key value is: install;

S133. Obtain the system time, and use the put method to add a character string into the SecretMap of the character string map, and the key value is: send;

S134. Encrypt the string-string map SecretMap in JSON format, the secret words used are defined during program development, and are hard-coded and stored by the client and server.

Further, verifying the ciphertext in the step S3 includes the following sub-steps:

S31. The server parses the header information of the HTTP request message, extracts the verification protocol agreement field therein, and executes S32 if the extraction is successful, otherwise executes S36;

S32. Decrypt the extracted verification protocol agreement field to obtain the structure of the string-string map, which is called StatusMap, extract the client agent field in the HTTP request message, and obtain the platform where the client is located in sequence;

S33. Determine the platform used by the client, if it is a web platform, execute step S331, if it is a non-web platform, execute step S333;

S331, extract the web field from the StatusMap as the verification content, analyze whether there is an error in the agreement content, if the agreement content is correct, then proceed to step S332; if the agreement content is wrong, then report an error, and report a protocol content error record, and then perform step S34;

S332, judging whether the protocol content is overtime compared with the current timestamp, if overtime occurs, an error is reported, and an outdated error record is reported, and then step S34 is performed; if not overtime, the timer is updated, and then step S35 is performed;

S333. Extract the response field as the verification content, maintain the persistent login information according to the content of the respective agreements, and judge whether the login information is successfully verified, and if the verification is successful, execute step S35; otherwise, report an error, and report a login error record, and then execute step S34;

S34, prompting the client computer for error information, and requesting to log in again;

S35. Regenerate the message, and encrypt the message according to the protocol content between the server and the client, and add the new message to the pretoken field in the server response message;

S36. Failure to extract the verification protocol agreement field or verification failure of the verification agreement agreement field means that an expired protocol message is used, indicating that the attack method of session fixation is received, and the server generates an attack warning and puts it into the server log;

S37. Extract the content of the client identity information in the StatusMap, and use it as a token in the business logic.

Further, the first adjustment solution in step S3 is specifically: analyze the verification result, check whether there is a syntax error in the ciphertext, and if so, generate an attack warning, put the current agent information and IP address information into the dangerous client source and Output to the log, and prompt an error message, requiring the client to re-provide the ciphertext;

If there is no ciphertext syntax error, check the request information in the HTTP message segment, analyze whether the agent and IP address in the message come from a dangerous client source, if so, generate an attack warning, and output the information to the log, and then request The client provides the ciphertext again; otherwise, an error message is displayed and the client is required to provide the ciphertext again.

Further, parsing the ciphertext in the step S4 includes the following sub-steps:

S41. Receive the access request message and ciphertext sent by the client, and obtain the received time stamp of the message and ciphertext, which is recorded as current;

S42. Analyze the ciphertext according to the agreed password to obtain the SecretMap. If the analysis is successful, step S43 is executed; otherwise, an attack warning is generated, and the agent information and IP address information in the current access request message are put into the dangerous client source and output to the log, and sent to the client. The machine prompts an error;

S43. Analyze the send field in the SecretMap and compare it with the current. If the current is earlier than the send or the difference between the current and the send exceeds 2 times the average network delay, it is considered to be under a credential stuffing attack, an attack warning is generated, and the current agent information is updated. and IP address information are put into the dangerous customer source and output to the log, prompting an error; otherwise, step S44 is performed;

S44, parsing the device section and the install field in the SecretMap, querying the server whether the client computer is a trusted client computer through the device section and the install field, if so, the ciphertext is verified, otherwise step S45 is performed;

S45. Check the operation of the client computer that sends the access request message: if it is a login request, the client computer is prompted and warned, and the client computer is required to provide a credible login operation certificate for verification. After the verification is passed, the current information is added to the server for verification. store, and identify the client as a trusted client, the ciphertext has passed the verification, if the verification fails, an untrusted operation warning will be sent to the currently online client, and an attack warning will be generated at the same time, and the current agent information and IP The address information is put into the dangerous client source and output to the log, prompting an error; if the client computer is performing other operations except the login request, an untrustworthy operation warning will be sent to the currently online client computer, and an attack warning will be generated at the same time, and the current Agent information and IP address information are placed in the source of dangerous customers and output to the log, prompting an error.

Further, the second adjustment scheme in step S4 is specifically: judge the current error type, if it is a timeout error, then prompt an error, require the client to log in again, and jump to the login page; if it is a ciphertext error, generate an attack warning , put the current agent information and IP address information into the dangerous client source and output it to the log, prompting an error.

The beneficial effects of the present invention are: the present invention is specially optimized for the traditional security problem of remembering the user login status and leaving relevant information on the server and the situation that the multi-platform states of a single system and multiple platforms are likely to be crowded with each other. The identity verification method will not leave customer information on the server, and the encryption method will be used to circulate. Modifying characters, using a crawler engine to hit the library, or using expired ciphertext will generate attack warnings, which can effectively reduce the risk of using the cache and the session caused by the use of the session. Fixed attack risk, will not be attacked by CSRF, can improve the efficiency and security of authentication.

Description of drawings

Fig. 1 is the single-system multi-platform authentication method flow chart of the present invention;

Fig. 2 is the flow chart of client machine login of the present invention;

Fig. 3 is the encryption flowchart of the present invention;

Fig. 4 is the verification ciphertext flowchart of the present invention;

Fig. 5 is a flow chart of analyzing ciphertext in the present invention.

detailed description

The technical solution of the present invention will be further described below in conjunction with the accompanying drawings.

As shown in Figure 1, a single-system multi-platform authentication method includes the following steps:

S1. The server obtains the user name and user password used when the client logs in, and then accesses the database to find out whether the user exists. If it exists, the user is provided with a ciphertext, otherwise an error is prompted and the client is required to log in again; as shown in Figure 2, Specifically include the following sub-steps:

S11, the server obtains the user name and user password used when the client logs in, accesses the database to find out whether the user exists, if it exists, executes step S12, otherwise prompts an error and requires the client to log in again;

S12, extracting the client object from the database, extracting the token field, if the token field is empty, then execute step S13, otherwise execute step S14;

S13. Using the put method, add the identification information of the current client, the current time stamp, and the platform information of the currently logged-in client into a string-string graph, encrypt the string-string graph into ciphertext, and insert cache;

The agent field of the client developed under the .net framework is uniformly set to UWP, the client agent field developed under the Android system is uniformly set to ADW, and the client agent field developed under the IOS system is uniformly set to IOS. The specific namespace (or called package) for example with UWP as a reference. As shown in Figure 3, the encryption process includes the following sub-steps:

S131. To obtain the device type of the client, you can use the content in the DeviceFamily namespace to obtain it, and use the put method to add a string—in the string map SecretMap, the key value is: device;

S132, obtain the time when the current program package is installed, you can use the content in the Package namespace to obtain, use the put method to add a string—in the string map SecretMap, the key value is: install;

S133. Obtain the system time, and use the put method to add a character string into the SecretMap of the character string map, and the key value is: send;

S134. Encrypt the string-string map SecretMap in JSON format, the secret words used are defined during program development, and are hard-coded and stored by the client and server.

S14, parse the token field, restore the token field to plaintext, extract the agent field from the header of the message requesting login, access the specified field as a key value, and modify it to the specified content; then modify the LastLogin field to the current timestamp; after modification Then encrypt it into ciphertext and put it in the cache;

S15. Return the login success information, and add the ciphertext to the header of the returned message as the ciphertext credential for the client to request to access the idle resource.

S2. The server receives the access request for restricted resources sent by the client, and receives the ciphertext submitted by the user;

S3. The server verifies the ciphertext, and proceeds to step S4 after the verification is successful, and executes the first adjustment scheme if the verification is unsuccessful;

As shown in Figure 4, the verification ciphertext includes the following sub-steps:

S31. The server parses the header information of the HTTP request message, extracts the verification protocol agreement field therein, and executes S32 if the extraction is successful, otherwise executes S36;

S32. Decrypt the extracted verification protocol agreement field to obtain the structure of the string-string map, which is called StatusMap, extract the client agent field in the HTTP request message, and obtain the platform where the client is located in sequence;

S33. Determine the platform used by the client, if it is a web platform, execute step S331, if it is a non-web platform, execute step S333;

S331, extract the web field from the StatusMap as the verification content, analyze whether there is an error in the agreement content, if the agreement content is correct, then proceed to step S332; if the agreement content is wrong, then report an error, and report a protocol content error record, and then perform step S34;

S332, judging whether the protocol content is overtime compared with the current timestamp, if overtime occurs, an error is reported, and an outdated error record is reported, and then step S34 is performed; if not overtime, the timer is updated, and then step S35 is performed;

S333. Extract the response field as the verification content, maintain the persistent login information according to the content of the respective agreements, and judge whether the login information is successfully verified, and if the verification is successful, execute step S35; otherwise, report an error, and report a login error record, and then execute step S34;

S34, prompting the client computer for an error message, and requesting to log in again;

S35. Regenerate the message, and encrypt the message according to the protocol content between the server and the client, and add the new message to the pretoken field in the server response message;

S36. Failure to extract the verification protocol agreement field or verification failure of the verification agreement agreement field means that an expired protocol message is used, indicating that the attack method of session fixation is received, and the server generates an attack warning and puts it into the server log;

S37. Extract the content of the client identity information in the StatusMap, and use it as a token in the business logic.

The first adjustment scheme is specifically: analyze the verification result, check whether there is a ciphertext syntax error (SyntaxException), if there is an attack warning, put the current agent information and IP address information into the dangerous client source and output it in the log , and prompts an error message, requiring the client to provide the ciphertext again;

If there is no ciphertext syntax error, check the request information in the HTTP message segment, analyze whether the agent and IP address in the message come from a dangerous client source, if so, generate an attack warning, and output the information to the log, and then request The client provides the ciphertext again; otherwise, an error message is displayed and the client is required to provide the ciphertext again.

S4, the server parses the ciphertext, queries the content of the relevant fields according to the information of the client requesting access, and determines whether there is an error in the current operation according to the protocol content of each client, if there is no error, then enter step S5, otherwise execute the second adjustment plan;

As shown in Figure 5, parsing the ciphertext includes the following sub-steps:

S41. Receive the access request message and ciphertext sent by the client, and obtain the received time stamp of the message and ciphertext, which is recorded as current;

S42. Analyze the ciphertext according to the agreed password to obtain the SecretMap. If the analysis is successful, step S43 is executed; otherwise, an attack warning is generated, and the agent information and IP address information in the current access request message are put into the dangerous client source and output to the log, and sent to the client. The machine prompts an error;

S43. Analyze the send field in the SecretMap and compare it with the current. If the current is earlier than the send or the difference between the current and the send exceeds 2 times the average network delay, it is considered to be under a credential stuffing attack, an attack warning is generated, and the current agent information is updated. and IP address information are put into dangerous customer sources and output to the log, prompting an error; otherwise, step S44 is performed;

S44, parsing the device section and the install field in the SecretMap, querying the server whether the client computer is a trusted client computer through the device section and the install field, if so, the ciphertext is verified, otherwise step S45 is performed;

S45. Check the operation of the client computer that sends the access request message: if it is a login request, the client computer is prompted and warned, and the client computer is required to provide a credible login operation certificate for verification. After the verification is passed, the current information is added to the server for verification. store, and identify the client as a trusted client, the ciphertext has passed the verification, if the verification fails, an untrusted operation warning will be sent to the currently online client, and an attack warning will be generated at the same time, and the current agent information and IP The address information is put into the dangerous client source and output to the log, prompting an error; if the client computer is performing other operations except the login request, an untrustworthy operation warning will be sent to the currently online client computer, and an attack warning will be generated at the same time, and the current Agent information and IP address information are placed in the source of dangerous customers and output to the log, prompting an error.

The second adjustment scheme is specifically: judge the current error type, if it is an overtime error (OvertimeException), it will prompt an error, require the client to log in again, and jump to the login page; if it is a ciphertext error (ProtocolException), an attack warning will be generated, Put the current agent information and IP address information into the dangerous client source and output it to the log, prompting an error.

S5. The server returns a receipt for allowing the client computer to access the restricted resource, re-encrypts the ciphertext, and resends the encrypted ciphertext to the client computer.

Those skilled in the art will appreciate that the embodiments described here are to help readers understand the principles of the present invention, and it should be understood that the protection scope of the present invention is not limited to such specific statements and embodiments. Those skilled in the art can make various other specific modifications and combinations based on the technical revelations disclosed in the present invention without departing from the essence of the present invention, and these modifications and combinations are still within the protection scope of the present invention.

Claims (7)

1. a kind of multi-platform auth method of single system is it is characterised in that comprise the following steps：

S1, server obtain the user name using during client logon and user cipher, then access this user of database lookup Whether there is, if existing, providing ciphertext for this user, otherwise point out mistake and require client computer again to log in；

The access request for restriction resource that S2, server subscribing client send, and the ciphertext that receive user is submitted to；

S3, server authentication ciphertext, enter step S4 after being proved to be successful, checking is unsuccessful, executes the first Adjusted Option；

S4, server parsing ciphertext, the client information inquiry relevant field content being accessed according to request, according to each client computer Protocol contents determine that current operation whether there is mistake, then enter step S5 without mistake, otherwise execute the second adjustment side Case；

S5, server return and allow client computer to access the receipt limiting resource, and encrypted cipher text again, the ciphertext that encryption is completed Resend to client computer.

2. the multi-platform auth method of single system according to claim 1 is it is characterised in that described step S1 is specifically wrapped Include following sub-step：

S11, server obtain the user name using during client logon and user cipher, whether access this user of database lookup Exist, if existing, execution step S12, otherwise pointing out mistake and requiring client computer again to log in；

S12, extract this client objects from data base, extract token field, if token field is sky, execution step S13, otherwise execution step S14；

S13, use put method, by the identification information of current client, current time stamp, the current platform letter logging in client computer Breath is added to a string characters string in figure, string characters string figure is encrypted to ciphertext, inserts caching；

S14, parsing token field, token field is reduced in plain text, extract agent word from the stem asking the message logging in Section, accesses specific field as key assignments, is revised as given content；Changing LastLogin field again is current time stamp；Repair It is encrypted to ciphertext after having changed, insert caching；

S15, return login successfully information, and stem ciphertext being added to returned packet accesses slack resources as client requests Ciphertext voucher.

3. the multi-platform auth method of single system according to claim 2 is it is characterised in that described step S13 is encrypted Process includes following sub-step：

S131, the device type of acquisition client computer, are added in string characters string figure SecretMap using put method；

S132, acquisition present procedure are coated the time of installation, add string characters string figure SecretMap using put method In；

S133, acquisition system time, are added in string characters string figure SecretMap using put method；

S134, with JSON form, string characters string figure SecretMap is encrypted, the cipher of use determined by during program development Justice, is preserved by client-server hard coded.

4. the multi-platform auth method of single system according to claim 3 is it is characterised in that verify in described step S3 Ciphertext includes following sub-step：

S31, server parse the header information of HTTP request message, extract indentification protocol agreement field therein, extract successfully Execution S32, otherwise executes S36；

S32, the indentification protocol extracted agreement field is decrypted, obtains the structure of character string-character string figure, be called StatusMap, extracts the client proxy field in HTTP request message, obtains the platform residing for client computer successively；

S33, judge client computer use platform, if web platform then execution step S331, if non-web platform then executes step Rapid S333；

S331, from StatusMap extract web field as checking content, analyse whether that protocol contents mistake occurs, if agreement Content is errorless, carries out step S332；If protocol contents are wrong, reported an error, and reported a protocol contents error logging, so Execution step S34 afterwards；

S332, judge protocol contents whether time-out compared with current time stamp, then reported an error if there is time-out, and report one Secondary time-out error record, then execution step S34；If having not timed out, update intervalometer, then execution step S35；

S333, extraction response field, as checking content, safeguard lasting log-on message according to respective protocol contents, judge to log in letter Whether breath is proved to be successful, if being proved to be successful, execution step S35；Otherwise reported an error, and report and once log in error logging, so Execution step S34 afterwards；

S34, prompting Client Error information, and require again to log in；

S35, regenerate message, and according to the protocol contents of server and client computer, message is encrypted, by new message Add the pretoken field in server response message；

S36, indentification protocol agreement field or indentification protocol agreement field authentication failed cannot be extracted it is meant that employing expired association View message, represents and receives the fixing attack pattern of session, and server produces attacks warning, is placed into server log；

Client identity information content in S37, extraction StatusMap, and as the token in service logic.

5. the multi-platform auth method of single system according to claim 4 it is characterised in that in described step S3 One Adjusted Option is specially：Analysis verification result, checks whether there is ciphertext syntax error, if existing, producing and attacking warning, Current agent information and IP address information are inserted dangerous client source and export in daily record, and point out error message it is desirable to Client computer provides ciphertext again；

If there is not ciphertext syntax error, check the solicited message in HTTP message section, agent and IP address in analysis message Whether from dangerous client source, if it is produce and attack warning, and by information output in daily record, then require client again Ciphertext is provided；Otherwise prompting error message is it is desirable to client provides ciphertext again.

6. the multi-platform auth method of single system according to claim 5 is it is characterised in that parse in described step S4 Ciphertext includes following sub-step：

Access request message and ciphertext that S41, subscribing client send, obtain the timestamp that message and ciphertext receive, are designated as current；

S42, parsing ciphertext of being talked secretly according to agreement obtain SecretMap, if successfully resolved execution step S43, otherwise produce and attack Warning, the agent information in current access request message and IP address information is inserted dangerous client source and exports in daily record, Point out mistake to client computer；

Send field in S43, parsing SecretMap, and is compared with current, if there is current early than send or The difference of current and send is attacked then it is assumed that being hit storehouse more than 2 times of averaging network time delays, produces and attacks warning, will be current Agent information and IP address information are inserted dangerous traveller and are exported in daily record, point out mistake；Otherwise execution step S44；

Device section in S44, parsing SecretMap and install field, by device section and install field to clothes Business device inquires about whether this client computer is trusted client, and if it is this ciphertext passes through checking, otherwise execution step S45；

S45, inspection send the operation of the client computer of access request message：If logging request then carries out prompting police to client computer Accuse it is desirable to client computer provides credible register to prove to be verified, after being verified, current information is added in server Stored, and this client identifying is trusted client, this ciphertext is passed through checking, does not pass through if verifying, exists to current The client computer of line sends insincere operation warning, produces simultaneously and attacks warning, current agent information and IP address information are put Enter dangerous client source and export in daily record, point out mistake；If client computer is carrying out other behaviour in addition to log on request Make, send insincere operation warning to currently online client computer, produce simultaneously and attack warning, by current agent information and IP address information is inserted dangerous client source and is exported in daily record, points out mistake.

7. the multi-platform auth method of single system according to claim 6 it is characterised in that in described step S4 Two Adjusted Option are specially：Judge current erroneous type, then point out mistake it is desirable to client computer is stepped on again if overtime class mistake Record, redirects login page；Then produce attack warning if ciphertext mistake, current agent information and IP address information are put Enter dangerous client source and export in daily record, point out mistake.