Security verification method for security transaction

Abstract

The invention discloses a security verification method for security transaction, which is characterized by comprising the following steps: a client generates first authentication request data before a user requests to perform security transaction, and sends the first authentication request data to a server through an encrypted channel; and after the server receives the first authentication request data, a one-time authentication token is generated based on a preset authentication algorithm and the user identity information, and the one-time authentication token and the unique transaction context corresponding to the one-time authentication token are bound and stored in a server session cache. And the authentication information is transmitted by adopting an independent channel, so that the token is prevented from being reused after being intercepted and captured, and the transaction security is effectively guaranteed. Meanwhile, user behavior feature analysis is introduced, token generation and verification strategies are dynamically adjusted, the recognition and response ability of the system to abnormal transactions is enhanced, and therefore the accuracy of identity verification and the intelligence of risk control in the security transaction process are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of network information security, in particular to a security verification method for securities trading. BACKGROUND

[0002] In the prior art security verification process of securities trading, a problem that is not common but will cause serious consequences once it occurs is "identity verification process hijacked by repeated use of intermediate authentication data by legitimate users". For example, in the scenario of using one-time password (OTP) or two-dimensional code authentication, if the attacker intercepts and reuses these authentication information that should be used only once through man-in-the-middle attack (MITM) or network monitoring during the user verification process, it may bypass the security protection of the system in a short time, and initiate illegal transactions by forging the user's identity. This type of attack is difficult to be identified by traditional firewalls or authentication mechanisms in real time, and once successful, it may result in the transfer of user assets or the malicious execution of transaction instructions, with extremely serious consequences.

[0003] The prior art has the following disadvantages: In the existing security verification process of securities trading, the intermediate authentication data (such as one-time password or two-dimensional code) generated by the legitimate user in the identity verification link may be intercepted and maliciously reused by the attacker. Through man-in-the-middle attack (MITM) or network monitoring, the attacker can obtain these authentication information that should be used only once during data transmission, and impersonate the user to bypass the security verification mechanism in a short time, and initiate unauthorized transaction operations. Since this process usually occurs after the completion of the verification link and before the execution of the transaction, traditional security strategies are difficult to identify and block in a timely manner, which can easily lead to illegal transfer of account assets and cause serious consequences. SUMMARY

[0004] The technical problem to be solved by the present application is to provide a security verification method for securities trading.

[0005] To solve the above technical problems, the technical scheme of the present application is as follows: A security verification method for securities trading, comprising the following steps: The client generates first authentication request data before the user requests to trade securities, and sends it to the server through an encrypted channel; After receiving the first authentication request data, the server generates a one-time authentication token based on a preset authentication algorithm and user identity information, and binds and stores it in the server session cache with a unique transaction context corresponding to the one-time authentication token; The server returns the one-time authentication token to the client through an independent channel for subsequent transaction authentication; The client embeds the one-time authentication token when submitting the transaction instruction, and sends it to the server again with complete transaction context data; The server extracts the bound one-time authentication token from the cache and performs a double comparison with the transaction context after receiving the transaction instruction, verifying whether the two match and are used for the first time; If the authentication token and transaction context are consistent and have not been used, the transaction instruction is allowed to be executed, and the authentication token is immediately destroyed; otherwise, the transaction request is rejected and an abnormal behavior log is recorded.

[0006] Preferably, the first authentication request data includes a user device identifier, a current timestamp, a random challenge code, and a user account digest; The user device identifier is used to identify the uniqueness of the terminal, the current timestamp is used to prevent replay attacks, the random challenge code is used for dynamic confirmation, and the user account digest is generated by a hash algorithm to avoid leaking real account information during transmission; After the client combines the data, an elliptic curve encryption algorithm is used to generate an encrypted data packet, thereby improving the data protection strength in the authentication request process.

[0007] Preferably, the server dynamically calculates the one-time authentication token in combination with user historical transaction behavior characteristics; The server adjusts the token survival time limit based on the degree of deviation after comparing the behavior characteristics with the current transaction context.

[0008] Preferably, the specific steps of matching verification of the transaction context are as follows: The client structures and splices three elements of transaction type, transaction amount, and transaction time when initiating a transaction, and generates a digest code through a SHA256 hash function, with the generation formula as follows: , wherein is the context digest code, is the transaction type, is the transaction amount, is the transaction timestamp; After the server receives the digest code, it processes it using the HMAC encryption mechanism and a private key to generate a context hash value, with the generation formula as follows: , wherein is the server private key, is the server-side context verification code; The server calls the local binding hash value in the context cache and matches it with the newly calculated : if , the authentication is passed; otherwise, the authentication fails; A failed match indicates that the context has been tampered with or the data has not been submitted in an authorized manner, and the transaction is immediately rejected, with an abnormal log recorded as security tracking evidence.

[0009] Preferably, the independent channel is a dedicated short-time encryption channel dynamically established through the TLS1.3 protocol, uses a self-generated key pair, and adopts session-level encryption. Each session is only used once for token delivery and then destroyed, and cannot be reused; The independent channel is physically separated from the main transaction channel and logically isolated. The authentication token adopts a one-way synchronous sending strategy to avoid the risk of authentication token leakage caused by response blocking or playback delay, thereby improving the security level of information transmission.

[0010] Preferably, the transaction context data includes four elements: transaction type, transaction subject code, transaction amount, and transaction trigger time. The context data is sent with the transaction instruction after being encrypted by the client and is used on the server side to bind and compare the token. If it is found that the transaction context and the original binding data are inconsistent in any way, even if the authentication token itself is legal, the transaction processing flow is still immediately interrupted to ensure that the authentication mechanism not only verifies the user but also verifies the integrity of the transaction instruction.

[0011] Preferably, the double comparison process includes two stages: the first stage is token body consistency verification, and the second stage is context parameter consistency verification. The first stage uses an encryption digest algorithm to check the token value, and the second stage uses a hash mapping table to compare the context fields one by one. Both stages must pass the verification before entering the transaction execution process. If any stage fails, an automatic blocking mechanism will be triggered, and an abnormal check event log will be generated in the user account.

[0012] Preferably, the server needs to perform an integrity check before destroying the authentication token. The verification process includes confirming the token usage state, checking the token binding information, and verifying whether the processing time limit is within the set time window. After the verification passes, the memory erasure mechanism is called to overwrite the original token cache area to ensure that it cannot be obtained by subsequent calls due to memory residue. At the same time, the destruction time and execution process are recorded and linked to the tamper-proof log area to improve verifiability and regulatory transparency.

[0013] Preferably, the generation of the authentication token is as follows: After receiving the authentication request data from the client, the server extracts the current server timestamp, the user's unique identity code, and the pseudo-random number, calculates the basic seed of the authentication token by combining the XOR and the hash function, and the calculation expression is as follows: , where is the basic seed value, is the hash function, is the current server timestamp, Is the user identification code, is a pseudo-random number, It is a bitwise exclusive OR operation; The server analyzes the user's current behavior parameters, including intraday trading frequency, device activity, and the degree of deviation from the user's historical behavior, and calculates the behavior weight factor. The calculation expression is as follows: , where is the weight factor, is the frequency of intraday trading, is the device activity, is the characteristic value of the current transaction amount distribution, is the historical behavior benchmark characteristic value; The server uses the AES symmetric encryption algorithm based on the seed value As the key, the behavior factor and the pseudo-random number product are encrypted to generate the authentication token core value. The generation formula is as follows: , where is the Advanced Encryption Standard encryption function, It is the core value of the authentication token.

[0014] Beneficial effects of the present invention: By binding a one-time authentication token to a specific transaction context and using an independent channel to transmit authentication information, this invention combines context-dependent transaction security verification with token uniqueness. This mechanism effectively prevents the illegal reuse of intercepted intermediate authentication data. Even if an attacker obtains the authentication token, they cannot restore the bound transaction context, thus failing the server's double verification. This design significantly enhances the unforgeability of transaction operations and the integrity verification of user identities, providing strong security protection for core transaction processes in securities systems.

[0015] This invention incorporates dynamic behavior analysis and a temporary token generation strategy into the authentication process. This dynamically adjusts the authentication token's structure and validity period based on historical user behavior, enhancing the system's sensitivity to anomalous trading patterns. When a user's trading behavior significantly deviates from previous patterns, the system proactively shortens the authentication cycle and strengthens authentication, enhancing the flexibility and responsiveness of overall risk control. This intelligent security response mechanism effectively addresses the traditional static authentication model's inability to identify unknown attack patterns, empowering trading platforms with stronger adaptive protection capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 The present invention is a flowchart of a security verification method for securities trading. DETAILED DESCRIPTION

[0017] The specific embodiments of the present application will be further described below with reference to the accompanying drawings. It should be noted that the description of these embodiments is used to help understand the present application, but does not constitute a limitation on the present application. In addition, the technical features involved in the various embodiments of the present application described below can be combined with each other as long as they do not conflict with each other.

[0018] The working principle of the present application: a security verification method for securities trading, comprising the following steps: The client generates first authentication request data before the user requests to trade securities, and sends it to the server through an encrypted channel; The first authentication request data includes user device identification, current timestamp, random challenge code and user account summary; The user device identification is used to identify the uniqueness of the terminal, the current timestamp is used to prevent replay attacks, the random challenge code is used to dynamically confirm, and the user account summary is generated by a hash algorithm to avoid leaking real account information during transmission; After the client combines the data, it generates an encrypted data packet using the elliptic curve encryption (ECC) algorithm, thereby improving the data protection strength in the authentication request process and ensuring that the authentication request is not maliciously modified or forged by the man-in-the-middle.

[0019] The role of this step is to build a set of authentication request data structure with high security, uniqueness and tamper-proof ability, thereby establishing a reliable data protection mechanism from the source of the client-initiated authentication process. In the existing authentication process, if the identity authentication request data structure submitted by the client is too simple or redundant, it is easy to be monitored, forged or replayed by attackers, thereby bypassing security controls and implementing malicious behaviors such as transaction fraud. Therefore, this step greatly improves the protection ability of the authentication data itself by jointly building multiple data elements.

[0020] First, the user device identification is the first key element in this structure, which can be extracted through the device hardware unique number (such as MAC address, IMEI, etc.), ensuring that each authentication request is bound to a specific physical device, thereby forming a device-level security boundary. Second, the current timestamp introduces the system time dimension, which can effectively prevent replay attacks, because the server can set a time window mechanism to only accept data packets generated within a certain time period. Third, the addition of the random challenge code enhances the dynamic nature of the data, ensuring that even if an attacker copies the request structure, it is difficult to predict the challenge code content, losing the possibility of replaying. Finally, the user account summary is sent after being encrypted by a hash algorithm, which protects user privacy and improves the non-tamperability of the account field.

[0021] This data structure is finally encapsulated and encrypted by ECC (Elliptic Curve Cryptography) algorithm. ECC is suitable for mobile terminals and high-frequency transaction platforms due to its high strength and low computational complexity, which requires high real-time performance. The entire encryption process ensures that the authentication request will not be leaked or forged in the communication link from the client to the server, thereby providing a strong and trusted initial interaction basis for subsequent authentication token generation.

[0022] After the server receives the first authentication request data, it generates a one-time authentication token based on the preset authentication algorithm and user identity information, and binds it with the unique transaction context corresponding to the one-time authentication token and stores it in the service side session cache. When generating the one-time authentication token, the server combines the user's historical transaction behavior characteristics for dynamic calculation. Behavioral characteristics include typical transaction time, commonly used device address, transaction amount distribution characteristics, etc. After comparing the behavior characteristics with the current transaction background, the server adjusts the token survival time limit according to the deviation degree. For example, when detecting that the user's transaction behavior deviates significantly from the regular mode, the effective time of the one-time authentication token is shortened, and a risk prompt is attached, further enhancing the risk control ability of the authentication token.

[0023] The role of the above steps is to introduce user behavior modeling and dynamic risk perception mechanism, so that the generation of authentication tokens is not only based on static identity information, but also combined with user behavior characteristics for adjustment, in order to realize dynamic protection and personalized verification strategy. Traditional authentication mechanisms rely mainly on user identity and password, although encryption methods can improve security, but when faced with advanced attack methods (such as social engineering, behavior impersonation), there are still vulnerabilities. Therefore, by modeling the user's historical transaction behavior, more sensitive and detailed dynamic judgment logic can be introduced in the authentication process.

[0024] In the implementation process, the server first retrieves the user's behavior portrait data, including but not limited to daily transaction frequency, daily active transaction period, type and geographic location of commonly used transaction terminals, distribution range of transaction amount, etc. Based on these data, the system establishes a user feature baseline. Whenever the user submits an authentication request, the system can compare the current behavior state with the historical baseline to generate a behavior deviation factor. This factor will participate in dynamic parameter setting in the token generation process, such as shortening the token's life cycle, increasing transmission delay verification, adding one-time semantic recognition, etc.

[0025] The key advantage of this mechanism is that even if an attacker obtains authentication information at a certain stage, it would be difficult for them to simulate the user's complete behavior pattern, resulting in a mismatch between the generated authentication token and the transaction request, which would be identified as an anomaly by the system and terminate the authentication process. Furthermore, the dynamic token mechanism supports flexible configuration of security policies, automatically adjusting token parameters based on different user risk levels, achieving personalized protection and enhancing the system's adaptability and resilience to diverse attacks.

[0026] The specific steps for transaction context matching verification are as follows: When the client initiates a transaction, it performs a structured concatenation of the transaction type, transaction amount, and transaction time, and generates a digest code using the SHA256 hash function. The generation formula is as follows: , where Is the context summary code, the client concatenates the above three fields in order ( Represents byte concatenation) as the input value for SHA256 hash calculation to generate a fixed-length summary code. This summary code is used to represent the unique context signature of this transaction. Any slight change in any field will result in a completely different summary value (hash avalanche effect), thereby ensuring the integrity of the context. The transaction type indicates the type of operation initiated by the current user. It is one of the key fields that constitute the transaction context and can include "buy", "sell", "fund transfer", "cancel order", etc. It is represented in a unified coding form. The transaction amount refers to the amount involved in the current transaction operation, usually a floating point value accurate to two decimal places. The transaction timestamp indicates the time when the transaction instruction is generated, accurate to seconds or even milliseconds in a standard timestamp format. This summary code is used to uniquely identify the context of this transaction, ensuring that any changes in details will result in different results, thereby triggering the verification mechanism.

[0027] After receiving the digest code, the server uses the HMAC encryption mechanism and the private key to process it and generate a context hash value. The generation formula is as follows: , where The server private key is generated by the server system and stored only in the protected key management module. It is not exposed to the client or the outside world. It is used for HMAC calculation to ensure that the digest verification process can only be performed on the server and the client cannot forge a valid digest. It is the server-side context verification code, the server uses the private key Context summary for client submissions The result obtained after performing keyed hash function (HMAC) processing; HMAC (Hash-based Message Authentication Code) is a cryptographic checksum algorithm that combines a hash function and a key to verify the integrity and authenticity of a message. Its core function is to generate a fixed-length authentication code (MAC) by hashing the message content with a shared key. The receiver can use the same key to perform the same operation on the received data and compare the authentication codes to confirm whether the data has been tampered with. HMAC not only prevents malicious modification of data during transmission, but also verifies the legitimacy of the sender, so it is widely used in network security protocols (such as HTTPS, JWT, etc.) as a core mechanism for data signing and identity authentication.

[0028] This process establishes a binding relationship between the transaction context and the server's trusted key, effectively preventing the digest code from being forged or guessed.

[0029] The server calls the local binding hash value in the context cache and matches it with the newly calculated If , is the local binding hash value, which means the server generates and stores a context hash check value at the same time as the authentication token when issuing the token, and stores it in the local cache, then the authentication is passed; otherwise, the authentication fails. A failed match indicates that the context has been tampered with or the data has not been submitted in an authorized manner, so the transaction is immediately rejected, and abnormal logs are recorded as security tracking evidence.

[0030] The role of the above steps is to set up a complete and structured security check mechanism for transaction context data, thereby preventing the risk of tampering or forging transaction instructions. The core design philosophy is that transaction security not only depends on the correctness of the authentication token itself, but also must ensure that the transaction content (such as amount, time, type, subject) is not changed by any party during the entire transmission and processing process. By coupling the transaction context parameters with the authentication process, this step achieves a high degree of binding between authentication and business data, ensuring that even if an attacker obtains an authentication token, they cannot bypass the strong verification of transaction content.

[0031] This mechanism is implemented at three levels. The first level is transaction summary generation. Before initiating a transaction instruction, the client automatically extracts four core fields: transaction type, amount, target security code, and operation time, and combines them to generate summary information. This summary is unique and traceable. The second level is summary signature processing. The system encrypts and signs the summary using a key algorithm. The signature is generated using the server's exclusive private key and can only be verified by the server to ensure that the summary has not been tampered with by a third party. The third level is context comparison and verification. After the transaction instruction is transmitted to the server, the system extracts the context summary contained therein and compares it one by one with the original binding summary in the cache. Only when the signature is consistent, the summary is consistent, and the signing time is within the valid time window, will the transaction request be allowed to continue.

[0032] This method is particularly suitable for high-risk scenarios such as high-value and batch transactions. Under the protection of this mechanism, any eavesdropping, tampering, or delayed transmission of transaction data will be detected by the server due to invalid context signatures, and the transaction will be blocked. This significantly improves the security level of the securities system's collaborative work between identity authentication and transaction instruction protection.

[0033] The server returns the one-time authentication token to the client through an independent channel (different from the main channel for transaction data) for subsequent transaction authentication; Independent channels are dedicated short-term encrypted channels that are dynamically established through the TLS1.3 protocol. The channels use self-generated key pairs and employ session-level encryption. Each session is used only once and then destroyed after token delivery and cannot be reused. Independent channels are physically separated and logically isolated from the main transaction channel. The authentication token adopts a one-way synchronous sending strategy to avoid the risk of authentication token leakage due to response blocking or playback delay, thereby improving the security level of information transmission.

[0034] The above steps focus on improving the confidentiality and anti-eavesdropping capabilities of authentication tokens during transmission. Their core goal is to ensure that sensitive information is only transmitted once in a dedicated environment by setting up an independent transmission channel, preventing it from being stolen by eavesdropping tools in the main transaction channel. Currently, most financial systems use a common encrypted channel to transmit authentication data. However, because authentication tokens and business instructions share the same transmission path, there are security risks such as man-in-the-middle attacks, side-channel monitoring, or channel reuse. This step, through the dual mechanism of "physical separation + logical isolation", immediately initiates a temporary independent transmission path after the authentication token is generated, allowing the token delivery process to take place outside the main channel, greatly improving its transmission security.

[0035] This independent channel establishment process is based on the TLS 1.3 protocol. The server dynamically generates session keys and negotiates communication parameters using asymmetric encryption. Once key negotiation is complete, the channel automatically enters the encrypted data transmission phase. Each channel only handles a single token delivery. Upon completion, the key is immediately released, the session cache is destroyed, and the server's local token usage status is updated. This transmission path is logically isolated from the main transaction channel. Any data analysis tools monitoring the main channel cannot identify or parse the token content transmitted in this channel. This mechanism, through the three guarantees of single session, single delivery, and one-way communication, ensures that authentication tokens are "unobtrusive, unforgeable, and unreusable."

[0036] This step also supports a channel circuit-breaking strategy. This means that if the system detects any abnormal transmission behavior (such as abnormal latency, packet modification, or request retransmission), it will immediately terminate the current channel and generate a security alert. This feature ensures that even attackers attempting to initiate a half-open connection or forge return packets cannot disrupt the authentication process. In high-frequency trading environments, this strategy ensures both real-time requirements and transmission security, making it a key component in enhancing the system's authentication trust level.

[0037] When submitting a transaction instruction, the client embeds a one-time authentication token and resends it to the server with the complete transaction context data; Transaction context data includes four elements: transaction type, transaction target code, transaction amount, and transaction trigger time; The context data is encrypted on the client side and sent along with the transaction instruction. It is used for binding token comparison on the server side. If any inconsistency is found between the transaction context and the original binding data, the transaction processing flow will be immediately interrupted even if the authentication token itself is legitimate, ensuring that the authentication mechanism not only verifies the user, but also verifies the integrity of the transaction instructions.

[0038] The purpose of the above steps is to ensure a close binding relationship between the business context of the transaction instruction and the user's authentication status, preventing attackers from using the authentication token to forge or modify the content of the transaction request, thereby conducting illegal transactions. Traditional authentication methods usually only verify user identity information and do not verify the content of the transaction instruction itself. As a result, after identity authentication is passed, if the transaction request is hijacked or tampered with by an intermediary, the server may still mistakenly determine that the transaction is legitimate, resulting in asset loss. This step proposes to use "transaction context" as the core of verification, that is, the transaction instruction must contain specific, structured business content fields and be bound to the authentication token for verification.

[0039] In practice, when constructing a trade instruction, the client extracts four core parameters: the current transaction type (e.g., buy, sell), the target security symbol, the transaction amount (e.g., 100,000 yuan), and the precise trigger time (in milliseconds). This data is encapsulated into a context data structure, encrypted synchronously with the authentication token, and sent to the server. Upon receiving this request, the server not only verifies the legitimacy and validity of the authentication token but also extracts the context data associated with the token from the local session cache for a comparison.

[0040] Even the slightest discrepancy in any field is considered a potential security incident, and the system immediately halts the transaction and generates a security audit log to flag the anomaly. This strict mechanism prevents attackers from adjusting transaction amounts, subject matter, or timing parameters, even if they obtain a valid authentication token. This prevents security vulnerabilities such as "authentication is valid but transaction is illegal." This step strengthens the authentication mechanism from a data integrity perspective, establishing a dual confirmation model that parallels user identity authentication with business content authentication, further enhancing the system's security perimeter.

[0041] After receiving the transaction instruction, the server extracts the bound one-time authentication token from the cache and compares it with the transaction context to verify whether the two match and whether it is the first use; The double comparison process consists of two stages: the first stage is the token ontology consistency verification, and the second stage is the context parameter consistency verification; The first stage uses a cryptographic digest algorithm to check the token value, and the second stage uses a hash map to compare the context fields item by item; Both stages must pass verification before entering the transaction execution process. If either stage fails, the automatic blocking mechanism will be triggered and an abnormal verification event log will be generated in the user account for subsequent auditing and risk tracing.

[0042] The functional positioning of the above steps is to modularly restructure the authentication process, breaking down the traditional one-time authentication process into two independent sub-processes: "token body verification" and "context consistency verification." This ensures that transaction operations meet the verification requirements of both token legitimacy and business consistency. This structural design is based on the results of a risk analysis of complex attack paths: attackers may obtain legitimate authentication tokens through illegal means but lack access to specific transaction context information; or conversely, they may be able to construct the correct transaction context but be unable to obtain the actual token. Therefore, separating the verification process allows the system to intercept different types of risks separately, forming the basis of the protection strategy of this invention.

[0043] In specific operations, the first phase, "Token Body Verification," compares the server-generated summary information with the token fields in the request. This step primarily determines whether the token matches, whether it's the first use, and whether it's within the valid time window. If this step passes, the second phase, "Context Consistency Verification," begins. This phase uses a hash mapping mechanism to process transaction context fields (transaction type, amount, time, and subject matter), comparing each field in the current request with the fields recorded in the server cache when the binding token was generated, ensuring that each field is completely consistent with the original value.

[0044] Both phases are essential; the system allows transactions only if both verifications pass. Otherwise, a system lockout mechanism is triggered, suspending the user's trading privileges and logging the transaction. This structure significantly improves the transparency, controllability, and fault tolerance of the authentication process, particularly in resisting impersonation attacks and internal tampering, making it an essential component of building a highly reliable authentication system.

[0045] If the authentication token is consistent with the transaction context and has not been used, the transaction instruction is allowed to be executed and the authentication token is destroyed immediately; otherwise, the transaction request is rejected and the abnormal behavior log is recorded; Before destroying the authentication token, the server must first perform an integrity check; The inspection process includes confirming the token usage status, checking the token binding information, and verifying whether the processing time limit is within the set time window; After the verification is passed, the memory erasure mechanism is called to overwrite the original token cache area to ensure that it will not be acquired by subsequent calls due to memory residue; at the same time, the destruction time and execution process are recorded and entered into the chain to the tamper-proof log area to improve verifiability and regulatory transparency.

[0046] The purpose of the above steps is to control the lifecycle of the authentication token, ensuring that it is completely invalid after use and cannot be reactivated or called in any way by subsequent programs or attackers. In traditional authentication systems, the state transition of authentication tokens often carries the risk of delays, cache residue, or system misuse. Especially in high-concurrency, low-latency transaction environments, it is common for authentication data to be called multiple times, which can easily lead to illegal transactions or account anomalies. Therefore, this step proposes a full-link closed-loop control mechanism for the token lifecycle.

[0047] The mechanism is divided into three key stages: first, before the token is destroyed, the system automatically performs an integrity check to confirm that it is the first and only legal use; second, the verification process needs to check the user account, context data and timestamp bound to the token to confirm that it has not been activated prematurely or delayed; finally, the token will enter the destruction stage, and the server will use the memory erase mechanism to use multiple overwrite strategies (such as three random value writes) to physically clear the token cache.

[0048] To prevent malicious data restoration during maintenance or audits, the destruction process simultaneously generates a complete log record, including the token ID, usage time, destruction time, user IP address, transaction summary, and other information. This log record is written to an immutable log storage system (such as a blockchain audit chain) for verification by regulatory audit agencies. This method strictly controls and tracks authentication tokens at every stage of generation, use, and destruction, ensuring they cannot be misused, reused, or leaked. This is a key safeguard for enhancing the security of authentication tokens.

[0049] The specific steps to generate an authentication token are as follows: After receiving the client's authentication request data, the server extracts the current server timestamp, the user's unique identity code, and the pseudo-random number, and calculates the basic seed of the authentication token through XOR and hash function. The calculation expression is as follows: , where It is the basic seed value. Based on the current time, user identity and random number, a unique and unpredictable basic seed value is generated for subsequent encryption to generate the final authentication token. It is a hash function, such as SHA256, SHA3 and other irreversible cryptographic hash functions, The server's current timestamp indicates the current time recorded by the server in millisecond-level UNIX timestamps. This is used to introduce time sensitivity and make the authentication token short-lived. Is the user identity code, which represents the unique identifier generated by the client device through the user account (such as account hash, user ID), It is a pseudo-random number, which is a high-entropy random value generated when the client initiates an authentication request. It can be generated using an encryption-grade random function. It is a bitwise exclusive OR operation; Exclusive OR (XOR) operations and hash functions are two basic technical tools in the field of information security, commonly used in encryption and data protection.

[0050] The exclusive OR (XOR) operation is a bitwise logical operation. If two binary bits are the same, the result is 0, and if they are different, the result is 1. It has an important feature: XORing the same value twice will restore the original value, that is, In security protocols, XOR is often used to cheaply mix multiple input data to improve randomness and unpredictability.

[0051] A hash function is an algorithm that converts input data of any length into an output value of fixed length. The output value is called a hash value. The main characteristics of a hash function include: Irreversibility (the original data cannot be deduced from the hash value); Collision resistance (the probability of different inputs producing the same output is extremely low); Avalanche effect (a slight change in input will lead to a completely different output).

[0052] Common hash functions include SHA-1, SHA-256, SHA-3, etc., which are widely used in digital signatures, data integrity verification, password protection and other fields.

[0053] In this patented method, an XOR operation is used to mix the "timestamp, user identity code, and pseudo-random number", and the hash function then compresses the mixed result into a unique authentication seed, ensuring that the generated security token has high tamper resistance and unpredictability.

[0054] This step ensures that the authentication seed is time-sensitive, user-unique, and unpredictable, preventing replay and forgery.

[0055] The server analyzes the user's current behavior parameters, including intraday trading frequency, device activity, and the degree of deviation from the user's historical behavior, and calculates the behavior weight factor. The calculation expression is as follows: , where It is a weight factor, which represents the overall behavior credibility score and is used to participate in the generation of encrypted authentication tokens. It is used to increase the weight of active transaction behaviors and trusted devices, and reduce the weight of transaction behavior deviations. The intraday trading frequency indicates the total number of securities transactions conducted by the user in the current calendar day. It is used to measure the user's trading activity on that day. An increase in frequency can reflect normal user activity or increased system risk. It serves as an adjustment factor. The device activity level indicates the number of times the device has accessed the securities service platform within a period of time. This is usually calculated over the past seven days and is used to determine the familiarity and credibility of the device. If the access frequency of a new device is low, the risk factor is increased to prevent theft. It is the characteristic value of the current transaction amount distribution, indicating the ratio of the current transaction amount to the average transaction amount of users in the recent period, reflecting whether it is abnormal and used to determine whether the transaction amount deviates from the normal behavior pattern. It is the historical behavior benchmark characteristic value, which is the characteristic value of the user's long-term stable transaction amount distribution, and serves as a reference value for behavioral deviation; This weighting factor is used to adjust the strength of authentication tokens, dynamically adapting them to the risk environment. For example, if behavior deviates significantly, the token complexity is increased to effectively curb the risk of fraudulent use.

[0056] The server uses the AES symmetric encryption algorithm based on the seed value As the key, the behavior factor and the pseudo-random number product are encrypted to generate the authentication token core value. The generation formula is as follows: , where It is an advanced encryption standard encryption function, a symmetric encryption algorithm that uses a 128-bit or 256-bit key to encrypt data and encrypt authentication data into a token to ensure transmission security. It is the core value of the authentication token and is the encrypted token ultimately generated by the server. It is used for transaction security verification. The token will be attached to the transaction instruction and submitted to verify whether the transaction is initiated by a real user, at the correct time, and through a trusted device.

[0057] This encryption step ensures that the token has high-strength encryption protection, and the result generated for each request is unique and unpredictable, resisting various man-in-the-middle attacks and collision attacks.

[0058] The purpose of the above steps is to build a highly dynamic and personalized authentication token generation mechanism, fundamentally addressing the technical shortcomings of traditional authentication tokens, which are easily predictable and easily simulated. This step introduces a multi-parameter-driven strategy, binding the token generation process to multiple factors such as user identity, server time, pseudo-random numbers, and user behavior status, ensuring that each authentication token possesses the security properties of being non-copyable, non-reusable, and unpredictable. Its design principle is to utilize a mathematical hybrid calculation method to ensure that the generated token not only relies on a single identity information but also has behavioral contextual awareness, thereby raising the threshold for identifying potential attacks before they occur.

[0059] The implementation path of this mechanism is divided into three stages. The first stage is the initialization process. After the server receives the authentication request, it immediately collects the server timestamp of the request, the user's unique identifier (such as the user account or public key), and a pseudo-random number generated by the server. It uses a cryptographic hash function to combine these three as seed parameters to form the initial basis for token generation. The second stage is the behavioral dynamic analysis process. The system analyzes the current user's access behavior, including daily transaction frequency, network activity of access devices, and the distribution pattern of capital flows. The system constructs a user behavior feature model based on these dimensions and calculates the deviation value between current behavior and historical characteristics, thereby forming a weight factor for dynamic token regulation. The third stage is the token generation process. The server generates a unique token value based on the output parameters of the first two stages and encrypts it using a symmetric encryption algorithm to ensure that it is not hijacked or tampered with during network transmission.

[0060] The resulting authentication token not only uniquely corresponds to the current transaction request, but its internal components encompass three dimensions: time, behavior, and encryption. This makes it difficult for an attacker to reverse engineer the token value, even if they obtain partial parameters. This mechanism enhances the authentication process's ability to resist advanced forgery and automated attacks, representing a substantial upgrade to the traditional static token structure.

[0061] By binding a one-time authentication token to a specific transaction context and using an independent channel to transmit authentication information, this invention combines context-dependent transaction security verification with token uniqueness. This mechanism effectively prevents the illegal reuse of intercepted intermediate authentication data. Even if an attacker obtains the authentication token, they cannot restore the bound transaction context, thus failing the server's double verification. This design significantly enhances the unforgeability of transaction operations and the integrity verification of user identities, providing strong security protection for core transaction processes in securities systems.

[0062] This invention incorporates dynamic behavior analysis and a temporary token generation strategy into the authentication process. This dynamically adjusts the authentication token's structure and validity period based on historical user behavior, enhancing the system's sensitivity to anomalous trading patterns. When a user's trading behavior significantly deviates from previous patterns, the system proactively shortens the authentication cycle and strengthens authentication, enhancing the flexibility and responsiveness of overall risk control. This intelligent security response mechanism effectively addresses the traditional static authentication model's inability to identify unknown attack patterns, empowering trading platforms with stronger adaptive protection capabilities.

[0063] The embodiments of the present invention are described in detail above with reference to the accompanying drawings, but the present invention is not limited to the described embodiments. It is apparent to those skilled in the art that various changes, modifications, substitutions, and variations to these embodiments may be made without departing from the principles and spirit of the present invention, and these changes and modifications still fall within the scope of protection of the present invention.

Claims

1. A security verification method for securities trading, characterized in that: The following steps are involved: Before a user requests to conduct a securities transaction, the client generates first authentication request data and sends it to the server via an encrypted channel; After receiving the first authentication request data, the server generates a one-time authentication token based on a preset authentication algorithm and user identity information, and stores the one-time authentication token in the server session cache in conjunction with a unique transaction context corresponding to the one-time authentication token; The server returns the one-time authentication token to the client through an independent channel for subsequent transaction authentication; When submitting a transaction instruction, the client embeds a one-time authentication token and resends it to the server with the complete transaction context data; After receiving the transaction instruction, the server extracts the bound one-time authentication token from the cache and compares it with the transaction context to verify whether the two match and whether it is the first use; If the authentication token is consistent with the transaction context and has not been used, the transaction instruction is allowed to be executed and the authentication token is destroyed immediately; Otherwise, the transaction request will be rejected and the abnormal behavior log will be recorded.

2. A security verification method for securities trading according to claim 1, characterized in that: The first authentication request data includes a user device identifier, a current timestamp, a random challenge code, and a user account summary; The user device identifier is used to uniquely identify the terminal, the current timestamp is used to prevent replay attacks, the random challenge code is used for dynamic confirmation, and the user account summary is generated using a hash algorithm to prevent the leakage of real account information during transmission. After the client combines the data, it uses the elliptic curve encryption algorithm to generate an encrypted data packet, thereby improving the data protection strength during the authentication request process.

3. A security verification method for securities trading according to claim 1, characterized in that: When generating a one-time authentication token, the server dynamically calculates the user's historical transaction behavior characteristics; After comparing the behavioral characteristics with the current transaction background, the server adjusts the token lifespan based on the degree of deviation.

4. A security verification method for securities trading according to claim 3, characterized in that: The specific steps for transaction context matching verification are as follows: When the client initiates a transaction, it performs a structured concatenation of the transaction type, transaction amount, and transaction time, and generates a digest code using the SHA256 hash function. The generation formula is as follows: , where is the context summary code, is the transaction type, is the transaction amount, is the transaction timestamp; After receiving the digest code, the server uses the HMAC encryption mechanism and the private key to process it and generate a context hash value. The generation formula is as follows: , where is the server private key, Is the server-side context check code; The local binding hash value in the server call context cache and compare it with the newly calculated To match: If , the authentication is successful; otherwise, the authentication fails; Failure to match indicates that the context has been tampered with or the data has not been submitted in an authorized manner. The transaction will be rejected immediately and the exception log will be recorded as security tracking evidence.

5. A security verification method for securities trading according to claim 1, characterized in that: Independent channels are dedicated short-term encrypted channels that are dynamically established through the TLS1.3 protocol. The channels use self-generated key pairs and employ session-level encryption. Each session is used only once and then destroyed after token delivery and cannot be reused. Independent channels are physically separated and logically isolated from the main transaction channel. The authentication token adopts a one-way synchronous sending strategy to avoid the risk of authentication token leakage due to response blocking or playback delay, thereby improving the security level of information transmission.

6. A security verification method for securities trading according to claim 1, characterized in that: Transaction context data includes four elements: transaction type, transaction target code, transaction amount, and transaction trigger time; The context data is encrypted on the client side and sent along with the transaction instruction. It is used for binding token comparison on the server side. If any inconsistency is found between the transaction context and the original binding data, the transaction processing flow will be immediately interrupted even if the authentication token itself is legitimate, ensuring that the authentication mechanism not only verifies the user, but also verifies the integrity of the transaction instructions.

7. A security verification method for securities trading according to claim 1, characterized in that: The double comparison process consists of two stages: the first stage is the token ontology consistency verification, and the second stage is the context parameter consistency verification; The first stage uses a cryptographic digest algorithm to check the token value, and the second stage uses a hash map to compare the context fields item by item; Both stages must be verified before entering the transaction execution process. If either stage fails, the automatic blocking mechanism will be triggered and an abnormal verification event log will be generated in the user account.

8. A security verification method for securities trading according to claim 1, characterized in that: Before destroying the authentication token, the server must first perform an integrity check; The inspection process includes confirming the token usage status, checking the token binding information, and verifying whether the processing time limit is within the set time window; After the verification is passed, the memory erasure mechanism is called to overwrite the original token cache area to ensure that it will not be acquired by subsequent calls due to memory residue; at the same time, the destruction time and execution process are recorded and entered into the chain to the tamper-proof log area to improve verifiability and regulatory transparency.

9. A security verification method for securities trading according to claim 8, characterized in that: The specific steps to generate an authentication token are as follows: After receiving the client's authentication request data, the server extracts the current server timestamp, the user's unique identity code, and the pseudo-random number, and calculates the basic seed of the authentication token through XOR and hash function. The calculation expression is as follows: , where is the base seed value, is a hash function, is the server's current timestamp, Is the user identification code, is a pseudo-random number, It is a bitwise exclusive OR operation; The server analyzes the user's current behavior parameters, including intraday trading frequency, device activity, and the degree of deviation from the user's historical behavior, and calculates the behavior weight factor. The calculation expression is as follows: , where is the weight factor, is the frequency of intraday trading, is the device activity, is the characteristic value of the current transaction amount distribution, is the historical behavior benchmark characteristic value; The server uses the AES symmetric encryption algorithm based on the seed value As the key, the behavior factor and the pseudo-random number product are encrypted to generate the authentication token core value. The generation formula is as follows: , where is the Advanced Encryption Standard encryption function, It is the core value of the authentication token.

Images