Method, system and device for security signing of saas service

Abstract

The application provides a method, system and device for SaaS service security signing, comprising: a client sending a login request to a server; the server verifying the login request and returning dynamic password rule information to the client based on the login request and a current time window; the client generating a first password table corresponding to a dynamic key, hashing data of a business request according to an encoding rule table and embedding the hashed data into the first password table, obtaining a client request signature after shuffling, and sending the business request and the client request signature to the server; the server generating a second password table corresponding to the dynamic key, hashing data of the business request according to an encoding rule and embedding the hashed data into the second password table, obtaining a server request signature after shuffling, verifying the client request signature based on the server request signature, and returning a response result corresponding to the business request to the client after verification. The application can significantly improve the data integrity and security in the end-to-end communication process between the client and the server.

Description

Technical Field

[0001] This invention relates to the field of SaaS service security technology, and in particular to a method, system, and device for secure signature verification of SaaS services. Background Technology

[0002] Web (World Wide Web) application security is a crucial component of cybersecurity. During client-server interactions, the HTTP (Hypertext Transfer Protocol) protocol itself is typically stateless and transmits data in plaintext, failing to guarantee data security. HTTPS uses TLS (Transport Layer Security) / SSL (Secure Sockets Layer) encryption to ensure data security, but even so, it primarily protects the transport layer, preventing eavesdropping and tampering during transmission and ensuring data confidentiality and integrity. However, at the application layer, it doesn't provide absolute security guarantees for the processing between the two ends. Malware or attackers can still tamper with and forge data before client-side encryption. Therefore, relying solely on HTTPS is insufficient to address all application-layer threats, and numerous security risks remain, such as data tampering, request forgery, and replay attacks. Among them, data tampering refers to the attacker intercepting and modifying parameters in the request (such as user ID (identity document), URL parameters, request body content, etc.) before the request is sent, in order to achieve the purpose of unauthorized operation; request forgery refers to the attacker forging the request of a legitimate user, sending malicious information instructions to the server, and illegally obtaining data; replay attack refers to the attacker intercepting a legitimate request and sending the request repeatedly later, in order to achieve the purpose of repeatedly performing a certain operation.

[0003] To address these threats, the industry has developed various application-layer security mechanisms, including token authentication (such as JSON Web Token, JWT), OAuth authorization, API (Application Programming Interface) keys, and request signing. Request signing is a common mechanism; its core idea is that the client uses an agreed-upon algorithm and key to generate a signature on the key information of the request, and the server uses the same method to verify the signature to confirm the source and integrity of the request. Traditional signature mechanisms rely on fixed keys or relatively simple signature algorithms, and there is still a risk of key leakage or cracking under complex attack scenarios. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method, system and device for secure signature verification of SaaS services, which can significantly improve end-to-end data integrity and security during communication between the client and the server.

[0005] In a first aspect, this invention provides a method for secure signature verification of SaaS services. The method is applied to a target system, which includes a client and a server. The method includes:

[0006] The client sends a login request to the server;

[0007] The server verifies the login request and returns dynamic password rule information to the client based on the login request and the current time window. The dynamic password rule information includes at least a dynamic key and an encoding rule table. The encoding rule table contains multiple elements, and the value corresponding to the subscript index of the element is used to describe the embedding index of the string it is bound to in the password table.

[0008] The client generates a first cryptographic table corresponding to the dynamic key, hashes the data of the business request according to the encoding rule table and embeds it into the first cryptographic table. After the new first cryptographic table is shuffled, the client request signature is obtained. The business request and the client request signature are sent to the server.

[0009] The server generates a second cryptographic table corresponding to the dynamic key. The data of the business request is hashed according to the encoding rules and embedded into the second cryptographic table. The new second cryptographic table is shuffled to obtain the server-side request signature. The server-side request signature is used to verify the client-side request signature. After successful verification, the server returns the response result corresponding to the business request to the client.

[0010] In one implementation, the data of the business request is hashed according to the encoding rule table and embedded into a first cryptographic table. The new first cryptographic table is then shuffled to obtain the client request signature, including:

[0011] The client performs the following operations:

[0012] Perform mixed hashing on the request elements contained in the business request to obtain the hash string corresponding to the request element. The request element includes one or more of the following: tenant identifier, user identifier, request path, request parameters, and request body.

[0013] According to the encoding rule table, the hash string corresponding to the request element is embedded into the first password table to obtain a new first password table;

[0014] The new first cipher table is shuffled to generate the client request signature.

[0015] In one implementation, according to the encoding rule table, the hash string corresponding to the request element is embedded into the first cryptographic table to obtain a new first cryptographic table, including:

[0016] The client performs the following operations:

[0017] From the elements contained in the encoding rule table, determine the target element to which the request element is bound;

[0018] Based on the embedding index described by the subscript index of the target element, the hash string corresponding to the requested element is used to replace the random string corresponding to the element at the embedding index in the first cipher table, resulting in a new first cipher table.

[0019] In one implementation, the new first cryptographic table is shuffled to generate a client request signature, including:

[0020] The client performs the following operations:

[0021] The elements in the new first cipher table are shuffled using a dynamic key. The strings corresponding to the elements in the shuffled first cipher table are then concatenated to obtain the client request signature.

[0022] In one implementation, shuffling the elements contained in the new first cryptographic table based on a dynamic key includes:

[0023] Generate the current element index based on the dynamic key, and construct the rearrangement interval corresponding to the current element index;

[0024] Determine the index of the element to be swapped based on the rearranged interval;

[0025] Swap the string corresponding to the element at the current element index with the string corresponding to the element at the index of the element to be swapped.

[0026] Update the current element index, construct the new rearrangement interval corresponding to the current element index, and stop element swapping when the preset conditions are met, thereby shuffling the elements contained in the new first cipher table.

[0027] In one implementation, generating a first cryptographic table corresponding to the dynamic key includes:

[0028] The client performs the following operations:

[0029] Encode the dynamic key to obtain the encoded array corresponding to the dynamic key;

[0030] Perform a hash calculation on the encoded array, and generate a random seed corresponding to the dynamic key based on the hash calculation result;

[0031] Multiple random strings are generated using a random seed to obtain a first cipher table; the number of random strings is the same as the number of elements in the first cipher table.

[0032] In one implementation, the dynamic password rule information further includes the remaining validity period; verification of the client request signature based on the server-side request signature includes:

[0033] The server performs the following operations:

[0034] Determine whether the server-side request signature matches the client-side request signature, and whether the remaining validity period is not 0;

[0035] If any judgment result is negative, the verification will be retried based on the dynamic password rule information corresponding to the previous time window. If any judgment result during the retried verification process is still negative, the verification will be deemed unsuccessful.

[0036] If all the judgment results are yes, the verification is successful.

[0037] Secondly, this invention also provides a system for secure signature verification of SaaS services, including a client and a server:

[0038] The client is used to: send login requests to the server;

[0039] The server is used to: verify login requests and, based on the login request and the current time window, return dynamic password rule information to the client. The dynamic password rule information includes at least a dynamic key and an encoding rule table. The encoding rule table contains multiple elements, and the value corresponding to the subscript index of each element is used to describe the embedding index of the string it is bound to in the password table.

[0040] The client is used to: generate the first cryptographic table corresponding to the dynamic key, hash the data of the business request according to the encoding rule table and embed it into the first cryptographic table, obtain the client request signature after the new first cryptographic table is shuffled, and send the business request and the client request signature to the server.

[0041] The server-side is used to: generate a second cryptographic table corresponding to the dynamic key; hash the data of the business request according to the encoding rules and embed it into the second cryptographic table; obtain the server-side request signature after the new second cryptographic table is shuffled; verify the client-side request signature based on the server-side request signature; and return the response result corresponding to the business request to the client after the verification is successful.

[0042] Thirdly, the present invention also provides an electronic device including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement any of the methods provided in the first aspect.

[0043] Fourthly, the present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement any of the methods provided in the first aspect.

[0044] This invention provides a method, system, and device for secure signature verification of SaaS services. The client sends a login request to the server. Based on the login request and the current time window, the server returns dynamic password rule information to the client. This dynamic password rule information includes at least a dynamic key and an encoding rule table. The encoding rule table contains multiple elements, and the index of each element describes the embedding index of the string it is bound to in the password table. The client generates a first password table corresponding to the dynamic key, hashes the data of the business request according to the encoding rule table, embeds it into the first password table, and after shuffling, obtains the client request signature. The business request and the client request signature are then sent to the server. The server generates a second password table corresponding to the dynamic key, hashes the data of the business request according to the encoding rule, embeds it into the second password table, and after shuffling, obtains the server request signature. The server verifies the client request signature based on the server request signature, and upon successful verification, returns the response result corresponding to the business request to the client. The above method proposes an enhanced request signature verification mechanism. Based on a password table and an encoding rule table of random strings, the data of the business request is hashed and embedded into the password table to obtain the client request signature. The server-side request signature is generated based on the same logic, and the two are verified and compared to ensure the security and integrity of the data, thereby fundamentally improving the security protection capabilities of existing secure signature verification.

[0045] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0046] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0047] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0048] Figure 1 This is a flowchart illustrating a method for secure signature verification of SaaS services provided in an embodiment of the present invention.

[0049] Figure 2 A schematic diagram of a system architecture provided for an embodiment of the present invention;

[0050] Figure 3 This is a schematic diagram of another system architecture provided in an embodiment of the present invention;

[0051] Figure 4 This invention provides a technical framework diagram of a method for secure signature verification of SaaS services.

[0052] Figure 5 A schematic diagram of a mapping process provided in an embodiment of the present invention;

[0053] Figure 6 This is a schematic diagram illustrating the principle of a shuffling process provided in an embodiment of the present invention;

[0054] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] Currently, existing web security signature verification schemes mainly suffer from the following drawbacks: Static keys are easily leaked and cracked: Traditional schemes typically use fixed keys, which are valid for a long time once generated, unless manually or dynamically rotated. Once leaked or stolen, requests can be forged. Insufficient signature algorithm security: Traditional signature algorithms and logic are standardized and transparent. Attackers who obtain the key can arbitrarily tamper with data, construct legitimate requests, and illegally obtain data. Lack of dynamic signature mechanisms: The signature generation logic of traditional schemes is relatively simple and lacks dynamic change mechanisms, making them vulnerable to attack through analysis and cracking. Exposed client logic: The client-side code's data assembly and preprocessing logic is usually not effectively protected or obfuscated. Attackers can easily obtain the key and all implementation details of the signature algorithm through reverse engineering, decompiling, or debugging, thereby bypassing security protections.

[0057] Based on this, the present invention provides a method, system, and device for secure signature verification of SaaS services, which can significantly improve end-to-end data integrity and security during communication between the client and the server.

[0058] To facilitate understanding of this embodiment, a method for secure signature verification of SaaS services disclosed in this embodiment will first be described in detail. This method is applied to a target system, such as an integrated talent management platform. The target system includes a client and a server. See [link to relevant documentation]. Figure 1 The diagram illustrates a method for secure signature verification of SaaS services, which mainly includes the following steps S102 to S108:

[0059] In step S102, the client sends a login request to the server.

[0060] In step S104, the server verifies the login request and returns dynamic password rule information to the client based on the login request and the current time window. The dynamic password rule information includes at least the dynamic key and the encoding rule table, and may also include the remaining validity period.

[0061] The encoding rule table contains multiple elements. The index of each element describes the embedding index of the string it is bound to in the password table. This password table is called the first password table and the second password table. The embedding index is the index of the element in the password table where the string is to be embedded. It should be noted that the terms "first" and "second" in the first and second password tables are only used to distinguish between the password tables generated by the client and the server, and have no actual meaning.

[0062] In step S106, the client generates a first cryptographic table corresponding to the dynamic key, hashes the data of the business request according to the encoding rule table, and embeds it into the first cryptographic table. After the new first cryptographic table is shuffled, the client request signature is obtained, and the business request and the client request signature are sent to the server.

[0063] In one example, a random seed is generated based on the dynamic key, and multiple random strings are randomly generated based on the random seed as the first cryptographic table. The strings consist of numbers 0-9 and uppercase and lowercase letters a, b, and c. From the elements contained in the encoding rule table, the target elements bound to the request elements contained in the business request are randomly assigned. Then, according to the embedding index described by the subscript index of the target element, the request elements contained in the business code are subjected to mixed hashing, and the corresponding hash string is embedded into the element corresponding to the embedding index in the first cryptographic table. After shuffling and string concatenation, the client request signature can be obtained.

[0064] In step S108, the server generates a second cryptographic table corresponding to the dynamic key, hashes the data of the business request according to the encoding rules and embeds it into the second cryptographic table, and obtains the server request signature after the new second cryptographic table is shuffled. The server request signature is used to verify the client request signature, and the response result corresponding to the business request is returned to the client after the verification is successful.

[0065] In one example, the server generates a server-side request signature according to the same logic. It then performs multiple rounds of signature comparison and verification between the server-side request signature and the client-side request signature, taking into account the remaining validity period of the current time window. After passing the verification, it executes the business logic corresponding to the business request and returns the response result to the client.

[0066] The present invention provides a method for secure signature verification of SaaS services, which proposes an enhanced request signature verification mechanism. Based on a password table and an encoding rule table of random strings, the data of the business request is hashed and embedded into the password table to obtain the client request signature. The server-side request signature is generated based on the same logic, and the two are verified and compared to ensure the security and integrity of the data, thereby fundamentally improving the security protection capabilities of existing secure signature verification.

[0067] Given the widespread adoption of SaaS applications and the continuous evolution of cyberattack methods, traditional web security verification mechanisms face increasingly severe challenges. Data may be tampered with, forged, or replayed during the request process, posing a serious threat to tenant data security and the correctness of business logic. This invention proposes a specific implementation method for secure signature verification of SaaS services. By introducing a signature algorithm employing multiple security technologies such as dynamic password tables, encoding rule tables, multiple hashing, reshuffling, and code obfuscation, it achieves high-strength signature verification of web requests, enhancing the security of client-server communication and the security protection capabilities of SaaS applications.

[0068] First, the system architecture will be explained. (See below) Figure 2 The diagram shown is a schematic of a system architecture. Figure 2 This illustration shows the client-server collaborative verification architecture used in an embodiment of the present invention. See also... Figure 3 Another system architecture diagram is shown below. Figure 3The system provided in this embodiment of the invention mainly includes the following core components: Client-Signature Generation: Responsible for obtaining user keys and encoding tables, generating password tables, and generating request signatures according to rules; Server-Signature Verification: Responsible for signature generation and verification, and security event recording (this logic is built into the gateway); Server-Dynamic Password Rule Management Service: Responsible for the generation, distribution, storage, and updating of dynamic keys and encoding rule tables. (Dynamic keys and encoding rule tables are automatically updated after expiration; dynamic keys are used to generate password tables); Server-Business Services: Implement specific business logic and functions based on a domain model, typically divided into multiple independent microservice units according to the business domain.

[0069] Different tenants or users can configure independent security policy levels such as signature algorithms, key management, and encoding rules to achieve security isolation between tenants or even between users, prevent the spread of security risks across tenants and users, and ensure that even if the security mechanism of a certain tenant or user is cracked, it will not affect other tenants.

[0070] By embedding the server-side signature generation and verification logic within the gateway, the main purpose is to complete security verification and malicious request filtering before requests reach the backend business services. This reduces the computational burden and network pressure on the backend servers. At the same time, by leveraging the gateway's high concurrency processing capabilities and unified entry point, faster security response speeds, more centralized security policy management, and better system architecture decoupling are achieved. This allows the gateway to focus on security protection while the backend focuses on business logic, thereby significantly improving overall system performance and maintainability while ensuring security.

[0071] Based on the above system architecture, see Figure 4The diagram illustrates a technical framework for a SaaS service security signature verification method, primarily comprising client-side and server-side components. The client-side component includes processes such as client request authentication, obtaining tenant user ID information, obtaining a dynamic key and encoding rule table, generating a password table based on the dynamic key, request element index allocation, various hash calculations for request elements, updating and reshuffling the dynamic password table, concatenating the signature string and generating the final client request signature, and request construction and signature appending. The server-side component includes processes such as server authentication, obtaining a dynamic key and encoding rules, generating a password table based on the dynamic key, obtaining request parameters, various hash calculations for request parameters, updating and reshuffling the dynamic password table, concatenating the signature string and generating the final server-side request signature, and multi-round signature comparison verification. The multi-round signature comparison verification process involves verifying whether the client and server signatures match. If they match, the request is processed; otherwise, it continues to check if the comparison threshold has been exceeded. If not, the password table and encoding rule table from the previous window are retrieved, and the process of "updating and reshuffling the dynamic password table, concatenating the signature string and generating the final server-side request signature" is repeated. If the threshold is exceeded, the request is rejected.

[0072] based on Figure 4 The technical framework shown in this invention provides a specific implementation of a method for secure signature verification of SaaS services. This includes:

[0073] (a) Client authentication: Users follow the standard authentication process (username / password) and send a login request to the server through the client to complete the login verification.

[0074] (ii) Server-side authentication: After receiving the login request from the client, the server performs authentication to obtain the login user ID and the tenant ID to which it belongs.

[0075] (III) Client obtains dynamic password rule table: Based on the user's login identity information, the client sends a request to the server's dynamic password rule management service. The server returns information such as the key and encoding rule table based on the current time window, tenant ID, and user ID. The data returned is different for each tenant user, and is time-sensitive and unique.

[0076] For example:

[0077] "key": "secret_2025",

[0078] "patch": [15, 28, 45, 36, 72, 89, 81, 62, 25, 33],

[0079] "ttl": 600

[0080] The dynamic key (Key) is used to generate 100 random strings, i.e., the password table (Table). The encoding rule table (Patch) contains 10 elements, with indices ranging from 0 to 9. The value corresponding to each index is a unique integer between 0 and 99. The value at each index determines the position in the password table (Table) where the hashed key information should be inserted. TTL (Time To Live) represents the remaining validity period (in seconds). This information is time-sensitive and unique; expired information is unusable and needs to be retrieved again.

[0081] (iv) The client generates 100 random strings (password table) based on the dynamic key Key: the dynamic key Key is encoded to obtain the encoding array corresponding to the dynamic key Key; the encoding array is hashed to generate the random seed corresponding to the dynamic key Key based on the hash calculation result; multiple random strings are generated using the random seed to obtain the first password table; wherein the number of random strings is consistent with the number of elements in the first password table.

[0082] In the specific implementation, the client generates a 32-bit integer random seed based on the dynamic key Key. Then, it randomly generates 100 strings (consisting of digits 0-9 and uppercase and lowercase letters a, b, a) based on the seed, which serve as the first password table. For example, if the dynamic key Key is "secret_2025", the string Key is first converted to a UTF-8 byte array, and then a hash value is calculated using SHA-256, resulting in a 32-byte (256-bit) hash result. Subsequently, the first 4 bytes of the hash result are extracted using BitConverter.ToInt32(hash) and converted to a 32-bit integer. In this process, if configured for little-endian (low byte first), the first four bytes are read in byte order, resulting in a random seed of 2,004,074,403. Conversely, if configured for big-endian (high byte first), the byte order is reversed, resulting in the absolute value of a random seed of 1,563,781,510. Finally, 100 random strings are generated based on the random seed as the first cipher table and cached. This first cipher table becomes unusable after expiration and needs to be regenerated.

[0083] (v) The client hashes the data of the business request according to the encoding rule table and embeds it into the first cryptographic table to obtain the client request signature. This includes the processes of request element index allocation, various hash calculations of request elements, dynamic cryptographic table updates and reshuffling, concatenating the signature string, and generating the final client request signature. In specific implementation, the client performs the following operations:

[0084] (5.1) Perform mixed hashing on the request elements contained in the business request to obtain the hash string corresponding to the request element. The request element includes one or more of the following: tenant ID, user ID, request path, request parameters, and request body. The five request elements are: TenantID: unique identifier of the current tenant; UserID: unique identifier of the current user; Path: URL path of the request; Querystring: URL query parameter string; Body: request body content (JSON or form data).

[0085] In practice, the tenant ID, user ID, request path (Path), request parameter (Querystring), and the actual request value in the request body are each subjected to a hybrid hash calculation. The hash algorithm can be MD5, SHA1, or SHA256, balancing computational efficiency and security. Note: For the request parameter (Querystring), it is first sorted by name (AZ) before applying the hash algorithm to prevent server-side verification failure due to changes in parameter position. Example:

[0086] HashTenantID = SHA1(TenantID)

[0087] HashUserID = SHA1(UserID)

[0088] HashPath = MD5(Path)

[0089] HashQuerystring = MD5(Sort(Querystring))

[0090] HashBody = SHA256(Body).

[0091] (5.2) According to the encoding rule table, embed the hash string corresponding to the request element into the first cryptographic table to obtain a new first cryptographic table. Specifically:

[0092] (5.21) Determine the target element bound to the request element from the elements contained in the encoding rule table. In specific implementation, the five request elements, namely tenant ID, user ID, request path, request parameter querystring, and request body, are randomly (fixed) assigned to the corresponding target elements in the encoding rule table. For example, the elements corresponding to the five subscript indices 0, 1, 3, 5, and 9 are the target elements bound to each request element. That is, the tenant ID index is 0, the user ID index is 1, the path index is 3, the querystring index is 5, and the body index is 9.

[0093] Example: Five elements are assigned encoding rule table indices, corresponding to password table indices:

[0094] TenantID → Index 0 → Patch[0] → Table Location Index Patch

[15]

[0095] UserID → Index 1 → Patch[1] → Table Location Index Patch

[28]

[0096] Path → Index 3 → Patch[3] → Table Location Index Patch

[36]

[0097] Querystring → Index 5 → Patch[5] → Table position index Patch

[89]

[0098] Body → Index 9 → Patch[9] → Table Location Index Patch

[33] .

[0099] (5.22) According to the embedding index described by the subscript index of the target element, replace the random string corresponding to the element at the embedding index in the first cipher table with the hash string corresponding to the request element, and obtain a new first cipher table.

[0100] In practice, based on the mapping relationship between the request elements, the encoding rule table, and the password table, the calculated hash value is replaced in the corresponding position in the password table. For example, see [link to example]. Figure 5 The diagram shown illustrates a mapping process:

[0101]

[0102] Please refer to the example again, which involves replacing the random string at position 15 of the first password table with the hash string corresponding to the tenant ID. The updated password table has a length of 100, with 5 positions containing the hash value of the newly replaced request element and 95 positions containing the original random string.

[0103] (5.3) Generate a client request signature based on the new first cipher table. Specifically: Shuffle the elements contained in the new first cipher table based on the dynamic key, and concatenate the strings corresponding to the elements in the shuffled first cipher table to obtain the client request signature.

[0104] The shuffling process is as follows: Generate the current element index based on the dynamic key, and construct the rearrangement interval corresponding to the current element index; determine the index of the element to be swapped based on the rearrangement interval; swap the string corresponding to the element at the current element index with the string corresponding to the element at the index of the element to be swapped; update the current element index, construct the new rearrangement interval corresponding to the current element index, and stop the element swapping when the preset conditions are met, thereby realizing the shuffling process of the elements contained in the new first cipher table.

[0105] In practice, the updated first cipher table is randomly rearranged using a shuffling algorithm based on the dynamic key Key. After shuffling, the positions of the elements in the cipher table are completely rearranged, but the content of the elements remains unchanged. The core logic of the shuffling process is to traverse backwards from the end of the array. In each step, such as... Figure 6 The diagram illustrates the principle of a card shuffling process. It includes:

[0106] Randomly select an index: Based on the random seed generated by the dynamic key Key, determine the index i of the current element, take the index i of the current element as the end of the array, construct the rearrangement interval [0, i], and generate a random integer j in the range [0, i] as the index of the element to be swapped.

[0107] Swap elements: Swap the string at index i of the current element with the string at index j of the element to be swapped.

[0108] Move forward: Decrement the index of the current element i by 1, and repeat the above process until the beginning of the array is reached.

[0109] This algorithm generates the same random sequence based on a dynamic key (key). By gradually narrowing the range of random selections, it reshuffles the first cryptographic table. This shuffling randomly rearranges the entire first cryptographic table, completely disrupting the original index-ordered elements. This makes it impossible for an attacker, even knowing the replacement positions of the hash values, to predict the final concatenation order of the signature string. The shuffling process uses a deterministic random number generator to ensure that, with the same input dynamic key (key), the client and server produce the same shuffling result, thus guaranteeing the consistency of signature verification.

[0110] The string concatenation process is as follows: Concatenate the 100 elements of the first cipher table after shuffling into a complete string in order:

[0111] ConcatString = Table[0] + Table[1]+ ... + Table

[99]

[0112] Perform a SHA256 hash calculation on the concatenated string ConcatString to generate the final client signature: RequestSign = SHA256(ConcatString). This signature is unique and unpredictable.

[0113] (vi) Client request construction and signature appending: The client constructs an HTTP request and appends the RequestSign signature parameter to the end of the original request QueryString, https: / / {Domain} / {Path} / {Querystring}&RequestSign={RequestSign}. Then, together with relevant Cookie, Header, Body and other information, the request is sent to the server.

[0114] (vii) Client-side code obfuscation: Using professional JavaScript obfuscation tools to perform multi-layered processing and protection on the client-side code logic to reduce code readability, making it difficult for humans to read, understand, and reverse engineer, thereby increasing the cost and difficulty for attackers to crack the code. Examples include replacing meaningful variable names and function names with random character sequences; string encryption / encoding; control flow flattening; inserting invalid code logic; adding invalid function calls, etc.

[0115] (viii) Server-side retrieval of dynamic password rule table: Based on the tenant ID and user ID, the server retrieves the same dynamic key (Key) and encoding rule table (Patch) as the client from the internal backend dynamic password rule management service. To prevent boundary deviations within the time window, the server will simultaneously return the key (Key) and encoding rule table from the previous time window (the number of returned windows is configurable). If the server-side and client signatures do not match, the server will attempt to re-verify the signature using information from the previous time window, thus downgrading and increasing fault tolerance. Additionally, the dynamic keys in the dynamic password rule management service are stored in isolated tenant-level key environments.

[0116] (ix) The server generates 100 random strings (password table) based on the dynamic key Key: It executes the same logic as the client, generating a 32-bit integer seed based on the dynamic key Key. Then, based on the seed, it generates 100 random strings (strings consisting of digits 0-9 and uppercase and lowercase letters a, b, a), which are used as the password table and cached. Similar to the client, the password table becomes unusable after expiration, and the server needs to regenerate it.

[0117] (x) The server hashes the business request data according to the encoding rule table and embeds it into the second cryptographic table to obtain the server-side request signature. This includes obtaining request parameters, performing various hash calculations on the request parameters, dynamically updating and reshuffling the cryptographic table, concatenating the signature string, and generating the final server-side request signature. In specific implementation, the server performs the following operations:

[0118] Obtain request parameters: Extract tenant ID, user ID, request path, request parameter querystring, request body, and client signature RequestSign from the client request.

[0119] Multiple hash calculations are performed on request parameters: SHA1, MD5, or SHA256 hash calculations are performed on the extracted tenant ID, user ID, request path, request parameter Querystring, and request body, respectively. This process is completely consistent with the client. For the request parameter Querystring, the RequestSign parameter and its value are removed before applying the hash algorithm, and then sorted by name (AZ).

[0120] For example:

[0121] HashTenantID = SHA1(TenantID)

[0122] HashUserID = SHA1(UserID)

[0123] HashPath = MD5(Path)

[0124] HashQuerystring = MD5(Sort(RemoveRequestSign(Querystring)))

[0125] HashBody = SHA256(Body)

[0126] Update the second cryptographic table: The server executes the same logic as the client, replacing the corresponding hash string with the corresponding index position in the second cryptographic table based on the second cryptographic table and the encoding rule table.

[0127] For example:

[0128] Table[Patch[0]] = HashTenantID

[0129] Table[Patch[1]] = HashUserID Table[Patch[3]] = HashPath

[0130] Table[Patch[5]] = HashQuerystring Table[Patch[9]] = HashBody

[0131] Reshuffling the dynamic cipher table: The updated second cipher table is randomly rearranged using a shuffling algorithm based on the dynamic key Key. After shuffling, the positions of the elements in the cipher table are completely rearranged, but the content of the elements remains unchanged.

[0132] Generate server request signature: Concatenate all elements in the reshuffled second cipher table into a complete string ConcatString, perform SHA256 hashing, and finally generate the server signature ServerSign.

[0133] ConcatString = Table[0] + Table[1]+ ... + Table

[99] ServerSign =SHA256(ConcatString).

[0134] (xi) The server-side verification of the client-side request signature based on the server-side request signature includes: determining whether the server-side request signature ServerSign and the client-side request signature RequestSign are consistent and whether the remaining validity period is not 0; if either judgment result is negative, a re-signing test is performed based on the dynamic password rule information corresponding to the previous time window, and if either judgment result in the re-signing test is still negative, the verification is deemed to fail; if both judgment results are positive, the verification is deemed to pass.

[0135] In practice, the client's RequestSign is compared with the server's ServerSign. If the signatures match, the verification passes, indicating that the request is valid and the data has not been tampered with. The server accepts the request and submits it for further business processing. Otherwise, the signatures do not match, and a re-signing attempt is performed using the password table and encoding rule table from the previous time window. If they still do not match, it indicates that the request may have been modified, expired, or forged. In this case, the server will reject the request, return a security warning message, and record a security event in the security event log.

[0136] Retrying multiple rounds of signature verification is primarily for fault tolerance and degradation, aiming to improve system continuity and user experience. The number of comparison rounds is configurable, with each round corresponding to different password tables and encoding rule tables within a time window. If the maximum round threshold is reached, the request will be rejected directly. Additionally, if the number of failures within a short period reaches the required security policy threshold, the client IP will be blocked, preventing further requests.

[0137] In summary, the method for secure signature verification of SaaS services provided in this embodiment of the invention includes at least the following key technical points:

[0138] (1) Dynamic randomized signature mechanism:

[0139] Unlike traditional fixed-key signature schemes, the signature elements in this embodiment of the invention have a high degree of dynamism and randomness.

[0140] Unpredictability: The dynamic password table and encoding rule table within each time window are dynamically and randomly generated, and attackers cannot predict the generation of future signature requests based on historical data.

[0141] Personalized customization: Each tenant and user can have their own password table and encoding rules to provide different levels of security. For example, whether a shared link is for exclusive use by the user or shared within the same tenant.

[0142] Algorithm uniqueness: The signature algorithm achieves uniqueness through dynamic mapping of multiple hash algorithms with cipher tables and encoding rule tables, as well as random rearrangement of the shuffling algorithm, increasing unpredictability and the difficulty of reverse analysis.

[0143] Double randomization: Combining a dynamic cipher table and a shuffling algorithm, it achieves double protection of content randomness and position randomness.

[0144] (2) Time window fault tolerance mechanism:

[0145] The mechanism is based on a time window for dynamic password table updates and provides fault-tolerant verification functionality for the previous time window.

[0146] Time synchronization tolerance: Solves the technical challenge of time synchronization between clients and servers in a distributed environment.

[0147] User experience optimization: Avoids the possibility of legitimate requests being mistakenly rejected due to time differences.

[0148] Security Guarantee: Replay attacks are prevented by limiting the number and duration of fault-tolerant windows.

[0149] (3) Multi-layered encryption protection system:

[0150] Construct a multi-layered security protection system that includes keys, multiple hashing algorithms, and code obfuscation.

[0151] Progressive encryption strength: from transport layer encryption to application layer signature, from client to server, achieving end-to-end security protection.

[0152] Diverse algorithms: Employing multiple hash algorithms such as MD5, SHA1, and SHA256 increases the complexity of algorithm analysis.

[0153] Code protection: Effective protection of client-side signature generation logic is achieved through JavaScript obfuscation techniques, preventing reverse engineering.

[0154] Preventing cross-tenant and cross-user security risks: Different tenants or users can configure independent signature algorithms, keys, password tables, encoding rules and other management policies and security levels to achieve secure isolation between tenants and even between users, effectively preventing the spread of security risks across tenants and users.

[0155] Chaining and nesting: Using a cipher table and an encoding rule table, the request elements are hashed, and these hash values ​​are embedded into the cipher table according to the encoding rules. The table is then reshuffled, and finally, the shuffled cipher tables are concatenated and hashed using SHA256 to generate the final signature. This layered and interlocking approach of multiple algorithms further enhances the security of the signature algorithm, making it difficult for attackers to predict and reproduce the signature generation process.

[0156] The enhanced request signature verification mechanism provided in this invention, based on a dynamic random string password table and encoding rule table (password table filling rules), and a Web secure signature verification scheme using multiple hybrid hash algorithms, aims to improve end-to-end data integrity and security during client-server communication. Its core lies in introducing a dynamic key and encoding rule table, dynamically generated by the server and time-sensitive for a specific tenant / user. After obtaining this information, the client generates a password table based on the dynamic key, then applies multiple hash algorithms to the key parameters of the request to be sent (tenant ID, user ID, request path, query parameters, request body), dynamically embeds the hash results into the password table according to the encoding rules, and reshuffles the result to generate the client request signature. The server then uses the same logic as the client to generate its own request signature and compares the two signatures to ensure data security and integrity, thereby fundamentally improving the security protection capabilities of existing Web secure signature verification.

[0157] The request signature verification security mechanism proposed in this invention, based on a "dynamic cryptographic table, encoding rule table, and multi-hash hybrid" approach, effectively overcomes the static nature and reversibility of traditional signature schemes. It utilizes a dynamic key (Key) and an encoding rule table distributed by the server.

[0158] By employing a series of measures, including dynamic index mapping for each request, multi-level hash nesting of request elements, reshuffling, and front-end obfuscation, the security strength of web requests in request transmission and integrity verification is significantly improved. This greatly enhances the ability to resist forgery, tampering, cracking, and replay attacks. Compared to traditional solutions, this solution is highly practical and innovative, providing more secure and reliable protection. The embodiments of this invention have at least the following characteristics:

[0159] (1) Enhance anti-tampering capability: By hashing the key elements of the request using multiple algorithms, and combining the password table and the encoding rule table, the hashed elements are integrated into the signature process, so that any minor changes to these contents will cause the server signature verification to fail, thus ensuring the integrity of the data during the request process.

[0160] (2) Resisting replay attacks: The dynamic password table and encoding rule mechanism based on the time window validity period effectively prevents expired requests from being requested again.

[0161] (3) Increase the difficulty of reverse analysis: By obfuscating the code, the client signature generation logic is effectively protected, which increases the difficulty for attackers to reverse analyze the signature generation logic and increases the attack cost for malicious users.

[0162] (4) Enhance key security: Personalized key management and regular update mechanism to reduce the risk of key leakage.

[0163] Based on the foregoing embodiments, this invention provides a system for secure signature verification of SaaS services, including a client and a server:

[0164] The client is used to: send login requests to the server;

[0165] The server is used to: verify login requests and, based on the login request and the current time window, return dynamic password rule information to the client. The dynamic password rule information includes at least a dynamic key and an encoding rule table. The encoding rule table contains multiple elements, and the value corresponding to the subscript index of each element is used to describe the embedding index of the string it is bound to in the password table.

[0166] The client is used to: generate the first cryptographic table corresponding to the dynamic key, hash the data of the business request according to the encoding rule table and embed it into the first cryptographic table, obtain the client request signature after the new first cryptographic table is shuffled, and send the business request and the client request signature to the server.

[0167] The server-side is used to: generate a second cryptographic table corresponding to the dynamic key; hash the data of the business request according to the encoding rules and embed it into the second cryptographic table; obtain the server-side request signature after the new second cryptographic table is shuffled; verify the client-side request signature based on the server-side request signature; and return the response result corresponding to the business request to the client after the verification is successful.

[0168] The system for secure signature verification of SaaS services provided in this invention proposes an enhanced request signature verification mechanism. Based on a password table and an encoding rule table of random strings, the data of the business request is hashed and embedded into the password table to obtain the client request signature. The server-side request signature is generated based on the same logic, and the two are verified and compared to ensure the security and integrity of the data, thereby fundamentally improving the security protection capabilities of existing secure signature verification.

[0169] The system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0170] This invention provides an electronic device, specifically, the electronic device includes a processor and a storage device; the storage device stores a computer program, and the computer program, when run by the processor, executes the method described in any of the above embodiments.

[0171] Figure 7The present invention provides a schematic diagram of the structure of an electronic device 100, which includes a processor 70, a memory 71, a bus 72 and a communication interface 73. The processor 70, the communication interface 73 and the memory 71 are connected through the bus 72. The processor 70 is used to execute executable modules, such as computer programs, stored in the memory 71.

[0172] The memory 71 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 73 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0173] Bus 72 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0174] The memory 71 is used to store programs. After receiving an execution instruction, the processor 70 executes the programs. The method executed by the device for defining the flow process disclosed in any of the foregoing embodiments of the present invention can be applied to the processor 70 or implemented by the processor 70.

[0175] The processor 70 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 70 or by instructions in software form. The processor 70 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 71. Processor 70 reads the information in memory 71 and, in conjunction with its hardware, completes the steps of the above method.

[0176] The computer program product of the readable storage medium provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the foregoing method embodiments. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0177] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0178] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for secure signature verification of SaaS services, characterized in that, The method is applied to a target system, the target system including a client and a server, and the method includes: The client sends a login request to the server; The server verifies the login request and, based on the login request and the current time window, returns dynamic password rule information to the client. The dynamic password rule information includes at least a dynamic key and an encoding rule table. The encoding rule table contains multiple elements, the subscript index of the element is used to describe the string it is bound to, and the value corresponding to the element is used to describe the embedding index of the string in the password table. The client generates a first cryptographic table corresponding to the dynamic key, hashes the data of the business request according to the encoding rule table and embeds it into the first cryptographic table, and obtains the client request signature after the first cryptographic table is shuffled, and sends the business request and the client request signature to the server. The server generates a second cryptographic table corresponding to the dynamic key, hashes the data of the business request according to the encoding rules, and embeds it into the second cryptographic table. After the second cryptographic table is shuffled, a server-side request signature is obtained. The server-side request signature is used to verify the client-side request signature. After successful verification, a response result corresponding to the business request is returned to the client.

2. The method for secure signature verification of SaaS services according to claim 1, characterized in that, The data of the business request is hashed according to the encoding rule table and embedded into the first cryptographic table. The new first cryptographic table is then shuffled to obtain the client request signature, which includes: The client performs the following operations: The request elements contained in the business request are subjected to mixed hash processing to obtain the hash string corresponding to the request element. The request element includes one or more of the following: tenant identifier, user identifier, request path, request parameters, and request body. According to the encoding rule table, the hash string corresponding to the request element is embedded into the first password table to obtain a new first password table; The new first cipher table is shuffled to generate a client request signature.

3. The method for secure signature verification of SaaS services according to claim 2, characterized in that, According to the encoding rule table, the hash string corresponding to the request element is embedded into the first password table to obtain a new first password table, including: The client performs the following operations: From the elements contained in the encoding rule table, determine the target element to which the request element is bound; According to the embedding index described by the target element, the hash string corresponding to the request element is used to replace the random string corresponding to the element at the embedding index in the first password table, so as to obtain a new first password table.

4. The method for secure signature verification of SaaS services according to claim 2, characterized in that, The new first cryptographic table, after being shuffled, generates a client request signature, including: The client performs the following operations: The elements in the new first cryptographic table are shuffled based on the dynamic key, and the strings corresponding to the elements in the shuffled first cryptographic table are concatenated to obtain the client request signature.

5. The method for secure signature verification of SaaS services according to claim 4, characterized in that, Shuffling the elements contained in the new first cryptographic table based on the dynamic key includes: Generate the current element index based on the dynamic key, and construct the rearrangement interval corresponding to the current element index; The index of the element to be swapped is determined using the rearranged interval as a constraint; Swap the string corresponding to the element at the current element index with the string corresponding to the element at the index of the element to be swapped. The current element index is updated, and a new rearrangement interval corresponding to the current element index is constructed until a preset condition is met to stop element swapping, thereby shuffling the elements contained in the new first cipher table.

6. The method for secure signature verification of SaaS services according to claim 1, characterized in that, Generating the first cryptographic table corresponding to the dynamic key includes: The client performs the following operations: The dynamic key is encoded to obtain an encoded array corresponding to the dynamic key; Perform a hash calculation on the encoded array, and generate a random seed corresponding to the dynamic key based on the result of the hash calculation; Multiple random strings are generated using the random seed to obtain a first password table; wherein the number of random strings is the same as the number of elements in the first password table.

7. The method for secure signature verification of SaaS services according to claim 1, characterized in that, The dynamic password rule information also includes the remaining validity period; the verification of the client request signature based on the server-side request signature includes: The server performs the following operations: Determine whether the server-side request signature is consistent with the client-side request signature, and whether the remaining validity period is not 0; If any judgment result is negative, the signature is retried based on the dynamic password rule information corresponding to the previous time window, and if any judgment result is still negative during the retried signature process, the verification is deemed unsuccessful. If all the above judgment results are yes, the verification is successful.

8. A system for secure signature verification of SaaS services, characterized in that, Including client and server sides: The client is used to: send a login request to the server; The server is configured to: verify the login request, and based on the login request and the current time window, return dynamic password rule information to the client. The dynamic password rule information includes at least a dynamic key and an encoding rule table. The encoding rule table contains multiple elements, the subscript index of the element is used to describe the string it is bound to, and the value corresponding to the element is used as the embedding index of the string in the password table. The client is used to: generate a first cryptographic table corresponding to the dynamic key, hash the data of the business request according to the encoding rule table and embed it into the first cryptographic table, obtain the client request signature after the new first cryptographic table is shuffled, and send the business request and the client request signature to the server. The server is configured to: generate a second cryptographic table corresponding to the dynamic key; hash the data of the business request according to the encoding rules and embed it into the second cryptographic table; obtain a server-side request signature after the new second cryptographic table is shuffled; verify the client-side request signature based on the server-side request signature; and return the response result corresponding to the business request to the client after successful verification.

9. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images