CN106453352B - Single-system multi-platform identity authentication method - Google Patents
Single-system multi-platform identity authentication method Download PDFInfo
- Publication number
- CN106453352B CN106453352B CN201610933435.0A CN201610933435A CN106453352B CN 106453352 B CN106453352 B CN 106453352B CN 201610933435 A CN201610933435 A CN 201610933435A CN 106453352 B CN106453352 B CN 106453352B
- Authority
- CN
- China
- Prior art keywords
- client
- ciphertext
- information
- current
- field
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
Abstract
The invention discloses a single-system multi-platform identity authentication method, which comprises the following steps: s1, the server acquires a user name and a user password used when the client logs in; s2, the server receives the access request and the ciphertext sent by the client; s3, the server verifies the ciphertext, the step S4 is carried out after the verification is successful, and a first adjusting scheme is executed if the verification is unsuccessful; s4, the server analyzes the ciphertext, determines whether the current operation has errors according to the protocol content of each client, if not, the step S5 is carried out, otherwise, a second adjustment scheme is executed; s5, the server returns the receipt of allowing the client to access the restricted resource and re-encrypts the message. The identity authentication method of the invention can not leave client information on the server, adopts an encryption mode to circulate, can generate attack warning by modifying characters, using a crawler engine to hit a library or using an expired ciphertext, and can effectively reduce the risk of using cache and the risk of session fixed attack caused by using session.
Description
Technical Field
The invention belongs to the technical field of identity authentication, and particularly relates to a single-system multi-platform identity authentication method.
Background
Four authentication methods are included in the Web: basic, Form, Digest, SSL:
1. basic (HTTP 1.0 proposition)
After the client requests a resource, the server sends a 401 (unauthorized) response with a real message indicating Basic authentication.
The browser will pop up a box after receiving the response and enter the user name and password. And point cancel means to cancel authentication, and point determination will submit a user name and a password to the server. The submission mode is to add in the HTTP header:
WWW-Authorization:Basic XXXXXXX
basic is followed by BASE64 encoding of the username, password. In client programming, the construction of the piece of content is:
String cre＝userName+":"+password
Base64encode(cre)；
add to request header with"WWW-Authroization"。
2、Form
form is simply submitting data in Form on a page, GET or post.
3. Digest (HTTP 1.1 basic)
To prevent replay attacks, digest access authentication is employed. After the client sends a request, a message 401 is received, which also includes a unique string: nonce, which is different for each request. Such as, for example,
HTTP/1.1 401Unauthorized
WWW-Authenticate:Digest
realm＝"xxxxxxx",
qop＝"auth,auth-int",
nonce＝"--base code--",
opaque＝"--base code--"
at this point the client returns a digest of the username, password, nonce, HTTP Method, and URI hashed (by default MD5) based on the check value to the server. The response header must include 5 parts:
realm, Domain, different Domain may have a password that is different
Challenge value
username of usernames
digest-URI request URI
response summary section
The server calculates a new digest by adding the stored password to the received information and compares the new digest with the digest in the request, and because each nonce is changed, the replay attack is difficult to achieve.
4、SSL
The SSL protocol is positioned between the TCP/IP and the application protocol, and the safety of data communication is ensured based on a public key system. The SSL protocol can be divided into two layers: SSL recording Protocol (SSL Record Protocol): it is built on top of reliable transmission protocol (such as TCP), and provides basic functions of data encapsulation, compression, encryption and the like for higher-layer protocol. SSL handshake Protocol (SSLHandshake Protocol): it is established on SSL record protocol, and is used for making identity authentication, negotiation encryption algorithm and exchange encryption key, etc. by two communication parties before actual data transmission is started.
The SSL protocol provides services mainly including:
1) authenticating the user and the server to ensure that the data is sent to the correct client and server;
2) encrypting data to prevent data from being stolen midway;
3) and the integrity of the data is maintained, and the data is ensured not to be changed in the transmission process.
The biggest problem in the 4 basic verification methods is that authentication of identity can only be maintained from the level of data encryption and session, but system contents between different platforms cannot be synchronized. Secondly, it is impossible to identify whether the user's login failure behavior and session failure flow are caused by erroneous operation or attack.
Disclosure of Invention
The invention aims to overcome the defects of the prior art, and provides a single-system multi-platform identity authentication method which can not leave client information on a server, adopts an encryption mode to circulate, can generate attack warning when characters are modified, a crawler engine is used for bumping a library or an expired ciphertext is used, can effectively reduce the risk of using a cache and the risk of session fixed attack caused by using a session, and can improve the efficiency and the safety of identity authentication.
The purpose of the invention is realized by the following technical scheme: a single-system multi-platform identity authentication method comprises the following steps:
s1, the server obtains the user name and user password used when the client logs in, then accesses the database to find out whether the user exists, if yes, the user is provided with the ciphertext, otherwise, the server prompts error and requires the client to log in again;
s2, the server receives the access request for the restricted resource sent by the client and receives the ciphertext submitted by the user;
s3, the server verifies the ciphertext, the step S4 is carried out after the verification is successful, and a first adjusting scheme is executed if the verification is unsuccessful;
s4, the server analyzes the ciphertext, inquires the relevant field content according to the client information which requests to access, determines whether the current operation has errors according to the protocol content of each client, if not, the step S5 is carried out, otherwise, a second adjusting scheme is executed;
s5, the server returns the receipt allowing the client to access the restricted resource, re-encrypts the ciphertext and re-sends the encrypted ciphertext to the client.
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 yes, the step S12 is executed, otherwise, an error is prompted and the client is required to log in again;
s12, extracting the client object from the database, extracting a token field, if the token field is empty, executing the step S13, otherwise executing the step S14;
s13, adding the identification information of the current client, the current timestamp and the platform information of the current login client into a character string-character string diagram by using a put method, encrypting the character string-character string diagram into a ciphertext, and placing the ciphertext into a cache;
s14, analyzing the token field, reducing the token field into a plaintext, extracting agent field from the header of the message requesting login, using the agent field as a key value to access the specified field, and modifying the specified field into specified content; modifying the LastLogin field to be the current timestamp; after the modification, the data is encrypted into a ciphertext and is placed into a cache;
and S15, returning login success information, and adding the ciphertext into the header of the returned message to be used as a ciphertext certificate for the client to request to access the idle resources.
Further, the step S13 encryption process includes the following sub-steps:
s131, obtaining the device type of the client, obtaining the device type by using the content in the DeviceFamily namespace, adding the device type into a string-string graph SecretMap by using a put method, wherein the key value is as follows: device;
s132, acquiring the time for installing the current program Package, acquiring the time by using the content in the Package namespace, adding the time into a string-string graph SecretMap by using a put method, wherein the key value is as follows: install;
s133, acquiring system time, adding the system time into a string-string graph SecretMap by using a put method, wherein key values are as follows: send;
s134, encrypting the character string-character string graph SecretMap in a JSON format, wherein the used secret language is defined during program development and is stored by hard coding of a client and a server.
Further, the step S3 of verifying the ciphertext includes the following sub-steps:
s31, the server analyzes the header information of the HTTP request message, extracts the authentication protocol agreement field therein, and successfully executes S32, otherwise executes S36;
s32, decrypting the extracted agreed field of the verification protocol to obtain a structure of a character string-character string diagram, namely StatusMap, extracting a client agent field in the HTTP request message, and sequentially acquiring a platform where the client is located;
s33, judging the platform used by the client, if the platform is a web platform, executing the step S331, and if the platform is a non-web platform, executing the step S333;
s331, extracting a web field from the StatusMap as verification content, analyzing whether protocol content errors occur or not, and if the protocol content is correct, performing step S332; if the protocol content has an error, reporting the error, reporting a protocol content error record, and then executing the step S34;
s332, judging whether the comparison between the protocol content and the current timestamp is overtime or not, if yes, reporting an error, reporting an outdated error record once, and then executing the step S34; if not, updating the timer, and then executing step S35;
s333, extracting the response field as verification content, maintaining persistent login information according to respective protocol content, judging whether the login information is successfully verified, and executing the step S35 if the login information is successfully verified; otherwise, reporting an error, reporting a login error record once, and then executing the step S34;
s34, prompting the client of error information and requiring re-login;
s35, regenerating the message, encrypting the message according to the protocol content of the server and the client, and adding the new message into the pretoken field in the server response message;
s36, failing to extract the agreed field of the verification protocol or failing to verify the agreed field of the verification protocol, meaning that an expired protocol message is used to indicate that the attack mode of session fixation is received, and the server generates an attack warning and puts the attack warning into a server log;
and S37, extracting the client identity information content in the StatusMap and using the client identity information content as a token in the business logic.
Further, the first adjustment scheme in step S3 is specifically: analyzing the verification result, checking whether ciphertext grammar errors exist or not, if yes, generating an attack warning, placing the current agent information and the IP address information into a dangerous client source and outputting the dangerous client source and the IP address information into a log, prompting error information, and requesting the client to provide the ciphertext again;
if the ciphertext grammar error does not exist, checking request information in the HTTP message segment, analyzing whether an agent and an IP address in the message are from a dangerous client source, if so, generating an attack warning, outputting the information to a log, and then requesting the client to provide the ciphertext again; otherwise, error information is prompted, and the client is required to provide the ciphertext again.
Further, parsing the ciphertext in step S4 includes the following sub-steps:
s41, receiving the access request message and the ciphertext sent by the client, obtaining the timestamp received by the message and the ciphertext, and recording as current;
s42, acquiring a SecretMap according to the secret language analysis ciphertext, if the analysis is successful, executing the step S43, otherwise, generating an attack warning, placing agent information and IP address information in the current access request message into a dangerous client source and outputting the agent information and the IP address information to a log, and prompting an error to the client;
s43, analyzing the send field in the SecretMap, comparing the send field with the current, if the current is earlier than the send field or the difference between the current and the send exceeds 2 times of the average network time delay, considering that the current is attacked by the database collision, generating an attack warning, and placing the current agent information and the IP address information into a dangerous customer source and outputting the information to a log to prompt an error; otherwise, executing step S44;
s44, analyzing the device field and the install field in the SecretMap, inquiring whether the client is a credible client or not from the server through the device field and the install field, if so, the ciphertext passes the verification, otherwise, executing the step S45;
s45, checking the operation of the client sending the access request message: if the verification is passed, current information is added into the server to be stored, the client is identified as a credible client, the ciphertext passes the verification, if the verification is not passed, an incredible operation warning is sent to the current online client, an attack warning is generated at the same time, and the current agent information and IP address information are placed into a dangerous client source and output to a log to prompt errors; if the client is carrying out other operations except the login request, sending an untrusted operation warning to the current online client, generating an attack warning at the same time, and placing the current agent information and the IP address information into a dangerous client source and outputting the dangerous client source and the IP address information into a log to prompt an error.
Further, the second adjustment scheme in step S4 is specifically: judging the current error type, if the current error type is a timeout type error, prompting an error, requiring the client to log in again, and jumping to a login page; and if the cipher text is wrong, generating an attack warning, placing the current agent information and the IP address information into a dangerous client source and outputting the dangerous client source and the IP address information into a log to prompt the error.
The invention has the beneficial effects that: the invention has specially optimized aiming at the traditional safety problem that the user login state needs to be kept at the server and the condition that the single system and the multiple platforms are easy to be crowded mutually, and by adopting the identity verification method of the invention, the client information can not be left on the server, and the encryption mode is adopted for circulation, and the attack warning can be generated by modifying characters, using a crawler engine to crash a library or using an expired ciphertext, so that the risk of using a cache and the risk of session fixed attack caused by using a session can be effectively reduced, the CSRF attack can not be generated, and the efficiency and the safety of identity verification can be improved.
Drawings
FIG. 1 is a flow chart of a single system multi-platform identity verification method of the present invention;
FIG. 2 is a client login flow diagram of the present invention;
FIG. 3 is an encryption flow diagram of the present invention;
FIG. 4 is a flowchart of the present invention for verifying a ciphertext;
FIG. 5 is a ciphertext flow chart of the present invention.
Detailed Description
The technical scheme of the invention is further explained by combining the attached drawings.
As shown in fig. 1, a single-system multi-platform identity authentication method includes the following steps:
s1, the server obtains the user name and user password used when the client logs in, then accesses the database to find out whether the user exists, if yes, the user is provided with the ciphertext, otherwise, the server prompts error and requires the client to log in again; as shown in fig. 2, the method 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 yes, the step S12 is executed, otherwise, an error is prompted and the client is required to log in again;
s12, extracting the client object from the database, extracting a token field, if the token field is empty, executing the step S13, otherwise executing the step S14;
s13, adding the identification information of the current client, the current timestamp and the platform information of the current login client into a character string-character string diagram by using a put method, encrypting the character string-character string diagram into a ciphertext, and placing the ciphertext into a cache;
agent fields of clients developed under a net frame are uniformly set to UWP, agent fields of clients developed under an android system are uniformly set to ADW, agent fields of clients developed under an IOS system are uniformly set to IOS, and the following specific name space (or package) is referred to by UWP. As shown in fig. 3, the encryption process comprises the following sub-steps:
s131, obtaining the device type of the client, obtaining the device type by using the content in the DeviceFamily namespace, adding the device type into a string-string graph SecretMap by using a put method, wherein the key value is as follows: device;
s132, acquiring the time for installing the current program Package, acquiring the time by using the content in the Package namespace, adding the time into a string-string graph SecretMap by using a put method, wherein the key value is as follows: install;
s133, acquiring system time, adding the system time into a string-string graph SecretMap by using a put method, wherein key values are as follows: send;
s134, encrypting the character string-character string graph SecretMap in a JSON format, wherein the used secret language is defined during program development and is stored by hard coding of a client and a server.
S14, analyzing the token field, reducing the token field into a plaintext, extracting agent field from the header of the message requesting login, using the agent field as a key value to access the specified field, and modifying the specified field into specified content; modifying the LastLogin field to be the current timestamp; after the modification, the data is encrypted into a ciphertext and is placed into a cache;
and S15, returning login success information, and adding the ciphertext into the header of the returned message to be used as a ciphertext certificate for the client to request to access the idle resources.
S2, the server receives the access request for the restricted resource sent by the client and receives the ciphertext submitted by the user;
s3, the server verifies the ciphertext, the step S4 is carried out after the verification is successful, and a first adjusting scheme is executed if the verification is unsuccessful;
as shown in fig. 4, the verification ciphertext includes the following sub-steps:
s31, the server analyzes the header information of the HTTP request message, extracts the authentication protocol agreement field therein, and successfully executes S32, otherwise executes S36;
s32, decrypting the extracted agreed field of the verification protocol to obtain a structure of a character string-character string diagram, namely StatusMap, extracting a client agent field in the HTTP request message, and sequentially acquiring a platform where the client is located;
s33, judging the platform used by the client, if the platform is a web platform, executing the step S331, and if the platform is a non-web platform, executing the step S333;
s331, extracting a web field from the StatusMap as verification content, analyzing whether protocol content errors occur or not, and if the protocol content is correct, performing step S332; if the protocol content has an error, reporting the error, reporting a protocol content error record, and then executing the step S34;
s332, judging whether the comparison between the protocol content and the current timestamp is overtime or not, if yes, reporting an error, reporting an outdated error record once, and then executing the step S34; if not, updating the timer, and then executing step S35;
s333, extracting the response field as verification content, maintaining persistent login information according to respective protocol content, judging whether the login information is successfully verified, and executing the step S35 if the login information is successfully verified; otherwise, reporting an error, reporting a login error record once, and then executing the step S34;
s34, prompting the client of error information and requiring re-login;
s35, regenerating the message, encrypting the message according to the protocol content of the server and the client, and adding the new message into the pretoken field in the server response message;
s36, failing to extract the agreed field of the verification protocol or failing to verify the agreed field of the verification protocol, meaning that an expired protocol message is used to indicate that the attack mode of session fixation is received, and the server generates an attack warning and puts the attack warning into a server log;
and S37, extracting the client identity information content in the StatusMap and using the client identity information content as a token in the business logic.
The first adjustment scheme specifically comprises: analyzing the verification result, checking whether ciphertext grammar error (Syntax exception) exists, if yes, generating attack warning, placing the current agent information and IP address information into a dangerous client source and outputting the information to a log, and prompting error information to request the client to provide the ciphertext again;
if the ciphertext grammar error does not exist, checking request information in the HTTP message segment, analyzing whether an agent and an IP address in the message are from a dangerous client source, if so, generating an attack warning, outputting the information to a log, and then requesting the client to provide the ciphertext again; otherwise, error information is prompted, and the client is required to provide the ciphertext again.
S4, the server analyzes the ciphertext, inquires the relevant field content according to the client information which requests to access, determines whether the current operation has errors according to the protocol content of each client, if not, the step S5 is carried out, otherwise, a second adjusting scheme is executed;
as shown in fig. 5, parsing the ciphertext includes the following sub-steps:
s41, receiving the access request message and the ciphertext sent by the client, obtaining the timestamp received by the message and the ciphertext, and recording as current;
s42, acquiring a SecretMap according to the secret language analysis ciphertext, if the analysis is successful, executing the step S43, otherwise, generating an attack warning, placing agent information and IP address information in the current access request message into a dangerous client source and outputting the agent information and the IP address information to a log, and prompting an error to the client;
s43, analyzing the send field in the SecretMap, comparing the send field with the current, if the current is earlier than the send field or the difference between the current and the send exceeds 2 times of the average network time delay, considering that the current is attacked by the database collision, generating an attack warning, and placing the current agent information and the IP address information into a dangerous customer source and outputting the information to a log to prompt an error; otherwise, executing step S44;
s44, analyzing the device field and the install field in the SecretMap, inquiring whether the client is a credible client or not from the server through the device field and the install field, if so, the ciphertext passes the verification, otherwise, executing the step S45;
s45, checking the operation of the client sending the access request message: if the verification is passed, current information is added into the server to be stored, the client is identified as a credible client, the ciphertext passes the verification, if the verification is not passed, an incredible operation warning is sent to the current online client, an attack warning is generated at the same time, and the current agent information and IP address information are placed into a dangerous client source and output to a log to prompt errors; if the client is carrying out other operations except the login request, sending an untrusted operation warning to the current online client, generating an attack warning at the same time, and placing the current agent information and the IP address information into a dangerous client source and outputting the dangerous client source and the IP address information into a log to prompt an error.
The second adjustment scheme specifically comprises: judging the current error type, if the current error type is an overtime type error (overtime exception), prompting an error, requiring the client to log in again, and jumping to a login page; and if the message is a ciphertext error (protocol exception), generating an attack warning, and placing the current agent information and the IP address information into a dangerous client source and outputting the information to a log to prompt an error.
S5, the server returns the receipt allowing the client to access the restricted resource, re-encrypts the ciphertext and re-sends the encrypted ciphertext to the client.
It will be appreciated by those of ordinary skill in the art that the embodiments described herein are intended to assist the reader in understanding the principles of the invention and are to be construed as being without limitation to such specifically recited embodiments and examples. Those skilled in the art can make various other specific changes and combinations based on the teachings of the present invention without departing from the spirit of the invention, and these changes and combinations are within the scope of the invention.
Claims (3)
1. A single-system multi-platform identity authentication method is characterized by comprising the following steps:
s1, the server obtains the user name and user password used when the client logs in, then accesses the database to find out whether the user exists, if yes, the user is provided with the ciphertext, otherwise, the server prompts error and requires the client to log in again;
s2, the server receives the access request for the restricted resource sent by the client and receives the ciphertext submitted by the user;
s3, the server verifies the ciphertext, the step S4 is carried out after the verification is successful, and a first adjusting scheme is executed if the verification is unsuccessful; verifying the ciphertext includes the following substeps:
s31, the server analyzes the header information of the HTTP request message, extracts the authentication protocol agreement field therein, and successfully executes S32, otherwise executes S36;
s32, decrypting the extracted agreed field of the verification protocol to obtain a structure of a character string-character string diagram, namely StatusMap, extracting a client agent field in the HTTP request message, and sequentially acquiring a platform where the client is located;
s33, judging the platform used by the client, if the platform is a web platform, executing the step S331, and if the platform is a non-web platform, executing the step S333;
s331, extracting a web field from the StatusMap as verification content, analyzing whether protocol content errors occur or not, and if the protocol content is correct, performing step S332; if the protocol content has an error, reporting the error, reporting a protocol content error record, and then executing the step S34;
s332, judging whether the comparison between the protocol content and the current timestamp is overtime or not, if yes, reporting an error, reporting an outdated error record once, and then executing the step S34; if not, updating the timer, and then executing step S35;
s333, extracting the response field as verification content, maintaining persistent login information according to respective protocol content, judging whether the login information is successfully verified, and executing the step S35 if the login information is successfully verified; otherwise, reporting an error, reporting a login error record once, and then executing the step S34;
s34, prompting the client of error information and requiring re-login;
s35, regenerating the message, encrypting the message according to the protocol content of the server and the client, and adding the new message into the pretoken field in the server response message;
s36, failing to extract the agreed field of the verification protocol or failing to verify the agreed field of the verification protocol, meaning that an expired protocol message is used to indicate that the attack mode of session fixation is received, and the server generates an attack warning and puts the attack warning into a server log;
s37, extracting the client identity information content in the StatusMap, and using the client identity information content as a token in the service logic;
the first adjustment scheme specifically comprises: analyzing the verification result, checking whether ciphertext grammar errors exist or not, if yes, generating an attack warning, placing the current agent information and the IP address information into a dangerous client source and outputting the dangerous client source and the IP address information into a log, prompting error information, and requesting the client to provide the ciphertext again;
if the ciphertext grammar error does not exist, checking request information in the HTTP message segment, analyzing whether an agent and an IP address in the message are from a dangerous client source, if so, generating an attack warning, outputting the information to a log, and then requesting the client to provide the ciphertext again; otherwise, prompting error information and requiring the client to provide the ciphertext again;
s4, the server analyzes the ciphertext, inquires the relevant field content according to the client information which requests to access, determines whether the current operation has errors according to the protocol content of each client, if not, the step S5 is carried out, otherwise, a second adjusting scheme is executed;
parsing the ciphertext includes the following substeps:
s41, receiving the access request message and the ciphertext sent by the client, obtaining the timestamp received by the message and the ciphertext, and recording as current;
s42, acquiring a SecretMap according to the secret language analysis ciphertext, if the analysis is successful, executing the step S43, otherwise, generating an attack warning, placing agent information and IP address information in the current access request message into a dangerous client source and outputting the agent information and the IP address information to a log, and prompting an error to the client;
s43, analyzing the send field in the SecretMap, comparing the send field with the current, if the current is earlier than the send field or the difference between the current and the send exceeds 2 times of the average network time delay, considering that the current is attacked by the database collision, generating an attack warning, and placing the current agent information and the IP address information into a dangerous customer source and outputting the information to a log to prompt an error; otherwise, executing step S44;
s44, analyzing the device field and the install field in the SecretMap, inquiring whether the client is a credible client or not from the server through the device field and the install field, if so, the ciphertext passes the verification, otherwise, executing the step S45;
s45, checking the operation of the client sending the access request message: if the verification is passed, current information is added into the server to be stored, the client is identified as a credible client, the ciphertext passes the verification, if the verification is not passed, an incredible operation warning is sent to the current online client, an attack warning is generated at the same time, and the current agent information and IP address information are placed into a dangerous client source and output to a log to prompt errors; if the client is carrying out other operations except the login request, sending an untrusted operation warning to the current online client, generating an attack warning at the same time, placing the current agent information and the IP address information into a dangerous client source and outputting the dangerous client source and the IP address information into a log to prompt an error;
the second adjustment scheme specifically comprises the following steps: judging the current error type, if the current error type is a timeout type error, prompting an error, requiring the client to log in again, and jumping to a login page; if the cipher text is wrong, generating an attack warning, placing the current agent information and the IP address information into a dangerous client source and outputting the dangerous client source and the IP address information into a log to prompt the error;
s5, the server returns the receipt allowing the client to access the restricted resource, re-encrypts the ciphertext and re-sends the encrypted ciphertext to the client.
2. The single-system multi-platform identity authentication method according to claim 1, wherein the step S1 specifically comprises 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 yes, the step S12 is executed, otherwise, an error is prompted and the client is required to log in again;
s12, extracting the client object from the database, extracting a token field, if the token field is empty, executing the step S13, otherwise executing the step S14;
s13, adding the identification information of the current client, the current timestamp and the platform information of the current login client into a character string-character string diagram by using a put method, encrypting the character string-character string diagram into a ciphertext, and placing the ciphertext into a cache;
s14, analyzing the token field, reducing the token field into a plaintext, extracting agent field from the header of the message requesting login, using the agent field as a key value to access the specified field, and modifying the specified field into specified content; modifying the LastLogin field to be the current timestamp; after the modification, the data is encrypted into a ciphertext and is placed into a cache;
and S15, returning login success information, and adding the ciphertext into the header of the returned message to be used as a ciphertext certificate for the client to request to access the idle resources.
3. The single-system multi-platform authentication method according to claim 2, wherein the step S13 encryption process comprises the following sub-steps:
s131, acquiring the equipment type of the client, and adding the equipment type into a character string-character string diagram SecretMap by using a put method;
s132, acquiring the time for installing the current program package, and adding the current program package into a string-string diagram SecretMap by using a put method;
s133, acquiring system time, and adding the system time into a string-string diagram SecretMap by using a put method;
s134, encrypting the character string-character string graph SecretMap in a JSON format, wherein the used secret language is defined during program development and is stored by hard coding of a client and a server.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610933435.0A CN106453352B (en) | 2016-10-25 | 2016-10-25 | Single-system multi-platform identity authentication method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610933435.0A CN106453352B (en) | 2016-10-25 | 2016-10-25 | Single-system multi-platform identity authentication method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106453352A CN106453352A (en) | 2017-02-22 |
| CN106453352B true CN106453352B (en) | 2020-04-17 |
Family
ID=58177938
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610933435.0A Active CN106453352B (en) | 2016-10-25 | 2016-10-25 | Single-system multi-platform identity authentication method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106453352B (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108512657B (en) * | 2017-02-28 | 2021-05-14 | 中兴通讯股份有限公司 | Password generation method and device |
| CN108600209B (en) * | 2018-04-16 | 2021-06-22 | 新华三信息安全技术有限公司 | Information processing method and device |
| CN111212033A (en) * | 2019-12-16 | 2020-05-29 | 北京淇瑀信息科技有限公司 | Page display method and device based on combined web crawler defense technology and electronic equipment |
| CN111222121B (en) * | 2019-12-27 | 2022-03-11 | 广州芯德通信科技股份有限公司 | Authorization management method for embedded equipment |
| CN111343191B (en) * | 2020-03-03 | 2022-08-16 | 浙江大华技术股份有限公司 | Session checking method and device, storage medium and electronic device |
| CN112383535B (en) * | 2020-11-10 | 2022-10-25 | 平安普惠企业管理有限公司 | Method and device for detecting Hash transfer attack behavior and computer equipment |
| CN112667730B (en) * | 2021-01-13 | 2023-04-07 | 永辉云金科技有限公司 | External data verification method, system, equipment and storage medium |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101060520A (en) * | 2006-04-21 | 2007-10-24 | 盛趣信息技术（上海）有限公司 | Token-based SSO authentication system |
| CN101174953A (en) * | 2007-03-27 | 2008-05-07 | 兰州大学 | Identity authentication method based on S/Key system |
| CN101465735A (en) * | 2008-12-19 | 2009-06-24 | 北京大学 | Network user identification verification method, server and client terminal |
| CN101668013A (en) * | 2009-03-30 | 2010-03-10 | 刘文祥 | Network connection technology and system thereof |
| CN102780674A (en) * | 2011-05-09 | 2012-11-14 | 同方股份有限公司 | Method and system for processing network service by utilizing multifactor authentication method |
| CN103929435A (en) * | 2014-05-05 | 2014-07-16 | 中国科学院计算机网络信息中心 | Credibility verification method based on DNSSEC and DANE protocols |
| CN103944900A (en) * | 2014-04-18 | 2014-07-23 | 中国科学院计算技术研究所 | Cross-station request attack defense method and device based on encryption |
| CN105187382A (en) * | 2015-08-05 | 2015-12-23 | 西安电子科技大学 | Multi-factor identity authentication method for preventing library collision attacks |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8719905B2 (en) * | 2010-04-26 | 2014-05-06 | Authentify Inc. | Secure and efficient login and transaction authentication using IPhones™ and other smart mobile communication devices |
-
2016
- 2016-10-25 CN CN201610933435.0A patent/CN106453352B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101060520A (en) * | 2006-04-21 | 2007-10-24 | 盛趣信息技术（上海）有限公司 | Token-based SSO authentication system |
| CN101174953A (en) * | 2007-03-27 | 2008-05-07 | 兰州大学 | Identity authentication method based on S/Key system |
| CN101465735A (en) * | 2008-12-19 | 2009-06-24 | 北京大学 | Network user identification verification method, server and client terminal |
| CN101668013A (en) * | 2009-03-30 | 2010-03-10 | 刘文祥 | Network connection technology and system thereof |
| CN102780674A (en) * | 2011-05-09 | 2012-11-14 | 同方股份有限公司 | Method and system for processing network service by utilizing multifactor authentication method |
| CN103944900A (en) * | 2014-04-18 | 2014-07-23 | 中国科学院计算技术研究所 | Cross-station request attack defense method and device based on encryption |
| CN103929435A (en) * | 2014-05-05 | 2014-07-16 | 中国科学院计算机网络信息中心 | Credibility verification method based on DNSSEC and DANE protocols |
| CN105187382A (en) * | 2015-08-05 | 2015-12-23 | 西安电子科技大学 | Multi-factor identity authentication method for preventing library collision attacks |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106453352A (en) | 2017-02-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106453352B (en) | Single-system multi-platform identity authentication method | |
| WO2022052493A1 (en) | 5g-based internet of things device access method and system, and storage medium | |
| US10979427B2 (en) | Method and device for authenticating based on authenticating device | |
| CN107579991B (en) | Method for performing cloud protection authentication on client, server and client | |
| CN106506494B (en) | Application access method of open platform | |
| CN102201915B (en) | Terminal authentication method and device based on single sign-on | |
| CN101860540B (en) | Method and device for identifying legality of website service | |
| CN109672675B (en) | OAuth 2.0-based WEB authentication method of password service middleware | |
| CN106453361B (en) | A kind of security protection method and system of the network information | |
| US20160381001A1 (en) | Method and apparatus for identity authentication between systems | |
| CN103179134A (en) | Single sign on method and system based on Cookie and application server thereof | |
| CN107612889B (en) | Method for preventing user information leakage | |
| CN112260838B (en) | Automatic renewal authentication method based on JWT (just-before-last-transaction) | |
| CN103475666A (en) | Internet of things resource digital signature authentication method | |
| CN112711759A (en) | Method and system for preventing replay attack vulnerability security protection | |
| CN111371725A (en) | Method for improving security of session mechanism, terminal equipment and storage medium | |
| CN110768973A (en) | Signaling safety evaluation system and method based on GB35114 standard | |
| CN111800378A (en) | Login authentication method, device, system and storage medium | |
| CN112422477A (en) | Service authentication method, server, electronic device and storage medium | |
| CN111143822A (en) | Application system access method and device | |
| CN112600674A (en) | User security authentication method and device for front-end and back-end separation system and storage medium | |
| CN112699374A (en) | Integrity checking vulnerability security protection method and system | |
| CN111614458A (en) | Method, system and storage medium for generating gateway JWT | |
| CN116527341A (en) | Client-side calling rear-end interface authentication authorization security method | |
| CN110995424A (en) | Safe API data verification method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |