An anonymous reporting system and method based on multi-level login credentials and a storage medium

Abstract

The application discloses an anonymous reporting system and method based on multi-level login credentials and a storage medium. The system is composed of a front-end interactive terminal, a reverse proxy middleware and a back-end server to form a three-layer privacy isolation architecture, realize full-link zero retention of user privacy data and cut off the identity tracing path. The system replaces device fingerprint identification with human-computer interaction timing analysis, completes automatic script risk detection and avoids terminal privacy data collection. The system supports a multi-level login credential system and enhances account security. The system adopts a separate deployment of a reporting business library and a reward management library, and adopts a threshold secret sharing mechanism-based delegation to receive rewards to realize decoupling of reporting identity and reward receiving behavior. The application realizes anonymous reporting under the premise of ensuring account security through the isolation architecture, combined with risk detection, a multi-level login credential system and a delegation to receive rewards, and can adapt to the anonymous reporting and reward distribution needs in the government supervision and enterprise compliance scenarios.

Description

Technical Field

[0001] This invention relates to the field of computer network information security technology, and in particular to an anonymous reporting system, method and storage medium based on multi-level login credentials. Background Technology

[0002] With the continuous improvement of government oversight and corporate compliance oversight systems, anonymous whistleblowing mechanisms have placed higher technical demands on the simultaneous implementation of whistleblower privacy protection and reward mechanisms. Currently, several invention patents related to anonymous opinions, anonymous appeals, and anonymous whistleblowing have been published in China. The following section introduces some of the technical solutions disclosed in these patents and analyzes their shortcomings:

[0003] Reference Solution 1: CN121580436A (Publication Date: February 27, 2026; Application Date: November 27, 2025), entitled "A Method, System, Device, and Medium for Processing Anonymous and Real-Name Opinion Submissions." This solution generates login status through user authentication, supporting single-factor login verification such as account password or biometrics. In anonymous mode, it generates a temporary anonymous identifier by combining anonymized user identifiers, time factors, and generalized device factors (such as generalizing the browser User-Agent to a preset neutral value). This temporary anonymous identifier is then bound to the user's encrypted identity information and stored in a controlled encrypted partition. In this technical solution, the system stores a mapping table between user identities and anonymous identifiers. Authorized administrators can query this mapping table for compliance tracing and to confirm user identities. Therefore, there is a risk of unauthorized tracing by internal personnel or database leakage leading to the exposure of identity mapping relationships. Furthermore, this solution lacks a dedicated risk detection module, making it difficult to effectively identify the risk of automated script attacks during the login process.

[0004] Reference Solution 2: CN121814367A (Publication Date: April 7, 2026; Application Date: December 10, 2025), titled "Anonymous Appeal and Reporting Method, Device, Electronic Device, and Storage Medium." This solution generates a unique anonymous identifier based on the user's real mobile phone number, the device's unique identifier, and the business system identifier, and stores it on the blockchain. The on-chain evidence can be used to reverse-match the terminal entity. In this technical solution, the anonymous identifier and the terminal hardware identifier are permanently stored on the blockchain. Its application scenarios only involve voice appeal interaction and do not cover text / image reporting or multi-level login architectures, thus its applicability is relatively limited.

[0005] Reference Solution 3: CN113162769A (Publication Date: July 23, 2021; Application Date: February 24, 2021), titled "An Anonymous and Traceable Reporting System for Illegal Operating Vehicles." This solution generates encrypted signature data associated with the whistleblower's identity based on their identity identifier IDi. The platform can then reverse-match the whistleblower's identity identifier using a pre-defined bilinear pairing verification equation. In this technical solution, there is a mathematical binding relationship between the signature and the whistleblower's identity. However, this solution lacks a login verification process; any user who knows the system address can submit a report. It lacks a mechanism to verify the legitimacy of the whistleblower's identity, limiting its application to reporting illegal operating vehicles and neglecting to address reward distribution procedures.

[0006] Reference Solution 4: CN121567396A (Publication Date: February 24, 2026; Application Date: November 21, 2025), entitled "Anonymous Access Processing Method, Apparatus, and Related Equipment." This solution generates anonymous access identities using a terminal MAC address identifier and a user key, and the server persistently stores traceable system parameters and terminal device mapping records. In this technical solution, the generation of anonymous identities depends on the terminal identifier, and the server persistently stores device mapping data. Its functionality is limited to basic anonymous webpage access and does not cover complete business processes such as reporting and reward collection.

[0007] Reference Solution 5: CN110213251A (Publication Date: September 6, 2019; Application Date: May 22, 2019), titled "Method for Issuing and Receiving Anonymous Whistleblower Rewards, Equipment, and Storage Medium." This solution uses public and private keys to encrypt whistleblower information and store it on the blockchain, issuing rewards to a dedicated address on the chain. The private key can be publicly disclosed to support third-party supervision. In this technical solution, the whistleblower information and the reward-receiving address are permanently bound on the blockchain. Once the private key is made public, a third party can match the whistleblower with the reward recipient. However, this solution only involves the single stage of reward issuance, and the whistleblower's identity is at risk of being leaked during the submission stage.

[0008] A comprehensive analysis of the above technical solutions reveals the following four main shortcomings in anonymous reporting scenarios:

[0009] First, the risks of identity tracing are not fundamentally eliminated (see solutions 1, 2, and 4). Solutions 1 and 2 rely on device fingerprints or terminal identifiers to generate anonymous IDs and persistently store the mapping relationship; although solution 4 only involves anonymous web page access, its server-side persistent storage of the mapping record between system parameters and terminal devices allows internal personnel or attackers with database access to still associate anonymous access behavior with specific terminal devices, failing to achieve true end-to-end privacy-free tracing, and still allowing reverse tracking of visitors through this mapping relationship.

[0010] Secondly, the risk detection logic relies excessively on terminal privacy data (see solutions 1 and 4). Existing solutions generally collect data such as IP addresses and device characteristics for risk control, but lack technical means to identify automated scripts using only human-computer interaction time-series data.

[0011] Third, the login security mechanism is weak, lacking multi-factor and multi-level protection (see Solution 1). Solution 1 uses single-factor authentication, while the other solutions lack login verification, failing to balance account security and ease of use.

[0012] Fourth, the reporting behavior and the reward collection behavior are coupled at the data level, failing to achieve cryptographic decoupling (see Scheme 5). Although Scheme 5 involves rewards, the on-chain binding relationship is traceable, lacking a delegated reward collection mechanism based on cryptographic decoupling.

[0013] On the one hand, existing risk detection technologies generally rely on device fingerprints or IP address profiling. In anonymous systems, this inevitably involves collecting device and network characteristics related to the user's identity, which contradicts the design goals of anonymous systems and makes them unsuitable for anonymous environments. On the other hand, in anonymous reporting scenarios, whistleblowers often hesitate to claim rewards directly for fear of revealing their real identities. Existing reward claim mechanisms lack effective identity decoupling, and once the entrusted person intervenes, they may learn the content of the report, further increasing the risk of privacy exposure for the whistleblower.

[0014] In summary, existing technical solutions have shortcomings in four dimensions: identity tracing, risk detection, login security, and reward distribution. To address these shortcomings, this invention proposes an anonymous reporting system, method, and storage medium based on multi-level login credentials. This invention constructs a three-layer privacy isolation architecture consisting of a front-end interactive terminal, a reverse proxy middleware, and a back-end server, cutting off the user identity tracing path. It does not read the terminal device identifier throughout the process, only collecting human-computer interaction time-series data, and performs risk detection based on statistical analysis methods, thereby avoiding the risk of privacy data collection. Furthermore, the system supports self-configuration of multi-level login credentials, improving the account's resistance to brute-force attacks. The reporting business database and the reward management database are physically separated and deployed independently, and a delegated reward collection mechanism based on threshold secret sharing is adopted to achieve cryptographic decoupling between the reporting identity and the reward collection behavior, enabling anonymous reporting while ensuring account security. Summary of the Invention

[0015] 1. Technical problems to be solved

[0016] To address the four shortcomings of existing anonymous whistleblowing technologies, this invention simultaneously solves the following four interrelated technical problems:

[0017] 1.1 How to achieve zero retention of user privacy data throughout the entire process?

[0018] Existing solutions rely on device fingerprints or terminal identifiers to establish an "anonymous ID-terminal hardware feature" mapping relationship and persistently store the mapping relationship. Administrators or attackers can use the retained data to trace back the whistleblower. It is necessary to remove personal privacy identifiers in the three stages of front-end collection, middleware transmission, and back-end storage to completely eliminate the tracing channel.

[0019] 1.2 How to complete risk identification by collecting only human-computer interaction time-series data?

[0020] Existing solutions generally collect sensitive data such as IP addresses and device hardware fingerprints as the basis for risk control. In anonymous scenarios, collecting such data itself introduces the risk of identity exposure. It is necessary to rely solely on user operation behavior characteristics to distinguish between manual operations and automated scripts without reading terminal identifiers.

[0021] 1.3 How to design a self-configurable multi-level login credential system?

[0022] Existing anonymous platforms only support single-factor login or have no login verification step, lacking a multi-level login credential system that combines ease of use and high security. It is necessary to design a multi-level login credential system that allows users to set N levels (N≥2) to improve the account's resistance to brute-force attacks.

[0023] 1.4 How to achieve cryptographic decoupling between the reporting identity and the award-receiving behavior?

[0024] The existing solution links whistleblower information with reward information, allowing authorized reward recipients to view whistleblower content. This requires the independent physical deployment of the whistleblower database and the reward management database, and the use of a threshold-based confidentiality sharing mechanism to enable anonymous authorized reward collection, thus decoupling the whistleblower's identity from the reward collection behavior.

[0025] 2 Technical Solution

[0026] To address the aforementioned technical problems, this invention provides a complete technical solution from both system and method perspectives, as detailed below:

[0027] 2.1 In a first aspect, the present invention provides an anonymous reporting system based on multi-level login credentials.

[0028] 2.1.1 The system consists of a three-layer privacy isolation architecture, consisting of a front-end interactive terminal, a reverse proxy middleware, and a back-end server, which is suitable for government supervision and enterprise compliance reporting scenarios.

[0029] The front-end interactive terminal disables the device fingerprint collection interface and clears local persistent data by loading a script on the page; the reverse proxy middleware intercepts and clears the client network identity data in the request header and disables access log recording; the back-end server includes a physically partitioned, independently deployed reporting business database and a reward management database with no direct cross-database access channel, and runs both the reporting business service process and the reward management service process simultaneously. These two processes run in independent operating system process spaces, achieving process-level isolation. The reporting business service process only accesses the reporting business database and is responsible for the closed-loop management of the entire lifecycle of reporting leads; the reward management service process accesses the reward management database, is responsible for reward distribution, and responds to reward data query and operation requests submitted through the user login portal or the reward management login portal. The two processes communicate only through a one-way message queue, transmitting reward distribution trigger flags without business plaintext.

[0030] For details on the specific configuration of the three-layer privacy isolation architecture, please refer to the "Specific Implementation Methods - 2 General Privacy Rules" section of this manual. This architecture intercepts and cleans privacy data such as IP address, User-Agent, device fingerprint, and browser hardware characteristics throughout the entire chain, and does not persistently retain the original identifiable values, thereby achieving zero retention of user privacy data throughout the entire chain and fundamentally cutting off the path for tracing the identity of whistleblowers.

[0031] 2.1.2 The backend server includes the following functional modules:

[0032] User environment detection module; account registration module (including SMS registration module, email registration module, website registration module, dynamic verification code service module, key file generation module); system login module; clue handling module (including clue acceptance module, preliminary review module, investigation module, final handling module, feedback and communication module, material supplementation module, and case completion archiving module); reward management module (including on-site collection module, mailed check module, bank transfer module, online shopping module, and entrustment module); SMS service module; email service module; risk management module (including text password modification module and text password protection module).

[0033] 2.1.3 For details on the communication and data interaction relationships between modules, please refer to the "Detailed Implementation - 4 Communication and Data Interaction Relationships between Modules" section of this manual. The specific functions of each module are as follows:

[0034] (1) The user environment detection module is the pre-login risk detection unit of the system login module, and does not collect IP address, User-Agent, Cookie, or device fingerprint throughout the process.

[0035] The user environment detection module only collects human-computer interaction timing data, including the interval sequence of adjacent keys in the input box, the duration of focus pause in the input box, and backspace key usage marker data. Risk is assessed based on the collected data, and a risk is determined to exist if any of the following conditions are met:

[0036] ① The standard deviation of the key spacing is detected to be less than the preset standard deviation threshold of the key spacing;

[0037] ② The system detected no input pauses exceeding the preset input pause duration threshold and no backspace, deletion, or modification operations.

[0038] The preset key interval standard deviation threshold and the preset input pause duration threshold are calibrated by statistical analysis methods (see “Detailed Implementation - 3 Threshold Calibration and Performance Verification” section of this specification) to distinguish between automated input behavior and manual input behavior.

[0039] (2) The account registration module is configured to generate anonymous accounts and multi-level login credentials.

[0040] The multi-level login credentials are set by the user with a total number of levels N, where N is an integer greater than or equal to 2 (preferably, N can be 2 to 5, and the configuration takes into account both account security and login operation convenience. The higher the level, the stronger the resistance to brute-force attacks). This number N is uniformly applicable to the three verification methods configured by the user: text password, dynamic verification code, and key file.

[0041] Each level of login credentials consists of a mandatory part and an optional part: the mandatory part is a text password set independently for each level. This text password is a static string credential that is valid indefinitely and is not stored in plaintext. It remains valid as long as the user does not actively modify it, the account is not canceled, and the risk management module does not trigger a reset operation; the optional part is the dynamic verification code and / or the key file, which serve as a supplementary verification method for this level of login credentials. Users can choose whether to enable it.

[0042] If a user enables supplementary verification at a certain level, the login credentials for that level consist of the text password, the dynamic verification code, and / or the key file for that level. If the user does not select supplementary verification at that level, the login credentials for that level only contain the text password.

[0043] (3) The website registration module adopts a multi-level login credential system, configured to allow users to set custom usernames as anonymous accounts, and supports users to independently set the number N of multi-level login credentials. The supplementary verification method has an expiration period, which is configured by the user when generating the method. After the expiration period, the supplementary verification method will automatically become invalid and needs to be reconfigured and generated. The website registration module can complete the registration without the user providing personal privacy information.

[0044] When logging in, users can choose any of the configured verification methods at that level to complete the login credential verification for that level. After passing the login credential verification at all levels, users can log in to the system.

[0045] The dynamic verification code service module is configured to generate a TOTP key seed, which is Base32 encoded to generate a de-identified QR code conforming to the TOTP URI scheme (RFC 6238) specification. This supports third-party authentication applications using the standard TOTP protocol to scan the QR code, completing TOTP key seed binding and offline verification. The validity period of the TOTP key seed and the dynamic verification code is stored together on the server. The TOTP key seed automatically expires after its validity period, requiring the user to reconfigure and generate a new one. After configuration, the system automatically cancels the old key seed and overwrites it with the new one. There is no coexistence window between the old and new key seeds, and no user privacy information is recorded throughout the process. The dynamic verification code service module is configured to use the TOTP algorithm based on the IETF RFC 6238 specification, employing a 30-second time step and HMAC-SHA1 cryptographic hash operation to generate a 6-digit dynamic verification code.

[0046] The key file generation module employs one or more of the PBKDF2, BCrypt, or Argon2id key derivation algorithms to perform key derivation operations on the user-defined text password and random salt value, generating a derived key. The derived key is then packaged into a binary key file for the user to download. Simultaneously, the derived key is subjected to salted hashing, and the resulting verification value and file validity period are stored on the server for login verification. The key file automatically expires upon expiration and needs to be reconfigured and generated.

[0047] (4) The SMS registration module and the email registration module are implemented based on the SMS service module and the email service module, respectively. After the user sends the registration command, the system automatically generates an anonymous account and multi-level login credentials and replies via the original method. As defined above, the login credentials generated by SMS and email registration are also N-level. Due to the restriction of the registration channel, the user cannot configure a supplementary verification method. Therefore, in the N-level login credentials generated by the system, each level of login credentials only contains the text password of that level. This logic is consistent with the fact that each level of login credentials in website registration includes "mandatory text password + optional supplementary verification method". Login is only allowed after all levels of text passwords have been verified.

[0048] In the three registration methods described above, the system temporarily obtains the plaintext password during the registration process (following the "Specific Implementation Methods - 2.1 General Memory Security Rules" in this manual) to generate the TOTP key seed or key file. For persistent storage, the system salts the plaintext password with a cryptographically secure random salt value, then performs one-way hashing using the SHA-256 or SM3 cryptographic hash algorithm, storing the hash value and salt value together in the database. This storage method ensures that even if the database is compromised, attackers cannot recover the plaintext password. After successful registration, users can log in to the website to complete the entire process. Users who registered via SMS or email can also perform lightweight interactions via SMS or email commands.

[0049] (5) The system login module sets up two login entrances: user login and reward management login. Before logging in, the user environment detection module is forcibly called to complete risk detection. The specific login verification method is as follows:

[0050] ① Text password verification. Salted hash comparison is used, that is, the system performs the same salted hash operation on the plaintext text password entered by the user as configured, and compares the calculation result with the stored hash value.

[0051] ② Dynamic CAPTCHA verification. The system first reads the validity period of the dynamic CAPTCHA at this level from the server. If the current time has exceeded the validity period, the verification method is deemed invalid, and verification failure is returned directly. If it is within the validity period, the expected dynamic CAPTCHA is generated using the TOTP key seed stored on the server and compared with the dynamic CAPTCHA entered by the user.

[0052] ③ Key file verification. The system first reads the validity period of the key file at this level from the server. If the current time has exceeded the validity period, the verification method is deemed invalid, and verification failure is returned directly. If it is within the validity period, the system parses the key file uploaded by the user, extracts the derived key, performs the same salted hash operation on the extracted derived key, and compares it with the verification value stored on the server.

[0053] Once all login credentials at each level have been verified, the user is allowed to log in, and a temporary session identifier is generated that is stored only in memory.

[0054] (6) The clue handling module realizes closed-loop management of the entire life cycle of reported clues, including acceptance, preliminary review, examination, handling, feedback, and filing. The material supplementation module is a universal auxiliary module for the entire process. If there is missing material or doubt about information at any stage of the clue flow, this module can be triggered. After the material is supplemented, the clue returns to the original stage for further processing. The clue status is automatically updated after each module operation is completed. Staff members urge the informant to supplement the material in a timely manner according to the actual processing process. If the informant fails to supplement the material within the time limit, the staff members can mark the clue as "terminated after the deadline" and file it according to the business process. After the clue is filed, if a reward needs to be issued, the reward issuance trigger mark is pushed unidirectionally to the reward management service process through the system background process. The system generates an independent reward item on the reward management side.

[0055] (7) The reward management module adopts an independent deployment architecture with the reporting business database and the reward management database physically separated. This module includes at least a delegation module to adopt a delegated reward scheme based on a threshold secret sharing mechanism. In specific business implementation, the reward management module can also optionally configure one or more of the following methods as the business implementation channels for reward distribution: on-site collection module, mailed check module, bank transfer module, and online shopping module. The above distribution methods do not constitute a limitation on the necessary technical features of this module.

[0056] (8) The module for delegating to others is configured to perform the following functions:

[0057] ① Role designation and share distribution

[0058] The system generates a unique master key for each reward item. Using this master key as a constant, it constructs a P-1 degree polynomial, divides it into Q subkey shares, and distributes them to the executor and collaborators. During distribution, a commitment value is attached to each subkey share for subsequent single-share validity verification. A mapping table between unique share identifiers and reward items is maintained in the reward management database, recording the role type (executor or collaborator) corresponding to each share. The whistleblower must designate at least one executor and may selectively designate several collaborators, among whom only the executor has reward-claiming authority. When the master key is restored, the number of valid shares must reach P shares within the session's validity period, and at least one of these must be a valid share belonging to an executor. The minimum number of valid shares P and the total number of shares Q satisfy the constraints Q≥P, Q≥2, and P≥2. The whistleblower distributes the subkey shares to the executors and collaborators through channels outside the system. During this process, the whistleblower may distribute all shares to a single executor or distribute them proportionally to multiple collaborators as needed, but each executor must hold at least one subkey share.

[0059] ② Share Submission and Identity Verification

[0060] The executor and collaborators submit their subkey shares through a separate reward management login portal, submitting only one share at a time without needing to enter a username or login credentials at any level. The system first verifies the legitimacy of each subkey share using the commitment value corresponding to that share. If the verification passes, the system records the verification time and sets a session validity period (e.g., 24 hours, the specific duration can be configured according to actual implementation needs). After the session validity period expires, the share needs to be resubmitted; shares that fail verification are immediately rejected, and the system prompts: "Share invalid, please re-enter."

[0061] After successful verification, the system queries the mapping table based on the unique identifier embedded in the share to identify the reward item and role type (executor or collaborator), without collecting or retaining the privacy information of the executor and collaborator. When the number of valid shares for a certain reward item reaches the minimum number of valid shares P within the session validity period, and at least one of them contains a valid share of the executor, the master key is restored and the executor is authorized to enter the reward management interface to perform the reward claim operation.

[0062] The reported leads and reward items are linked via a one-way hash mapping, thus blocking the reverse tracing path from the reward management database to the reporting business database. The server generates an audit log for each valid share, bound to that share identifier. Collaborators can only view the audit logs bound to their own share identifier; they cannot view audit logs corresponding to other share identifiers.

[0063] After logging into the system through the user login portal, the whistleblower can view the audit logs of all executors and collaborators, and can revoke the authorization of any executor or collaborator at any time. After the authorization is revoked, the corresponding subkey share will immediately become invalid.

[0064] Once the reward is issued, the system marks the reward as "completed," and the obligation to fulfill the reward obligation terminates. Audit logs can serve as objective evidence for dispute resolution. Whistleblowers, executors, and collaborators bear the risk of improper safekeeping of documents. If a whistleblower, executor, or collaborator submits an objection after identity verification, the system will retrieve the audit logs associated with the reward as the basis for objection resolution.

[0065] (9) Mathematical definition of the algorithm based on threshold secret sharing mechanism

[0066] This invention employs a delegated prize-collection scheme based on the Shamir threshold secret-sharing mechanism, applicable to finite field GF(p) operations (where p is a large prime number, such as a 3072-bit or 4096-bit secure prime, satisfying p>Q and p>S, where Q is the total number of subkey shares and S is the integer value of the master key). A P-1 degree polynomial is constructed using the prize-collection master key as a constant term, and this polynomial is divided into Q subkey shares. During distribution, a commitment value is attached to each share for subsequent share validity verification. When the master key is restored, if the number of valid shares collected within the session's validity period reaches P, and at least one of these shares is a valid share belonging to the executor, the master key is restored, with parameters satisfying the constraints Q≥P, Q≥2, and P≥2. For details on the specific operation of the executor, collaborator, and commitment value mechanism, please refer to the corresponding description in the "Detailed Implementation - 5 Detailed Implementation with Reference to the Drawings" section of this specification.

[0067] (10) The SMS service module and the email service module serve as the underlying communication support of the system, providing SMS and email registered users with instruction interaction and message push services such as registration, query, and feedback.

[0068] (11) The risk management module has functions for setting clue aliases, querying audit logs, resetting text passwords at all levels, and modifying login credentials at all levels. Specifically, it executes the following control rules:

[0069] ① Alias ​​setting for clues: Users can set aliases for reported clues to achieve anonymous display of clue information.

[0070] ② Audit log query: For details of the audit log, please refer to the “Detailed Implementation - 1 Terminology Definition” section of this manual.

[0071] ③ Text Password Reset: Users set independent password protection questions and answers for each level of text password, serving as reset credentials in case of password forgetting. When a user forgets a level of text password, the reset can only be completed by verifying the password protection questions and answers for that level. The reset function for a single level will be locked after a threshold number of consecutive incorrect answers are entered. The dynamic verification code and / or key file for this level serve as supplementary verification methods and can only be generated by reconfiguring the text password for that level; there is no separate reset method for them.

[0072] ④ Login credentials modification: If a user discovers an anomaly, they can modify the text password at each level. After modification, the dynamic verification code and / or key file at that level will become invalid as a supplementary verification method, and a new text password must be reconfigured and generated.

[0073] The system incorporates a role-based access control model. At the database layer, neither the account information table nor the login credential information table contains a field for administrator reset permissions, and the administrator role only has read permissions for these tables, lacking write, delete, or modify permissions. At the application layer, the system disables API routes related to administrator reset. Users must properly safeguard their login credentials and password protection answers at all levels. The system does not provide account recovery channels other than user self-reset; this is a necessary security constraint implemented to achieve end-to-end anonymity protection.

[0074] 2.2 In a second aspect, the present invention provides an anonymous reporting method based on multi-level login credentials.

[0075] The method is implemented based on the aforementioned system. It relies on a three-layer privacy isolation architecture consisting of a front-end interactive terminal, a reverse proxy middleware, and a back-end server. Each layer executes independently, employing symmetric reversible encryption algorithms (such as the national cryptographic standard SM4-CBC or AES-256-GCM) throughout the process to encrypt sensitive fields such as phone numbers and email addresses before storing them in the database. The encryption keys are managed by a hardware security module or key management service independent of the business database and are only used for decryption when needed by the system. It does not persistently retain privacy data such as IP addresses, User-Agents, and device fingerprints, achieving zero retention of user privacy data throughout the entire process and fundamentally cutting off the path for tracing the identity of whistleblowers.

[0076] 2.2.1 The method described follows these rules:

[0077] (1) Risk detection rules: Risks are identified solely through human-computer interaction time-series data, without using device or network privacy data.

[0078] (2) Login credentials rules: The text password is a long-term valid login credential. Dynamic verification codes and key files both support independent validity periods and will automatically expire after expiration.

[0079] (3) Account security rules: Text password reset relies solely on user-defined password protection question and answer combination, and the backend has no manual account reset authority.

[0080] (4) Data isolation rules: The reporting business database and the reward management database are physically deployed independently, and the executor and collaborators cannot view the original reporting content.

[0081] 2.2.2 The method comprises the following steps:

[0082] Step 1: Global Three-Layer Privacy Isolation Processing: When the front-end interactive terminal loads the page, it disables the device fingerprint collection interface and cleans up local persistent data via a script. When the user enters login credentials, it collects human-computer interaction time-series data and uploads it to the back-end server. The reverse proxy middleware is configured to intercept identifiable feature fields such as client IP address and User-Agent in the request header and disable access logs. When receiving a request from the front-end interactive terminal, it removes the client IP address and User-Agent fields from the request header according to the aforementioned configuration and forwards the cleaned request to the back-end server. The back-end server uses a symmetric reversible encryption algorithm to encrypt the contact information before storing it in the database. The encryption key is managed by a hardware security module or key management service independent of the business database.

[0083] Step 2, Registration Processing: The account registration module of the backend server receives the registration request and generates an anonymous account and multi-level login credentials; the website registration method generates N levels of login credentials, where N≥2, and each level of login credentials includes a required text password and an optional dynamic verification code and / or a key file as a supplementary verification method; the multi-level login credentials generated by SMS registration and email registration methods consist only of a text password.

[0084] Step 3, Login Verification: The system login module of the backend server receives the login request, first calls the user environment detection module, and performs risk assessment based on the human-computer interaction time sequence data collected in Step 1. After the assessment is passed, multi-level login credentials are verified. After all verifications are passed, a temporary session identifier that exists only in memory is generated. This identifier is automatically destroyed after timeout and is not written to the log or persistently stored. The verification of multi-level login credentials supports two modes: step-by-step verification and one-time centralized verification.

[0085] Step 4, Clue Processing: The reporting service process on the backend server receives the reported clues, performs closed-loop management throughout the entire lifecycle, and after the clues are completed and archived, pushes a reward distribution trigger flag to the reward management service process through a one-way message queue.

[0086] Step 5, Award Collection: After receiving the trigger flag through a one-way message queue, the reward management service process splits the master key into multiple sub-key shares based on the threshold secret sharing mechanism and distributes them to the executor and collaborators. The executor and collaborators submit the sub-key shares, and after the system verifies them, the master key is restored and the reward is issued.

[0087] The method can be adapted to any of the following implementation modes, depending on the business scenario: mailing or placing materials, website reporting, or a combination of online and offline methods.

[0088] 3. Beneficial effects

[0089] This invention addresses the shortcomings of existing technologies in four aspects: identity tracing, risk detection, login security, and reward distribution, and achieves the following beneficial effects:

[0090] 3.1 End-to-End Privacy Protection

[0091] This invention achieves end-to-end protection of user privacy information throughout the data collection, transmission, and storage stages through the synergistic effect of a three-layer privacy isolation architecture. The front-end interactive terminal layer disables all device fingerprint collection interfaces and clears local cache, blocking privacy collection at the data source. The reverse proxy middleware layer removes client characteristic fields such as IP address and User-Agent and disables access logs, blocking privacy leakage at the transmission link. The back-end server layer encrypts sensitive contact fields before storing them in the database. The reporting business database and the reward management database are physically separate and deployed independently with no cross-database access channels. The two processes communicate only through a one-way message queue to transmit reward distribution trigger flags, blocking reverse tracing. This three-layer synergy cuts off the tracing path for whistleblowers at the front-end collection, middleware transmission, and back-end storage stages.

[0092] 3.2 Risk Detection Based on Human-Computer Interaction Time Series Data

[0093] This invention achieves risk detection solely based on human-computer interaction timing data, without collecting private information such as IP addresses or device fingerprints throughout the process. Human input is influenced by muscle physiological rhythms, resulting in random fluctuations in key press intervals, accompanied by pauses and backspace corrections; automated scripts, on the other hand, are precisely scheduled by timers, resulting in uniformly distributed key press intervals. Based on this fundamental difference, the system monitors purely interactive behavior data such as the sequence of adjacent key press intervals in the input box, the duration of focus pauses in the input box, and backspace key usage markers. Through statistical analysis to calibrate the standard deviation thresholds for key press intervals and the input pause duration thresholds, the system can distinguish between human operation and automated scripts, thus avoiding the privacy leakage risks associated with collecting device fingerprints at the source.

[0094] 3.3 Multi-level login credential system

[0095] This invention implements a user-configurable multi-level login credential system. Website registered users can set two or more levels of login credentials. Each level includes a mandatory text password and optional dynamic verification codes and / or key files as supplementary verification methods. If multiple verification methods are configured for the same level of login credentials, users can complete the verification of that level's login credentials through any one of them, balancing the user experience of password memorization with the security of multi-factor authentication. The combination of multi-level login credentials greatly increases the difficulty and cost of brute-force attacks, and the single-level error locking mechanism can effectively defend against online password guessing attacks, thereby significantly improving account security. Users registered via SMS or email can verify multi-level text passwords through the website and perform full-process operations after logging in. They can also perform lightweight interactions via SMS or email commands, adapting to different usage scenarios.

[0096] 3.4 Delegated Reward Collection Based on Physical Database Sharing and Threshold Secret Sharing

[0097] This invention decouples the whistleblower's identity from the reward claim process. When someone is entrusted to claim the reward on their behalf, the system splits the master key into Q sub-key shares and distributes them to each executor and collaborator. Each executor and collaborator submits their sub-key share, and after verification, they enter the reward management interface to claim the reward. The whistleblower can log in to the system at any time to view the audit logs of all executors and collaborators and revoke the authorization; upon revocation, the corresponding share immediately becomes invalid. The whistleblower's business database and the reward management database are physically deployed independently, with no direct cross-database data access channel between the two databases. This eliminates any human or programmatic association between the two types of data at the storage layer and severs the association path between the whistleblower's identity and reward claim information. Even if the reward management database data is leaked, attackers cannot obtain information related to the whistleblower's identity or the content of the whistleblower's report, thus effectively ensuring the anonymity of the whistleblower's report. Attached Figure Description

[0098] The above and other objects, features and advantages of the present invention will become more apparent from the accompanying drawings, which are functional logic diagrams of embodiments of the present invention.

[0099] Figure 1 This is a schematic diagram of the overall module structure and data flow interaction of the anonymous reporting system of the present invention.

[0100] Figure 2 This is a schematic diagram of the website registration process of the present invention.

[0101] Figure 3 This is a schematic diagram of the website registration information filling interface for this invention.

[0102] Figure 4 This is a schematic diagram of the interface for configuring supplementary verification methods for the Nth level login credentials in the website registration method of this invention.

[0103] Figure 5 This is a schematic diagram of the interface for configuring dynamic verification codes for the Nth level login credentials in the website registration method of this invention.

[0104] Figure 6 This is a schematic diagram of the login process of the step-by-step login credential verification mode of the present invention.

[0105] Figure 7 This is a schematic diagram of the Nth level login credential verification interface in the hierarchical login credential verification mode of the present invention.

[0106] Figure 8 This is a schematic diagram of the login process for the one-time centralized login credential verification mode of the present invention.

[0107] Figure 9This is a schematic diagram of the interface for the one-time centralized login credential verification mode of the present invention.

[0108] Figure 10 This is a schematic diagram of the reward management and award collection process of this invention.

[0109] Figure 11 This is a schematic diagram of the reward management login interface of the present invention.

[0110] Figure 12 This is a schematic diagram of a complete business process embodiment of the present invention.

[0111] Figure 13 This is a schematic diagram of the reporting mode of mailing or placing materials, which is an embodiment of the present invention.

[0112] Figure 14 This is a schematic diagram of the website reporting mode process in Embodiment 2 of the present invention.

[0113] Figure 15 This is a schematic diagram of the reporting mode combining online and offline methods, which is an embodiment of the present invention.

[0114] The interface layout and element arrangement shown in the attached figures are merely illustrative examples and do not constitute any limitation on the scope of protection of this invention.

[0115] Figure 1 The meanings of the reference numerals in the attached figures are as follows:

[0116] User Environment Detection Module 1; Account Registration Module 2; System Login Module 3; Clue Handling Module 4; Reward Management Module 5; SMS Service Module 6; Email Service Module 7; Risk Management Module 8. Detailed Implementation

[0117] The embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. All other embodiments obtained by those skilled in the art based on the technical solutions of the present invention fall within the protection scope of the present invention.

[0118] 1. Terminology Definition

[0119] To facilitate understanding of this invention, the following definitions are provided for key terms used in this specification:

[0120] (1) Human-computer interaction time sequence data: refers to the interactive behavior data generated by users during the registration or login process, including the interval sequence of adjacent keys in the input box, the pause duration of the input box focus, and the backspace key usage marker data.

[0121] (2) Multi-level login credentials: refers to the set of login credentials used for user authentication. The number of levels N is set by the user. Each level of login credentials consists of the required text password and the optional supplementary verification method. When verifying a login credential at a certain level, it can be completed through the text password of that level or any of the configured supplementary verification methods.

[0122] (3) Text password: refers to the static string credential set by the user. It is a mandatory verification method for each level of login credentials. Each level of text password is set independently and is not stored in plain text. It remains valid as long as the user does not actively modify it, the account is not canceled, and the risk management module reset operation is not triggered.

[0123] (4) Supplementary verification method: Associated with text passwords at all levels, consisting of dynamic verification codes and / or key files, with independently configurable validity periods. It expires upon expiration and needs to be reconfigured and generated. Users can choose whether to configure a supplementary verification method for the login credentials at this level after setting the text password.

[0124] (5) Dynamic verification code: refers to a 6-digit one-time password generated based on the TOTP (Time-Based One-Time Password) algorithm of the IETF RFC 6238 standard. Together with the key file, it constitutes a supplementary verification method for login credentials. The validity period of the dynamic verification code is configured independently by the user when it is generated.

[0125] (6) TOTP key seed: refers to the key seed generated by a password hash operation based on the user-defined text password, used to generate dynamic verification codes. The TOTP key seed is functionally equivalent to the shared secret in the RFC 6238 standard, but the key seed of this invention is derived from the user's text password rather than being randomly generated.

[0126] (7) Custom identifier: This refers to the identifier string that users set themselves when configuring the dynamic verification code supplementary verification method to distinguish different accounts. This custom identifier is a purely functional identifier and does not contain personal privacy information. It is designed to help users distinguish multiple accounts in the authentication application. During the setting and use of the custom identifier, the system does not collect or record the user's personal privacy information at all.

[0127] (8) Derived key: refers to the binary key data generated by executing a key derivation algorithm (such as PBKDF2, BCrypt, or Argon2id) based on the user-defined text password and random salt value. It is used to construct the key file. After the derived key is generated, it is immediately packaged into a key file for users to download. The server does not store the plaintext of the derived key, but only its verification value.

[0128] (9) Key file: refers to a binary file containing derived keys, which is generated by the server and then downloaded and saved by the user. Together with the dynamic verification code, it constitutes a supplementary verification method for login credentials. The validity period of the key file is configured independently by the user when it is generated.

[0129] (10) Verification value: refers to the hash value obtained after the derived key is salted and hashed, which is stored on the server side and used as the benchmark value for verifying the authenticity of the derived key during login verification.

[0130] (11) Reward Issuance Trigger Mark: This refers to the reward item activation signal sent by the reporting business service process to the reward management service process through a one-way message queue after the clue is closed and archived. It includes the reward item number and reward content, but does not include the reporting content or the whistleblower's privacy information. Among them, the reward item number is generated based on the reporting clue number through one-way hashing. The reward management service process cannot reverse the reporting clue content or the whistleblower's identity through this number.

[0131] (12) Entrusted executor (hereinafter referred to as "executor"): refers to the entrusted person designated by the whistleblower who has the authority to receive the reward. The master key can only be restored if the valid share includes at least one share held by the executor.

[0132] (13) Entrusted collaborator (hereinafter referred to as "collaborator"): refers to the entrusted person designated by the whistleblower to assist in completing the threshold secret sharing process. The entrusted person only provides the subkey share, does not have the right to receive the reward, and has no right to view the reward amount and other collaborator information.

[0133] (14) Threshold constraint: refers to the parameter constraint conditions in the threshold secret sharing scheme, which satisfy Q≥P, Q≥2, P≥2, where Q is the total number of subkey shares and P is the minimum number of valid shares required to recover the master key.

[0134] (15) Subkey share: refers to each key fragment generated after the master key for the prize is split by the threshold secret sharing scheme. It is held by the executor or collaborator. The master key can only be recovered when the number of valid shares collected during the session validity period reaches P shares, and at least one of them is a valid share with the role type of executor.

[0135] (16) Commitment value: refers to the verification value attached to each subkey share when the share is distributed. It is used to verify the legality of the single subkey share when the share is submitted. Only those that pass the verification are counted as valid shares, so as to avoid the process being repeated after P shares are collected and fake shares are found.

[0136] (17) Temporary session identifier: refers to a 256-bit identifier string generated by a cryptographically secure random number generator after the user login verification is successful. The server only stores its hash derivation value, which is stored only in memory. It expires when there is no operation within the validity period or when the user actively logs out.

[0137] (18) Audit Log: refers to the collection of user operation and reward management operation data automatically recorded by the system, which is divided into the following four categories according to the business stage:

[0138] ① Login and verification phase. Record the time of each login, the verification method used for each level of login credentials (text password, dynamic verification code, or key file), and the number of incorrect entries in a single login session.

[0139] ② Routine Operation Phase. Record key user operations within the system, such as the type, content, and time of operations like setting clue aliases, resetting text passwords, and modifying login credentials.

[0140] ③ Delegation and Share Submission Stage. Record the time when the executor or collaborator submits the subkey share, the session validity period of the share (calculated from the date of successful verification), and the reward items and role type corresponding to the share.

[0141] ④ Reward Collection Stage. Record the reward distribution status, collection time, and collection method (in-person collection, mailed check, bank transfer, online purchase, etc.).

[0142] 2 General Privacy Rules

[0143] All three reporting business modes of this invention uniformly implement a three-layer privacy isolation global pre-constraint. The three-layer privacy isolation global pre-constraint is selectively activated according to the specific execution stage of each business mode: the front-end and reverse proxy middleware constraints take effect in scenarios involving page loading and HTTP requests, while the back-end constraints remain in effect in all stages involving data storage. The specific configuration is as follows:

[0144] 2.1 General Memory Safety Rules

[0145] (1) In this invention, all processing of sensitive data such as plaintext text passwords and plaintext derived keys follows the following principles: it is used only momentarily in memory and is not written to persistent storage (including but not limited to cache, database, log file, disk file); after use, the plaintext data in memory is overwritten immediately.

[0146] (2) This rule applies to all processing of sensitive data in this specification, unless otherwise specified.

[0147] 2.2 Front-end cleanup configuration

[0148] The page loading script of the aforementioned front-end interactive terminal is executed automatically. This script has built-in feature collection and interception logic, completely disables the device fingerprint collection interface, deletes third-party tracking scripts, automatically clears cookies, and disables local data storage interfaces such as LocalStorage, SessionStorage, and IndexedDB.

[0149] (1) During the page DOM loading stage, the script automatically identifies and removes the Canvas, WebGL graphics rendering tags and script code that calls the relevant rendering interfaces; at the same time, by rewriting the pixel reading methods (such as getImageData, readPixels) and rendering parameter acquisition methods (such as getParameter) of CanvasRenderingContext2D and WebGLRenderingContext, the API calls return null values ​​or default values, thus blocking the hardware fingerprint extraction channel from the front end.

[0150] (2) During the DOM parsing phase, the script import tags of third-party event tracking, statistics, and monitoring SDKs are automatically identified and deleted to block the initialization logic of third-party SDKs and the reporting logic of user device feature events.

[0151] (3) The browser cookie operation interface is intercepted by the front-end script. The addition, deletion, modification and reading calls of cookies are intercepted by the attribute descriptor rewriting method. For write operations such as addition and modification, silent discard is performed. For deletion operations, existing cookies are allowed to be cleared. For reading operations, an empty string is returned. At the same time, the subsequent script is prevented from restoring the native interface at the interface level, thereby completely blocking the local storage of cookies.

[0152] (4) Inject storage interception logic. By rewriting the native API interfaces of LocalStorage, SessionStorage, and IndexedDB, global interception is performed on operations such as getItem, setItem, removeItem, and clear. When called, the null value is returned directly or the write request is silently discarded. When the page is loaded, the existing local persistent cache entries are traversed and cleared.

[0153] 2.3 Reverse Proxy Middleware Layer Configuration

[0154] Complete the following global interception configuration in the reverse proxy middleware:

[0155] (1) Modify the global configuration file of the reverse proxy service (such as Nginx, Apache) to disable the global normal access log, site request log, and proxy forwarding log, and retain only the operating system level fault error log for operation and maintenance troubleshooting; and actively remove all client-identifiable characteristic variables such as client IP address (remote_addr) and client User-Agent string (http_user_agent) from the error log format template to ensure that the error log does not contain client privacy information, thereby blocking the persistent storage of IP address and User-Agent logs.

[0156] (2) Add a request header standardization and cleaning rule to the reverse proxy service configuration: First, automatically delete the X-Forwarded-For, remote_addr, and HTTP_USER_AGENT fields in the request header; second, generalize fields such as Accept-Language, Accept-Encoding, and Cache-Control that can identify user preferences (for example, uniformly replace Accept-Language with "en-US,en;q=0.9"); finally, normalize and rearrange the order of request header fields to eliminate the identifiable features formed by the difference in the order of request headers of different clients.

[0157] (3) The cleaned HTTP request message retains only the path, request body and the minimum necessary header fields after cleaning, and forwards them to the backend server. The backend server can neither obtain the client's IP address, browser hardware characteristics or other user privacy data, nor can it distinguish different clients by request header arrangement pattern or preference value combination.

[0158] (4) Since users need to submit an anonymous account when logging in, the system performs single-level login credential error count and lock control based on the account, and does not rely on the client IP address or other network layer identifiers. Therefore, the reverse proxy's removal of explicit identifiers such as the client IP address will not affect the normal execution of the login risk control function.

[0159] 2.4 Comprehensive Management of Backend Servers

[0160] (1) Delete or disable all business code logic that reads client IP address and User-Agent at the code level, add code static verification rules, and strictly prohibit the addition of similar privacy data collection code.

[0161] (2) Deploy server-side request interception middleware in the backend service application layer, rewrite the network request utility class, and block the backend program's ability to read user privacy data such as IP address, device fingerprint, and browser hardware characteristics.

[0162] (3) The database instance does not create data table fields related to client IP address, device fingerprint, and browser hardware characteristics. Contact sensitive fields such as mobile phone number and email address are encrypted using a symmetric reversible encryption algorithm (such as national cryptographic SM4-CBC or AES-256-GCM) before being stored in the database. The encryption key is managed by a hardware security module or key management service independent of the business database and is only used for decryption when the system needs it. After the session ends, the plaintext in memory is immediately overwritten and destroyed. The reporting business database and the reward management database are physically deployed independently and there is no direct cross-database access channel. The reporting business service process and the reward management service process run in independent operating system process spaces to achieve process-level isolation. The reporting business service process only accesses the reporting business database and is responsible for the closed-loop management of the entire life cycle of reporting clues. The reward management service process accesses the reward management database, is responsible for reward distribution business, and responds to reward data query and operation requests submitted through the user login portal or reward management login portal. The reward management service process does not establish a direct data access channel with the reporting business database. The two processes only transmit reward distribution trigger flags through a one-way message queue.

[0163] 3. Threshold Calibration and Performance Verification

[0164] Regarding the aforementioned "preset threshold calibrated by statistical analysis methods," this invention calibrates it based on human-computer interaction time-series data:

[0165] First, based on the technical principle that the key press interval of real users is randomly distributed due to the influence of muscle physiological rhythm, while the key press interval of automated scripts is uniformly distributed due to timer scheduling, the login operation time sequence data of real users and automated scripts are collected as calibration samples. The standard deviation of key press interval for each sample is calculated, and the standard deviation distribution of the two types of samples is statistically analyzed separately.

[0166] Secondly, based on ROC curve analysis, and using the maximization of the Youden Index (sensitivity + specificity - 1) as the criterion, the optimal threshold combination is determined through grid search within the calibrated parameter range. For example, in an exemplary embodiment, the standard deviation threshold for key interval in a PC keyboard input scenario can be calibrated to 35 milliseconds, and the input pause duration threshold can be calibrated to 2.2 seconds; while in a mobile touchscreen input scenario, given the difference in rhythm between touch sampling and the virtual keyboard, the standard deviation threshold for key interval can be calibrated to the range of 50 to 80 milliseconds, and the input pause duration threshold can be calibrated to 1.5 to 2.0 seconds. It should be noted that the above thresholds are exemplary statistical results based on a specific sample set, and can be adjusted according to the interaction characteristic data of the target user group during actual deployment.

[0167] Finally, the threshold was validated using an independent test set comprising 200 real user operation samples from the PC and 200 automated script samples from the PC. The real user samples covered ordinary users aged 18 to 60 with varying typing proficiency. The script samples covered uniform input sequences generated by common keystroke simulation tools such as Selenium and PyAutoGUI. In this independent validation test, using the aforementioned initial threshold, the false positive rate (FPR) was 0.5% and the false negative rate (FNR) was 1.0%. In the control experiment, the traditional scheme based on Canvas fingerprinting and IP address binding had an FPR of 1.2% and an FNR of 2.8%, and the two-sided McNemar test showed a statistically significant difference (p<0.01). The above test results validated the effectiveness of this calibration method. After successful validation, the threshold parameters were locked for formal system operation.

[0168] 4. Communication and data interaction relationships between modules

[0169] 4.1 The backend server includes the following functional modules

[0170] User Environment Detection Module 1.

[0171] Account registration module 2 (including SMS registration module 21, email registration module 22, website registration module 23, dynamic verification code service module 231, and key file generation module 232).

[0172] System login module 3.

[0173] Clue handling module 4 (including clue acceptance module 41, preliminary review module 42, review and investigation module 43, final handling module 44, feedback and communication module 45, material supplementation module 46, and completion and archiving module 47).

[0174] Rewards Management Module 5 (including On-site Collection Module 51, Mailed Check Module 52, Transfer and Remittance Module 53, Online Shopping Module 54, and Entrusting Others Module 55).

[0175] SMS service module 6, Email service module 7.

[0176] Risk management module 8 (including text password modification module 81 and text password protection module 82).

[0177] 4.2 Data transmission mechanism between modules

[0178] One-way data transmission between modules is achieved through the underlying communication mechanism, preferentially using a one-way message queue deployed on the intranet. At the software architecture level, logical one-way data transmission is achieved through a one-way subscription mechanism in the message direction. A physical one-way network gateway can also be added to achieve hardware-level one-way transmission hardening, ensuring that reverse data packets are discarded at the physical layer. The one-way subscription mechanism of the message queue achieves logical one-way data transmission through the following architectural constraints:

[0179] (1) The data sending end is only responsible for publishing messages to the specified message queue or topic, and does not wait for or receive return values.

[0180] (2) The data receiver only subscribes to and consumes messages from the queue or topic, and does not have a channel to return data or write requests to the sender.

[0181] (3) There is no bidirectional communication interface or callback mechanism between the sending end and the receiving end, so that data flows only in a preset direction at the software architecture level.

[0182] If bidirectional communication is required, it can be achieved through a bidirectional configuration variant of the above mechanism. This solution does not depart from the scope of the communication architecture design of this invention.

[0183] 4.3 Communication and Data Interaction Relationships Between Modules

[0184] (1) The user environment detection module 1 connects to the account registration module 2 and the system login module 3 through a one-way data transmission interface and outputs the risk detection judgment result to both.

[0185] (2) The account registration module 2 connects to the system login module 3 through a one-way data transmission interface to transmit anonymous accounts and login credentials at all levels to the system login module 3.

[0186] (3) The system login module 3 connects to the clue handling module 4 and the reward management module 5 respectively through a one-way data transmission interface. After successful login, the login identifier is pushed to both modules without carrying user privacy information.

[0187] (4) The account registration module 2 and the system login module 3 are connected to the risk management module 8 through a one-way data transmission interface, and respectively upload login credential management request and login log.

[0188] (5) The clue handling module 4 connects to the reward management module 5 through a one-way data transmission interface. After the clue is closed and archived, the module pushes the closure mark and reward issuance trigger mark to the reward management module 5 through a one-way message queue.

[0189] (6) The SMS service module 6 and the email service module 7 communicate bidirectionally with the account registration module 2, the clue handling module 4 and the reward management module 5, respectively, to send notifications to users and receive user replies.

[0190] 5. Detailed Implementation Methods Referring to the Attached Drawings

[0191] 5.1 Reference Figure 1 A schematic diagram of the overall module structure and data flow interaction of the anonymous reporting system.

[0192] The system consists of a front-end interactive terminal, a reverse proxy middleware, a back-end server, and a data storage layer. The front-end interactive terminal forwards user HTTP requests to the back-end server after the reverse proxy middleware cleans them (removing identifiable characteristic fields such as IP address and User-Agent).

[0193] The modules and their composition included in the backend server have been fully described in the "Detailed Implementation - 4 Communication and Data Interaction Relationships between Modules" section. The specific data flow interaction relationships between the modules are as follows:

[0194] Number 1: User environment detection module 1 → Account registration module 2, System login module 3

[0195] The user environment detection module 1 serves as a pre-login risk detection unit. It does not collect privacy data throughout the process, but only analyzes the characteristics of human-computer interaction time sequence data to determine the risk, and pushes the risk determination result unidirectionally to the account registration module 2 and the system login module 3.

[0196] Number 2: Account registration module 2 → System login module 3

[0197] The account registration module 2 provides multiple anonymous registration methods, supports a multi-level login credential system, and pushes the generated anonymous accounts and login credentials at each level to the system login module 3 in a one-way manner.

[0198] Number 3: The system login module 3 → the clue handling module 4, the reward management module 5

[0199] The system login module 3 has two types of entry points: user login and reward management login. It has two built-in verification modes: step-by-step login credential verification and one-time centralized login credential verification. Before logging in, the user environment detection module 1 is forcibly called to perform risk detection. After the verification is successful, the login identifier is pushed unidirectionally to the clue handling module 4 and the reward management module 5 respectively.

[0200] Number 4: The clue handling module 4 → The reward management module 5

[0201] After the clues are closed and archived, the clue handling module 4 pushes the closure mark and reward issuance trigger mark to the reward management module 5 through a one-way message queue.

[0202] Number 5: The SMS service module 6, the email service module 7 ←→ the account registration module 2, the clue handling module 4, and the reward management module 5

[0203] The SMS service module 6 and the email service module 7 serve as the underlying communication support of the system. They communicate bidirectionally with the account registration module 2, the clue handling module 4, and the reward management module 5, respectively, to send notifications to users and receive user replies.

[0204] Number 6: Account registration module 2 → Risk management module 8

[0205] The account registration module 2 sends a one-way login credential management request to the risk management module 8.

[0206] Number 7: System login module 3 → Risk management module 8

[0207] The system login module 3 unidirectionally uploads login logs to the risk management module 8.

[0208] In the data storage layer, the reporting business database and the reward management database are physically deployed independently, and there is no direct cross-database data access channel between the two databases (marked with a cross). The reverse tracing path is blocked from the storage layer. The reporting business database is available for reading and writing by the clue handling module 4, and the reward management database is available for reading and writing by the reward management module 5.

[0209] The above modules work together to achieve core functions such as end-to-end anonymity protection, risk detection, login security, and reward distribution.

[0210] 5.2 Reference Figure 2 Website registration process flowchart

[0211] The website registration method is suitable for scenarios where users register through a website. Users do not need to provide any personal privacy information (including but not limited to mobile phone number, email address, social media account) throughout the process. They can complete the registration using only their self-defined username and multi-level login credentials.

[0212] 5.2.1 Process Steps

[0213] Step 1: The user opens the website registration page and starts the registration process.

[0214] Step 2: The system forcibly invokes the user environment detection module 1 to perform risk detection.

[0215] Step 3: The system determines the risk based on a preset threshold calibrated by statistical analysis methods (see "Detailed Implementation - 3 Threshold Calibration and Performance Verification" section of this manual for details); if a risk is detected, a risk warning will pop up and the system will exit registration; if there is no risk, proceed to the next step.

[0216] Step 4: Users fill in basic registration information. Users enter a custom username and a first-level text password (this text password is a mandatory verification method, valid indefinitely, and cannot be set to expire), and can set the total number of login credentials N (N is an integer greater than or equal to 2, preferably, N can be 2 to 5) through the drop-down selection box.

[0217] Step 5: Configure the first-level login credential supplementary verification method. Based on the first-level text password, users should configure it according to the following sub-steps:

[0218] Step 5-1: The user chooses whether to enable supplementary verification methods. They can choose to enable dynamic verification code method and / or key file method. The two methods can be used independently, simultaneously, or neither can be enabled.

[0219] Step 5-2a / 5-2b: If the user chooses to enable dynamic verification code, the user should enter the validity period; if the user chooses to enable key file, the user should enter the validity period.

[0220] Step 5-3a / 5-3b: After the system confirms the configuration, the dynamic verification code service module 231 generates a de-identified QR code that conforms to the otpauth URI scheme specification based on the TOTP algorithm of the IETF RFC6238 specification; the key file generation module 232 generates a dedicated binary key file using a key derivation algorithm.

[0221] Step 5-3c: The user scans the QR code to complete the binding using an authentication application that supports the standard TOTP protocol. After binding, a 6-digit dynamic verification code can be generated offline for login. The dynamic verification code will automatically expire and needs to be reconfigured and generated.

[0222] Step 5-3d: The user downloads the generated binary key file to their local machine for safekeeping. The user uploads the file to complete the verification process when logging in. The key file will automatically expire and needs to be reconfigured and generated.

[0223] Step 5-4: The user confirms the configuration, and the server stores the configuration information for this level of supplementary verification method.

[0224] Based on the total number of login credential levels N set in step 4, repeat the configuration logic in step 5 above for each level from level 2 to level N-1 to complete the configuration of the supplementary verification method.

[0225] Step 6: Enter the Nth level (last level) text password, which is a mandatory verification method for the Nth level.

[0226] Step 7: Configure the supplementary verification method for the Nth level login credentials. Referring to the configuration logic of the first level (steps 5-1 to 5-4), configure the supplementary verification method based on the Nth level text password (the dashed arrows in the figure indicate that the configuration logic of each level is the same).

[0227] Step 8: After configuring login credentials for all levels, the server stores the user's multi-level login credential association information and generates a unique anonymous account.

[0228] Step 9: Website registration process complete.

[0229] 5.2.2 Supplementary Verification Method

[0230] In addition to the mandatory text password, users can further select dynamic verification code and / or key file as supplementary verification methods for this level. The two supplementary verification methods can be selected independently or simultaneously, and the validity period of each supplementary verification method must be defined. If both dynamic verification code and key file are selected, then the login credentials for this level are configured with three verification methods (text password, dynamic verification code, and key file). Users can select any one of these verification methods to complete the login credentials verification for this level.

[0231] (1) Dynamic verification code method

[0232] After the user enters the validity period of the dynamic verification code, the dynamic verification code service module 231 generates a de-identified QR code that conforms to the otpauth URI scheme specification based on the TOTP algorithm specified in IETF RFC 6238. The user scans the QR code to bind the verification code using an authentication application that supports the standard TOTP protocol. After binding, a 6-digit dynamic verification code can be generated offline for login. The dynamic verification code will automatically expire after it expires, and the user needs to reconfigure and generate it.

[0233] In a preferred embodiment, the TOTP key seed is generated as follows: The server obtains the user-set text password and the validity period of the dynamic verification code; the text password is converted into a byte sequence using UTF-8 encoding, and then HMAC-SHA1 cryptographic hash operation is performed to obtain a first intermediate value; the validity period timestamp string is concatenated with the first intermediate value in sequence (timestamp first, first intermediate value last) to form a combined string; HMAC-SHA1 cryptographic hash operation is performed again on the combined string to obtain the TOTP key seed (160 bits); the TOTP key seed is Base32 encoded to obtain a key string. Based on the key string, an OTP URI scheme link is generated according to the RFC 6238 standard, and a QR code is generated and sent to the front-end interactive terminal. After the user scans the QR code to complete the binding using an authentication application that supports the standard TOTP protocol, a 6-digit dynamic verification code is generated for login. The server only stores the TOTP key seed and its validity period for subsequent login calculations of the dynamic verification code and comparison with the dynamic verification code generated by the user.

[0234] (2) Key file method

[0235] The key file generation module 232 obtains the plaintext text password entered by the user in real time during the current operation (following the "Specific Implementation - 2.1 General Memory Security Rules" in this specification), and generates a derived key using a key derivation algorithm with a random salt value. This derived key is processed through two paths: first, it is packaged into a binary key file for the user to download, serving as the user's login credential; second, it undergoes salted hashing, and the resulting verification value and validity period are stored on the server as the baseline value for subsequent verification. When the user logs in, they upload the key file to the server; the server parses the file and extracts the derived key; it performs the same salted hashing operation on the extracted derived key and compares the calculation result with the verification value stored on the server; if they match and the key file is within its validity period, the verification is successful; after expiration, the file automatically expires and needs to be reconfigured and generated.

[0236] (3) Algorithm type used in key file method

[0237] The server obtains the plaintext text password entered by the user in the current operation (following the "Specific Implementation Methods - 2.1 General Memory Security Rules" in this specification), and generates a derived key using a key derivation algorithm with a random salt value. For specific algorithm types and parameter configurations, please refer to the following exemplary configuration:

[0238] ①PBKDF2 algorithm configuration: HMAC-SHA256 is used as the pseudo-random function, the number of iterations is 100,000, the salt value length is 16 bytes, and the derived key length is 32 bytes.

[0239] ②BCrypt algorithm configuration: cost factor is 10, salt length is 16 bytes.

[0240] ③ Argon2id algorithm configuration: 3 iterations, 64MB memory, 1 degree of parallelism, 16-byte salt length, and 32-byte output length.

[0241] The algorithm types and parameter configurations described above are not essential technical features of this invention, and those skilled in the art can select or replace them according to security requirements and performance constraints.

[0242] 5.3 Reference Figure 3 A screenshot of the website registration information entry interface.

[0243] 5.3.1 Interface Description

[0244] Website users do not need to provide personal information such as mobile phone number, email address, or social media accounts during the registration process. They only need to set a username and multi-level login credentials to complete the registration.

[0245] 5.3.2 Interface Elements

[0246] Icon 1: Username input box. Users enter a custom username, which does not need to be associated with personal privacy information and serves as the user's anonymous identifier in the system.

[0247] Icon 2: First-level text password input box. Users set a text password for their first-level login credentials (enter password). The text password is a mandatory verification method, is valid indefinitely, and cannot be set to expire.

[0248] Icon 3: Confirm first-level text password input box. The user re-enters the above text password to confirm and prevent input errors.

[0249] Icon 4: Total Number of Levels Drop-down Selection Box. Users can set the total number of login credential levels N through the drop-down selection box. N is an integer greater than or equal to 2 (preferably, the value of N can be 2 to 5). After selection, the system will generate an N-level login credential configuration interface in subsequent steps. For each level from the second level to the Nth level, the system requires the user to enter the corresponding text password (the text password is a mandatory verification method for each level and is set by the user).

[0250] Label 5: Next button.

[0251] Icon 6: Privacy Protection Prompt Entry. The interface also displays a privacy protection prompt entry (marked with a dashed box), which clearly informs users of the system's data collection rules, privacy protection measures, and user rights. Users can click to view the detailed privacy protection commitment.

[0252] 5.4 Reference Figure 4 Website registration method, Nth level login credential configuration, supplementary verification method interface diagram.

[0253] 5.4.1 Interface Description

[0254] In addition to the mandatory Level N text password, users can further select dynamic verification code and / or key file as supplementary verification methods at this level through this interface.

[0255] 5.4.2 Interface Elements

[0256] Identifier 1: Current Status. The system displays the current status of the Nth level login credentials. Text password is a required verification method and has been set.

[0257] Identifier 2: Validity period of the Nth level dynamic verification code. The user enters the validity period of the Nth level dynamic verification code (in days). This supplementary verification method will automatically expire after the expiration date.

[0258] Identifier 3: Obtain the Nth level dynamic verification code. After the user clicks, the system generates a de-identified QR code conforming to the TOTP algorithm specified in IETF RFC 6238. The user then scans the QR code to bind the verification code using an authentication application that supports the standard TOTP protocol.

[0259] Identifier 4: Validity period of the Nth level key file. The user enters the validity period of the Nth level key file (in days). This supplementary verification method will automatically expire after the expiration date.

[0260] Identifier 5: Obtain the Nth level key file. After the user clicks, the system uses a key derivation algorithm to generate a binary key file for the user to download.

[0261] Identifier 6: Explanation. This indicates to the user that both supplementary verification methods can be enabled simultaneously, only one can be enabled, or neither can be enabled (only a text password can be used to complete this level of verification).

[0262] Identifier 7: Confirm Configuration. After the user completes the supplementary verification method configuration and clicks Submit, the server stores the configuration information for this level of supplementary verification method.

[0263] 5.5 Reference Figure 5 A diagram illustrating the Nth level login credential configuration and dynamic verification code interface for website registration.

[0264] 5.5.1 Interface Description

[0265] The dynamic verification code configuration interface for Level N login credentials.

[0266] 5.5.2 Interface Elements

[0267] Identifier 1: Validity period. The validity period (in days) for the user-entered dynamic verification code. This supplementary verification method will automatically expire after the expiration date.

[0268] Identifier 2: The system generates a QR code based on a text password. The dynamic verification code service module 231 generates an otpauth URIscheme link and a QR code based on the user-defined Nth level text password, according to the "Detailed Implementation - 5.2.2 Supplementary Verification Method" in this manual.

[0269] Icon 3: Display QR code.

[0270] Identifier 4: Link Format. The link format is otpauth: / / TOTP / {custom identifier}-{level}?secret={Base32 encoded TOTP key seed}, where the meanings of each parameter are as follows:

[0271] "{Custom identifier}" is, for example, "ab", which represents a user-defined identifier;

[0272] For example, “{level}” is “1”, which indicates the first level of login credentials;

[0273] "{Base32 encoded TOTP key seed}" is a system-generated Base32 encoded TOTP key seed, for example, "JBSEY3DPEHPK3PGB".

[0274] After the user scans the QR code to bind, the authentication application will display "ab-1" (the above values ​​are only examples and do not constitute a limitation on the scope of protection of this invention).

[0275] Identifier 5: Scan QR code to bind. Users can use an authentication application that supports the standard TOTP protocol (such as Google Authenticator, Microsoft Authenticator, Authy, etc.) to scan the QR code to complete the binding.

[0276] Identifier 6: Generate dynamic verification code. The authentication application generates a 6-digit dynamic verification code offline.

[0277] Identifier 7: Login Verification. Enter the dynamic verification code to complete the login credential verification for this level.

[0278] 5.6 Reference Figure 6 Login process diagram of step-by-step login credential verification mode

[0279] In the hierarchical login credential verification mode, the system verifies credentials level by level from the first level to the Nth level, with each level requiring individual confirmation from the user.

[0280] 5.6.1 Process Steps

[0281] Step 1: The user initiates a login request.

[0282] Step 2: The system forcibly invokes the user environment detection module 1 to perform risk detection.

[0283] Step 3: The system determines the risk based on a preset threshold calibrated by statistical analysis methods (see the "Detailed Implementation - 3 Threshold Calibration and Performance Verification" section of this manual for details); if a risk is detected, the login process is terminated; if there is no risk, proceed to the next step.

[0284] Step 4: The user performs the first-level login credential verification. According to the configured verification method, the user can choose any of the following verification methods to complete the verification: (1) Enter the first-level text password; (2) Enter the 6-digit first-level dynamic verification code generated by the authentication application; (3) Upload the first-level key file.

[0285] Step 5: Determine if the first-level login credential verification is successful; if it fails, the first-level error count increases by 1, and proceed to step 6; if it succeeds, proceed to step 7.

[0286] Step 6: The system determines whether the number of consecutive errors at this level has reached 3. If it has, the credentials at this level will be locked for 24 hours and the current login process will be terminated; if not, return to step 4 to re-enter the information.

[0287] Step 7: After the first level of verification is successful, proceed to the next level (second level) of login credential verification. For each level of verification, choose one of the configured verification methods.

[0288] Step 8: Continue in this manner until the Nth level of login credential verification. In the diagram, ellipses ("...") indicate that the same verification logic is repeated from the second level to the (N-1)th level.

[0289] Step 9: Has the Nth level login credential been verified? If it has, proceed to step 10; if it has not, increment the Nth level error count by 1 and proceed to step 11.

[0290] Step 10: After all N-level login credentials have been verified, login is successful, and the system generates a temporary session identifier.

[0291] Step 11: The system determines whether the cumulative number of consecutive errors for level N has reached 3. If it has, the credentials for that level will be locked for 24 hours and the current login process will be terminated. If not, return to step 8 to re-enter the information.

[0292] 5.6.2 Comprehensive Implementation Example

[0293] This embodiment takes N=3 login credential levels as an example to describe in detail the complete process from user registration to verification.

[0294] (1) Registration stage

[0295] Users set the total number of login credentials to 3 levels through the website registration page, with each level configured as follows:

[0296] Level 1: Text password (required) + dynamic verification code (supplementary verification method, valid for 90 days).

[0297] Level 2: Text password (required, no supplementary verification method configured).

[0298] Level 3: Text password (required) + key file (supplementary verification method, valid for 90 days).

[0299] During the registration process, the system performs the following internal processing:

[0300] ① First-level dynamic verification code generation

[0301] The system obtains the first-level plaintext text password and generates the TOTP key seed and corresponding QR code according to the "Detailed Implementation - 5.2.2 Supplementary Verification Method" in this manual.

[0302] ② Generation of the third-level key file

[0303] The system obtains the plaintext of the third-level text password and generates a key file according to the "Detailed Implementation - 5.2.2 Supplementary Verification Method" in this manual.

[0304] ③ Text cryptography processing at all levels

[0305] Each level of text cipher is salted with a random salt value, then hashed using SHA-256, and the hash value and salt value are stored in the database.

[0306] (2) Login phase

[0307] When a user initiates login, the system forcibly calls the user environment detection module 1 to perform risk detection; if there is a risk, the login is terminated; if there is no risk, the system proceeds to the step-by-step login credential verification process.

[0308] Level 1 Verification: Users can choose to enter a text password, a dynamic verification code, or upload a key file. In this example, the user chooses to enter a dynamic verification code. The system first reads the validity period of the Level 1 dynamic verification code from the server. If the current time has expired, the verification method is deemed invalid, and the system prompts the user to reconfigure and generate a new one. If it is within the validity period, the system uses the TOTP key seed stored on the server to calculate the dynamic verification code and compares it with the user's input. If this level fails three times consecutively, it is locked for 24 hours. If the comparison and verification pass, the system proceeds to Level 2 Verification.

[0309] Second-level verification: The user enters a second-level text password. The system retrieves the hash value and salt value of the text password stored on the server, performs the same salted hash operation on the user-entered text password, and compares the calculation result with the stored hash value. If this level fails three times consecutively, it is locked for 24 hours. If the comparison and verification pass, it proceeds to the third-level verification.

[0310] Level 3 Verification: The user uploads a Level 3 key file. The system first reads the validity period of the Level 3 key file from the server. If the current time has expired, the verification method is deemed invalid, and the system prompts the user to reconfigure and generate a new key. If it is within the validity period, the system parses the file, extracts the derived key, performs a salted hash on the derived key, and compares the calculation result with the checksum stored on the server. If this level fails three times consecutively, it is locked for 24 hours. If they match, the verification is successful.

[0311] After all three levels of verification are passed, the system generates a temporary session identifier.

[0312] (3) Exception handling

[0313] ① If any level of verification fails, the current login process will be terminated immediately, and subsequent levels of login credential verification will not continue.

[0314] ② During the single-level lockout period, even if the user enters the correct password, they will still be unable to pass the verification. The system will return "The login credentials for this level have been locked. Please try again in 24 hours".

[0315] ③ If a user forgets a certain level of text password, they can reset it themselves by combining the password protection question and answer for that level of text password (after resetting, the supplementary verification method for that level will also become invalid and needs to be reconfigured and generated).

[0316] The N=3 configuration in this embodiment is only a representative example. For other values ​​of N (such as N=2, N=4, N=5), the verification logic at each level is completely consistent with this embodiment. The only difference is the total number of login credentials. In actual applications, users can choose the total number of levels according to their security needs, and the configuration combination of supplementary verification methods at each level can also be flexibly adjusted.

[0317] 5.7 Reference Figure 7 A schematic diagram of the Nth level login credential verification interface in the hierarchical login credential verification mode.

[0318] 5.7.1 Interface Description

[0319] Verification interface for Level N login credentials.

[0320] 5.7.2 Interface Elements

[0321] Identifier 1: Select Verification Method. The system displays three verification methods (text password, dynamic verification code, and key file); users can switch between Identifier 2, Identifier 3, and Identifier 4 using the toggle control on the interface, and select any one to complete the login credential verification for this level.

[0322] Icon 2: Text password input box. After selecting this method, the user enters the set Nth level text password.

[0323] Icon 3: Dynamic verification code input box. After selecting this method, the user will open the authentication application, obtain a 6-digit dynamic verification code, and enter it.

[0324] Identifier 4: Key file upload area. Users can upload their key files after selecting this method.

[0325] Label 5: Confirm button.

[0326] 5.8 Reference Figure 8 A schematic diagram of the login process using a one-time centralized login credential verification mode.

[0327] In the one-time centralized login credential verification mode, users enter all levels of login credentials at once, and the system centrally verifies the login credentials at each level after submission.

[0328] 5.8.1 Process Steps

[0329] Step 1: The user initiates a login request.

[0330] Step 2: The system forcibly invokes the user environment detection module 1 to perform risk detection.

[0331] Step 3: The system determines the risk based on a preset threshold calibrated by statistical analysis methods (see the "Detailed Implementation - 3 Threshold Calibration and Performance Verification" section of this manual for details); if a risk is detected, the login process is terminated; if there is no risk, proceed to the next step.

[0332] Step 4: Enter all login credentials for all levels at once. The interface displays all input areas from Level 1 to Level N; each level displays three verification methods (text password, dynamic verification code, key file) for the user to choose from. The user can choose any one of the verification methods configured for that level without having to fill in all of them.

[0333] Step 5: Submit the application after the user confirms that everything is correct.

[0334] Step 6: The system centrally verifies login credentials at all levels.

[0335] Step 7: Any level of verification failed? If not, proceed to step 8; if yes, proceed to step 9.

[0336] Step 8: Login successful, the system generates a temporary session identifier.

[0337] Step 9: The system returns a uniform error message and does not record the number of single-level errors.

[0338] Step 10: Users can choose to re-enter and return to step 4 or choose to terminate login.

[0339] 5.9 Reference Figure 9 A schematic diagram of the one-time centralized login credential verification mode interface.

[0340] 5.9.1 Interface Description

[0341] The system centrally inputs verification information for all levels, and the page supports content verification and correction. After unified submission, the system centrally verifies the information.

[0342] 5.9.2 Interface Elements

[0343] Identifier 1: Current Status. The user is prompted to enter login credentials for each level sequentially, and can submit the completed information after verification and correction.

[0344] Identifier 2: First-level input area. This area contains input controls for three verification methods: text password, dynamic verification code, and key file. Choose one of these to complete the input for this level of verification.

[0345] Identifier 3: Input areas from level 2 to level N-1 (the number of input areas can be dynamically increased or decreased based on the number of login credentials set).

[0346] Label 4: Level N input area.

[0347] Icon 5: Confirm Login. Click the "Confirm Login" button for centralized system verification. If all levels of verification pass, login is successful; if any level of verification fails, a unified error message will be returned, and the number of errors at a single level will not be recorded. The user can choose to re-enter the information or terminate the login process.

[0348] 5.10 Reference Figure 10 Schematic diagram of the reward management and entrusted reward collection process

[0349] When entrusting someone to claim the reward, the whistleblower must designate at least one executor and may choose to designate several collaborators. The executor has the authority to claim the reward, while collaborators only hold subkey shares and participate in the master key recovery process by submitting their shares. They do not have the authority to claim the reward and have no right to view the whistleblower's anonymous account, the content of the tip, the progress of the tip, the reward amount, or the identity information of other collaborators. The whistleblower can flexibly allocate the shares: all Q subkey shares can be concentrated and distributed to the same executor (in which case the executor acts as all roles and only needs to submit P shares to claim the reward), or the shares can be distributed to multiple collaborators in any proportion to participate in the share submission.

[0350] 5.10.1 Process Steps

[0351] Step 1: The system background process pushes the reward distribution trigger flag unidirectionally to the reward management service process.

[0352] Step 2: The reward management service process receives the trigger flag, and the system generates a corresponding independent reward item on the reward management side.

[0353] Step 3: After the whistleblower completes identity verification through the user login portal, they enter the reward management configuration interface to configure the entrusted reward collection. The whistleblower sets the total number of sub-key shares Q and the minimum number of valid shares P required to recover the master key (Q and P satisfy the aforementioned threshold constraints), designates at least one executor and optionally several collaborators. The system splits the reward collection master key into Q sub-key shares and adds a commitment value to each share. It maintains a mapping table between the unique identifier of the share and the reward item in the reward management database, and records the role type (executor / collaborator) corresponding to each share. The key splitting process does not read or cache the plaintext data of the whistleblower clues or the whistleblower identity mapping data.

[0354] Step 4: The whistleblower distributes the Q-share key to each executor and collaborator through channels outside the system (such as offline or encrypted communication). During this process, the whistleblower can distribute the entire share to a single executor, or distribute it proportionally to multiple collaborators as needed.

[0355] Step 5: The executor or collaborator submits the sub-key share through the reward management login portal. Neither the executor nor the collaborator needs to enter a username or login credentials at any level.

[0356] Step 6: After receiving the subkey share submitted by the executor and collaborator, the system first uses the commitment value to perform a single-share legality verification to verify whether the share is a valid share generated during distribution; if the verification fails, it will return to step 5 with the message "Share invalid, please re-enter"; if the verification passes, it will proceed to step 7.

[0357] Step 7: After successful verification, the system records the verification time of the share and sets the session validity period (e.g., 24 hours, the specific duration can be configured according to actual implementation needs). After the session validity period expires, the share needs to be resubmitted. The system will send a message to the submitter: "The share you entered is valid. This session is valid for 24 hours. Please re-enter after it expires."

[0358] Step 8: The system extracts the unique identifier from the share, queries the mapping table to determine the reward item and role type (executor / collaborator) to which the share belongs, and records the received valid shares in the memory space of the item.

[0359] Step 9: Count the number of valid shares that are still within the session validity period.

[0360] Step 10: The system determines whether the number of valid shares within the session validity period is greater than or equal to the minimum number of valid shares P required for the matter, and whether it includes the valid shares of at least one executor; if it is satisfied, proceed to step 11; if it is not satisfied, proceed to step 14.

[0361] Step 11: The system restores the master key in memory, and the executor is now eligible to claim the prize.

[0362] Step 12: The executor enters the reward management interface, where they can view complete progress information and perform reward setting and claiming operations.

[0363] Step 13: Once the reward has been distributed, the system's obligation to fulfill its obligations regarding this reward terminates.

[0364] Step 14: If the authorization conditions are not met, the reward will not be issued temporarily. Return to Step 5 and continue to wait for the share to be submitted.

[0365] Step 15: Whistleblowers can log in to the system at any time through the user login portal to view all audit logs of all executors and collaborators, and can revoke the authorization of any executor or collaborator at any time (the dashed arrows in the figure indicate "intervene at any time" and "revoke authorization"). After revocation, the corresponding subkey share will immediately become invalid.

[0366] 5.11 Reference Figure 11 Rewards Management Login Interface Illustration

[0367] 5.11.1 Interface Description

[0368] The executor and collaborators submit subkey shares through the reward management login portal. Each submission is for one subkey share. The system automatically identifies the submitter's identity based on the role type embedded in the share and presents a differentiated view based on the role type.

[0369] (1) Collaborator View (Identifier 5)

[0370] After the collaborator's verification is successful, they will enter the rewards management interface. The system will display: "The share you entered is valid. This session is valid for 24 hours. Please re-enter after it expires." Audit logs corresponding to the user's share identifier can be viewed, but audit logs corresponding to other share identifiers cannot be viewed.

[0371] (2) Executor view (Identifier 7, Identifier 8)

[0372] After the executor is verified, they will enter the reward management interface, where they can view complete progress information (total number of valid shares collected, submission time of each share, remaining validity time of the session, and number of valid shares still needed). The system will verify whether the conditions are met (number of valid shares within the session validity period ≥ minimum number of valid shares P required for the matter, and at least one valid share of the executor is included). If the conditions are met, the reward setting and claiming operations can be performed; if not, the system will display a progress message: "X shares collected, Y shares still needed", but the reward setting and claiming operations cannot be performed.

[0373] (3) Hierarchical view isolation

[0374] The system determines the submitter's role based on the role type embedded in the share. Executors can only view the executor view, and collaborators can only view the collaborator view.

[0375] (4) Expediting mechanism

[0376] The system does not provide an online expediting channel. The executor can check the current progress through the reward management interface. If the valid share is insufficient, the whistleblower can be contacted, who will then contact the collaborator to urge them to submit their share.

[0377] 5.11.2 Interface Elements

[0378] Identifier 1: Current Status Indication. This indicates that the executor and collaborators do not need to enter usernames or login credentials at any level; they only need to submit one subkey share at a time.

[0379] Identifier 2: Subkey Share Input Box.

[0380] Icon 3: Submit button.

[0381] Identifier 4: Determine role type. The system performs share verification. If the verification is successful, proceed to Identifier 5 if the user is a collaborator, and to Identifier 6 if the user is an executor.

[0382] Icon 5: Collaborator View.

[0383] Identifier 6: Executor Verification. The system verifies in real time whether the valid shares still within the session's validity period meet the P-share condition. If they do, Identifier 7 is displayed; otherwise, Identifier 8 is displayed.

[0384] Identifier 7: Executor view (satisfies P copies).

[0385] Identifier 8: Executor view (does not satisfy P).

[0386] Identifier 9: Prompt Text Block (Supplementary Explanation from the Executor View). The system does not provide an online expediting channel. Executors can view the current progress through the reward management interface. If the valid quota is insufficient, they can contact the whistleblower, who will then contact the collaborators to urge them to submit their quota.

[0387] 5.12 Reference Figure 12 A complete business process implementation diagram

[0388] This embodiment presents the complete process from registration to claiming the reward from the perspective of a specific user.

[0389] 5.12.1 Phase Division

[0390] The entire process is divided into three stages:

[0391] (1) Registration and login stage (steps 1 to 2): Users complete the login credential level settings to register an account. When logging in, risk detection is performed first, and then login credentials at each level are verified.

[0392] (2) Reporting and handling stage (steps 3 to 11): The clues are transferred in sequence, and "Does it need to supplement materials?" (step 7) is a general auxiliary node for the whole process.

[0393] (3) Award collection by proxy stage (steps 12 to 17): The informant configures Q=4 and P=3, designates 1 executor (holding 2 copies) and 2 collaborators (each holding 1 copy) to entrust the collection of the award.

[0394] 5.12.2 Process Steps

[0395] Step 1: User registration.

[0396] Step 2: Login verification.

[0397] Step 3: Submit a tip.

[0398] Step 4: Accepting clues.

[0399] Step 5: Preliminary review.

[0400] Step 6: Review and investigation.

[0401] Step 7: Do we need to provide additional materials? The staff will determine whether additional materials are needed; if so, proceed to Step 8; if not, proceed to Step 9.

[0402] Step 8: Material replenishment.

[0403] Step 9: Feedback and communication.

[0404] Step 10: Final Disposal.

[0405] Step 11: Complete and archive.

[0406] Step 12: Configure the delegated prize collection.

[0407] Step 13: Collaborator 1 submits the subkey share.

[0408] Step 14: Collaborator 2 submits the subkey share.

[0409] Step 15: The executor submits the subkey share.

[0410] Step 16: Determine if there are at least 3 valid shares within the session's validity period, including the executor's share. If not, return to step 13; if yes, proceed to step 17.

[0411] Step 17: Recover the master key and distribute the reward.

[0412] 5.12.3 Implementation Method

[0413] Taking user "A" as an example, A registers through the website and sets the total number of login credentials to N=3. The first-level text password is set to, for example, "Abc@730702", and a first-level dynamic verification code is configured, valid for 90 days, and bound using an authentication application scanning a QR code; the second-level text password is set to, for example, "Xyz!010805" (without selecting a supplementary verification method); the third-level text password is set to, for example, "Pwd#480222", and a third-level key file is configured, valid for 90 days, and downloaded and stored on the user's local device. The system performs salted hash processing on each of the three levels of text passwords and stores them on the server; the TOTP key seed and corresponding validity period of the dynamic verification code are stored on the server; the derived key verification value and corresponding validity period corresponding to the key file are stored on the server. The original plaintext text passwords are processed according to "Specific Implementation Methods - 2.1 General Memory Security Rules" in this specification (the above usernames and passwords are exemplary data and do not constitute a limitation on the scope of protection of this invention).

[0414] After successful registration, User A initiates login. During page loading, the front-end script disables all device fingerprint collection interfaces and clears the local cache. User A enters the first-level text password. The front-end collects timing data such as the keystroke interval sequence and input pause duration, uploading it to the server. The server calculates the standard deviation of the keystroke interval and the input pause duration, comparing them with preset thresholds. If the data is deemed to be from a real person (the keystroke interval fluctuates randomly, with one pause exceeding 2.2 seconds), the risk detection passes. User A then sequentially completes the following steps in the hierarchical login credential verification mode: first-level dynamic verification code input; second-level text password input; and third-level key file upload. After all three levels of verification pass, the server generates a temporary session identifier.

[0415] After logging in, A fills in the report online and uploads materials. The system associates the report information with the user's anonymous account, generates an anonymous clue file, and submits it to the clue handling module 4. The clue goes through the acceptance, preliminary review, and investigation stages. During the investigation, if staff find that supplementary materials are needed, the supplementary materials module 46 is triggered, and the system notifies A through the website. After logging in, A uploads the supplementary materials, and the clue returns to the investigation stage for further processing.

[0416] The clues continue to flow through feedback and communication, final handling, and filing. After the clues are filed, the system background process pushes a reward issuance trigger marker to the reward management service process, and the system generates an independent reward item on the reward management side.

[0417] A logs into the system and enters the reward management configuration interface, sets Q=4 and P=3, and designates 1 executor (his relative) and 2 collaborators (his colleagues); the system constructs a polynomial of degree P-1=2 with the master key for receiving the reward as a constant term, generates 4 sub-key shares, adds a commitment value to each share, maintains a mapping table between the unique identifier of the share and the reward item in the reward management database, and records the role type corresponding to each share; A distributes the 4 shares to 3 agents (the executor holds 2 shares, and the 2 collaborators each hold 1 share).

[0418] One collaborator submits their share through the reward management login portal. The system uses the commitment value to verify the validity of a single share. After successful verification, a session validity period is set, and the share is added to the valid share (current valid share: 1 / 4). Another collaborator also submits and passes verification (current valid share: 2 / 4). The executor logs into the reward management portal, submits their share, and after successful verification, a session validity period is set, and the share is added to the valid share (current valid share: 3 / 4, including the executor's share). If the number of valid shares reaches P (P=3) within the session validity period, including the executor's share, the system restores the master key in memory. After successful restoration, the executor can claim the reward. After claiming the reward, the system marks the reward event as "completed," and the performance obligation terminates. A can log into the system at any time to view the audit logs of all executors and collaborators. If there are any objections, an objection application can be submitted. The system will retrieve the audit logs associated with the reward as the basis for dispute resolution.

[0419] In the above process, the three-layer privacy isolation global pre-constraints are always in effect: the front end does not collect device fingerprints, the reverse proxy does not retain IP addresses and User-Agents, the backend contact information is encrypted and stored, and the reporting business database and the reward management database are physically deployed independently, ultimately achieving persistent storage of no privacy data throughout the entire chain.

[0420] This invention uniformly supports three business implementation modes. The only differences between the modes are in the clue submission method and user interaction channel. In order to enable those skilled in the art to clearly and completely implement this invention, the three modes are described in detail below with reference to the accompanying drawings. The operation steps in each embodiment correspond to steps 1 to 5 in the independent claims, and the overall process and unique operation of each mode are further explained.

[0421] 5.13 Reference Figure 13 Implementation Method 1: Flowchart of the Reporting Mode by Mailing or Placing Materials

[0422] This implementation method is suitable for scenarios where submitting complaint materials online is inconvenient (such as when the complaint materials contain a large number of paper documents, physical evidence, or when users are concerned that online transmission may easily leak personal information). Users submit complaint materials by mail or by placing them in a designated location, and then interact lightly via website, SMS, or email instructions. In this implementation method, the complaint materials are linked to the anonymous account through manual entry, and no personal privacy information is collected throughout the entire process.

[0423] 5.13.1 Overall Process

[0424] Step 1: Users complete the general account registration process via SMS, email, or website to obtain an anonymous account.

[0425] Step 2: Users submit their reports by mail or by leaving them at the designated location. The reports should only include the registered anonymous account information and should not contain personal information such as name, contact information, or address.

[0426] Step 3: Staff manually enter the information of the reported materials at the clue acceptance portal, associate the information of the reported materials with the anonymous account marked by the user, and generate an anonymous clue file.

[0427] Step 4: The system determines whether the user has actively logged into the website; if not, proceed to Step 5; if logged in, proceed to Step 6.

[0428] Step 5: Users can engage in lightweight interaction via SMS or email commands (users can send query commands with content or subject "cx", or feedback commands with content or subject "fk").

[0429] Step 6: Users log in to the system through the website user login portal, and the system performs three-layer privacy isolation global pre-constraints (see the "Detailed Implementation - 2 General Privacy Rules" section of this manual for details), risk detection, and multi-level login credential verification.

[0430] Step 7: The system determines the type of operation performed by the user after logging in, which is divided into two types: "communication feedback / supplementary materials" and "receive reward", corresponding to Step 8 and Step 10 respectively.

[0431] Step 8: Users communicate and provide feedback online.

[0432] Step 9: The user submits supplementary materials online.

[0433] Step 10: Users can choose to receive the reward themselves or entrust someone else to receive it on their behalf. Users can receive the reward themselves in person, by mailing a check, by bank transfer, or by purchasing items online. Users can entrust someone else to receive the reward on their behalf through a threshold-based confidentiality sharing mechanism.

[0434] 5.13.2 Unique Operation

[0435] The unique operation of this implementation method, which distinguishes it from other implementation methods, is reflected in the following aspects:

[0436] (1) Material submission method: Users do not need to fill in the content of the report online, but can mail or place the report materials at a designated location; this method is suitable for scenarios that include paper documents, physical evidence and other materials that are inconvenient to submit online.

[0437] (2) Anonymous account labeling: After completing the general registration process, users only need to label the registered anonymous account on the reporting materials without filling in personal privacy information, thereby blocking the connection between the reporting materials and the real identity of the reporter.

[0438] (3) Manual entry in the background: Staff enter the information of the report materials, associate the information of the report materials with the anonymous account marked by the user, and generate an anonymous clue file; do not collect or retain personal privacy information such as the name, ID number, and contact information of the reporter.

[0439] (4) Lightweight offline interaction: For users who register via SMS or email, they can also perform lightweight query and feedback operations via SMS or email commands (users can send query commands with content or subject "cx", or feedback commands with content or subject "fk"), and obtain the status of clue processing without logging into the website.

[0440] 5.14 Reference Figure 14 Implementation Method Two: Flowchart of Website Reporting Mode

[0441] This implementation method is applicable to scenarios where users have internet access and wish to complete the entire reporting process through a website. After registration, users log in to the system via the website to complete all operations online, including online reporting, clue processing, communication feedback, reward management, and risk management. In this implementation method, a three-layer privacy isolation global pre-constraint is implemented throughout the entire process: the front end does not collect device privacy data, the reverse proxy does not forward identifiable client feature fields, and the backend server does not store personal privacy information, thereby achieving anonymity protection throughout the entire reporting chain.

[0442] 5.14.1 Overall Process

[0443] Step 1: Users complete the general account registration process via SMS, email, or website to obtain an anonymous account.

[0444] Step 2: Users log in to the system through the website user login portal, and the system performs three-layer privacy isolation global pre-constraints (see the "Detailed Implementation - 2 General Privacy Rules" section of this manual for details), risk detection, and multi-level login credential verification.

[0445] Step 3: After logging in, users fill in the report content and upload materials online. The system will then associate the report information with the user's anonymous account to generate an anonymous clue file.

[0446] Step 4: The system performs closed-loop management of the entire lifecycle of clue handling through the clue handling module 4, including clue acceptance, preliminary review, investigation, final handling, feedback and communication, material supplementation, and completion and archiving.

[0447] Step 5: Users communicate and provide feedback online.

[0448] Step 6: Users can choose to receive the reward themselves or entrust someone else to receive it on their behalf. Users can receive the reward themselves in person, by mailing a check, by bank transfer, or by purchasing items online. Users can entrust someone else to receive the reward on their behalf through a threshold-based confidentiality sharing mechanism.

[0449] Step 7: Users can manage risks through methods such as setting clue aliases, querying audit logs, resetting text passwords at all levels, and modifying login credentials at all levels.

[0450] 5.14.2 Unique Operation

[0451] The unique operation of this implementation method, which distinguishes it from other implementation methods, is reflected in the following aspects:

[0452] (1) Risk detection during login: When a user logs into the website, the system forcibly starts the user environment detection module 1 to collect human-computer interaction time sequence data, and makes risk judgment based on the preset threshold calibrated by statistical analysis method (see the “Specific Implementation - 3 Threshold Calibration and Performance Verification” section of this manual for details). No private data such as IP address, User-Agent, Cookie, and device fingerprint are collected throughout the process.

[0453] (2) Multi-level login credentials verification: The login process supports two verification modes: step-by-step login credentials verification and one-time centralized login credentials verification.

[0454] (3) The entire process is online: the entire process of submitting, accepting, preliminary reviewing, examining, handling, and providing feedback on the tip is completed online. The tip status is updated in real time, and users can log in to the website at any time to check the progress and supplement materials.

[0455] 5.15 Reference Figure 15 Implementation Method 3: Flowchart of a Reporting Model Combining Online and Offline Methods

[0456] This implementation method is suitable for scenarios where users wish to combine offline submission of complaint materials with online communication and feedback, balancing the security of offline submission with the convenience of real-time online communication. Users first submit complaint materials by mail or offline, and can then choose to log in to the website to complete the entire process, or choose not to log in and only interact via SMS or email. In this implementation method, no personal privacy information is collected during the offline submission stage, and the online interaction stage only links the complaint materials to an anonymous account, achieving a combination of offline materials and online anonymity.

[0457] 5.15.1 Overall Process

[0458] (1) Offline stage

[0459] Step 1: Users complete the general account registration process via SMS, email, or website to obtain an anonymous account.

[0460] Step 2: Users submit their reports by mail or by leaving them at the designated location. The reports should only include the registered anonymous account information and should not contain personal information such as name, contact information, or address.

[0461] Step 3: Staff manually enter the information of the reported materials at the clue acceptance portal, link the information of the reported materials with the anonymous account marked by the user, and generate an anonymous clue file.

[0462] Step 4: Users can engage in lightweight interaction via SMS or email commands (users can send query commands with content or subject "cx", or feedback commands with content or subject "fk").

[0463] (2) Online stage

[0464] Step 5: The system determines whether the user has actively logged into the website; if not, proceed to Step 4 and continue with lightweight interaction via SMS or email commands (shown as "No, do not log in" in the diagram); if logged in, proceed to Step 6.

[0465] Step 6: Users log in to the system through the website user login portal, and the system performs three-layer privacy isolation global pre-constraints (see the "Detailed Implementation - 2 General Privacy Rules" section of this manual for details), risk detection, and multi-level login credential verification.

[0466] Step 7: Users communicate and provide feedback online.

[0467] Step 8: The system performs closed-loop management of the entire lifecycle of clue handling through the clue handling module 4, including clue acceptance, preliminary review, investigation, final handling, feedback and communication, material supplementation, and completion and archiving.

[0468] Step 9: Users can choose to receive the reward themselves or entrust someone else to receive it on their behalf. Users can receive the reward themselves in person, by mailing a check, by bank transfer, or by purchasing items online. Users can entrust someone else to receive the reward on their behalf through a threshold-based confidentiality sharing mechanism.

[0469] Step 10: Users can manage risks through methods such as setting clue aliases, querying audit logs, resetting text passwords at all levels, and modifying login credentials at all levels.

[0470] 5.15.2 Unique Operation

[0471] In this embodiment, the offline stage is the same as in Embodiment 1 (see "Specific Embodiments - 5.13.2 Unique Operations" section of this specification for details). Based on this, the unique operations of this embodiment, which distinguish it from other embodiments, are reflected in the following aspects:

[0472] (1) Two interaction paths: This implementation provides two interaction paths for users to choose from; users can interact online after logging into the website; if they do not log into the website, they can still interact lightly through SMS or email commands.

[0473] (2) Seamless switching between the two paths: the user logs in to the website as the switching condition; before logging in, the user can perform a light interaction via SMS or email instructions; after logging in, the user switches to online interaction.

[0474] In the above three implementation methods, there is no network access behavior during the offline stage, so the constraints on the front-end side and the reverse proxy middleware side in the general privacy rules are not effective; when the user actively logs into the website, the three-layer privacy isolation global pre-constraint is executed in accordance with the general privacy rules (the general privacy rules are detailed in the "Specific Implementation Methods - 2 General Privacy Rules" section of this specification).

[0475] In summary, this invention employs a three-layer privacy isolation architecture comprised of a front-end interactive terminal, a reverse proxy middleware, and a back-end server to achieve zero retention of user privacy data throughout the entire process, fundamentally severing the path to identity tracing. It utilizes human-computer interaction time-series data analysis to replace device fingerprints for automated script risk detection, avoiding the collection of terminal privacy data. It supports users configuring multi-level login credentials, enhancing account security. The reporting business database and reward management database are physically deployed independently, and an anonymous reward claiming mechanism based on threshold secret sharing enables decoupling of reporting identity and reward claiming behavior. These technical measures work synergistically to achieve anonymous reporting while ensuring account security.

[0476] The above description is merely an exemplary embodiment of the present invention and is not intended to limit the scope of protection of the present invention; any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be covered within the scope of protection of the present invention.

Claims

1. An anonymous reporting system based on multi-level login credentials, comprising a front-end interactive terminal, a reverse proxy middleware, and a back-end server, the three being connected via a communication network, characterized in that, These three elements constitute a three-layer privacy isolation architecture, ensuring that user privacy data is not persistently stored at any of the three stages: the front-end interactive terminal, the reverse proxy middleware, and the back-end server. The specific configuration of this three-layer privacy isolation architecture is as follows: The front-end interactive terminal is configured to provide a user interaction interface and clear local persistent data and disable the device fingerprint collection interface by loading a script on the page. The reverse proxy middleware is configured to intercept and remove client network identity data in the request header and disable access logging; The backend server comprises a physically separate, independently deployed reporting service database and a reward management database, with no direct cross-database access channel between the two databases. The backend server is configured to run reporting service processes and reward management service processes in process-level isolation. The reporting service process only accesses the reporting service database, while the reward management service process accesses the reward management database and responds to reward data query and operation requests submitted through the user login portal or the reward management login portal. The reward management service process does not establish a direct data access channel with the reporting service database. The backend server includes the following functional modules: The user environment detection module is configured to collect only human-computer interaction time-series data and use preset thresholds calibrated by statistical analysis methods to determine the risk of automated script attacks. The account registration module includes a website registration module, an SMS registration module, and an email registration module, and is configured to generate anonymous accounts and multi-level login credentials; the multi-level login credentials are a set of N-level (N≥2) login credentials set by the user. The system login module is configured to respond to the detection result of the user environment detection module. If the detection is successful, it receives and verifies the anonymous account and login credentials at all levels entered by the user. After successful verification, it pushes the login identifier to the clue handling module and the reward management module respectively. This login identifier is a temporary session identifier that exists only in memory and is not written to the log or persistent storage. It is automatically destroyed after the timeout. The clue handling module is configured to perform closed-loop management of the entire lifecycle of reported clues, and push a reward issuance trigger marker to the reward management module after the clue is closed and archived. The trigger marker includes the reward item number and reward content, but does not include the report content or the whistleblower's privacy information. The reward management module includes a delegation module and is configured to perform delegated reward collection business based on a threshold secret sharing mechanism; It also includes SMS service module, email service module, and risk management module.

2. The anonymous reporting system according to claim 1, characterized in that, The three-layer privacy isolation architecture is configured to collaboratively enforce the following three-layer privacy isolation constraint rules: On the front-end interactive terminal side, the device fingerprint collection interface is disabled, third-party tracking scripts are deleted, cookies are automatically cleared, and LocalStorage, SessionStorage, and IndexedDB local data storage interfaces are disabled through page scripts. On the reverse proxy middleware side, the request headers are standardized and cleaned by removing the client IP address and User-Agent fields, generalizing the Accept-Language and Accept-Encoding fields to preset neutral values, and normalizing and rearranging the order of the request header fields to eliminate identifiable features caused by differences in the order of request headers from different clients. The minimum necessary request header fields, after generalization, along with the business data fields, are forwarded to the backend server. Immediately after the request is completed, clear all request header data in memory; disable the business access log recording function, only allow writing to the operating system level fault error log, and remove client characteristic variables such as $remote_addr and $http_user_agent from the log template; On the backend server side, the processor uses a symmetric reversible encryption algorithm to encrypt the mobile phone number and email fields before storing them in the database. The encryption key is managed by a hardware security module or key management service that is independent of the business database and is only used for decryption when the system needs it. Within the three-layer privacy isolation architecture adopted by this system, no user privacy data such as IP address, User-Agent, device fingerprint, and browser hardware characteristics are forwarded or persistently retained throughout the entire link, achieving zero retention of user privacy data throughout the entire link and fundamentally cutting off the path for tracing the identity of whistleblowers.

3. The anonymous reporting system according to claim 1, characterized in that, The user environment detection module is a pre-login risk detection unit of the system login module, and it does not collect IP address, User-Agent, Cookie, or device fingerprint throughout the entire process; The user environment detection module only collects human-computer interaction timing data, including the interval sequence of adjacent keys in the input box, the pause duration of the input box focus, and the backspace key usage marker data; The user environment detection module performs risk assessment based on the collected time-series data, and determines that a risk exists when any of the following conditions are met: The key spacing standard deviation was detected to be less than the preset key spacing standard deviation threshold; The system detected no input pauses exceeding the preset input pause duration threshold and no backspace, deletion, or modification operations. The preset key interval standard deviation threshold and the preset input pause duration threshold are calibrated by statistical analysis methods to distinguish between automated input behavior and manual input behavior.

4. The anonymous reporting system according to claim 1, characterized in that, The website registration module includes a dynamic verification code service module and a key file generation module; The website registration module adopts a multi-level login credential system and is configured to allow users to set custom usernames as anonymous accounts, and supports users to set the number of levels N of multi-level login credentials, where N≥2; The Nth level login credential consists of a mandatory Nth level text password and an optional Nth level dynamic verification code and / or Nth level key file. The Nth level text password is the mandatory verification method for this level. Users can further configure an Nth level dynamic verification code generated by the dynamic verification code service module and / or an Nth level key file generated by the key file generation module as supplementary verification methods. If the user does not select a supplementary verification method, the login credential for this level only includes a text password. The text password is a static string credential and remains valid as long as the user does not actively modify it, the account is not canceled, and the risk management module does not trigger a reset operation. The supplementary verification method has an expiration period, which is configured by the user when generating the method. After the expiration period, the supplementary verification method will automatically become invalid and needs to be reconfigured and generated. The key file generation module is configured to perform a key derivation algorithm on the user-defined text password to generate a derived key, package the derived key into a binary key file for the user to download, and simultaneously perform salted hashing on the derived key and store the resulting verification value on the server. The website registration module allows users to complete registration without providing personal privacy information. When logging in, users can choose any of the configured verification methods at that level to complete the login credential verification for that level. After passing the login credential verification at all levels, users can log in to the system.

5. The anonymous reporting system according to claim 4, characterized in that, The dynamic verification code service module is configured to generate a TOTP key seed, which, after Base32 encoding, generates a de-identified QR code conforming to the TOTP URI scheme (RFC 6238) specification; it supports third-party authentication applications using the standard TOTP protocol to scan the QR code to complete TOTP key seed binding and offline verification. Once the TOTP key seed reaches its expiration date, it will automatically expire. Users need to regenerate the QR code and bind it again. The system will overwrite the old key seed with the new key seed. There is no coexistence window between the old and new key seeds, and no user privacy information is recorded throughout the entire process. The dynamic verification code service module is configured to generate 6-digit dynamic verification codes based on the TOTP algorithm specified in IETF RFC 6238.

6. The anonymous reporting system according to claim 1, characterized in that, The SMS registration module is configured to receive registration instructions sent by users to a designated number in the system via an SMS service gateway, automatically generate anonymous accounts and multi-level login credentials, and reply via the original SMS service gateway. The email registration module is configured to receive registration emails sent by users to a system-specified email address via an email service protocol, automatically generate anonymous accounts and multi-level login credentials, and reply to the sender's email address via the email service protocol. The anonymous accounts generated by the SMS registration module and the email registration module do not contain users' personal privacy information, and each level of the generated multi-level login credentials only contains the text password of that level. SMS and email registration serve as supplementary alternatives to website registration. After registration, users can verify login credentials at various levels through the system's login module and then perform the entire anonymous reporting process on the website. They can also conduct lightweight interactions via SMS or email commands. The system only retains the user's mobile phone number or email address for contact and subsequent command interactions. The retention scope is limited to the minimum necessary for achieving the contact function, and no other private information is collected. Furthermore, the aforementioned information is encrypted using a symmetric reversible encryption algorithm before storage.

7. The anonymous reporting system according to claim 1, characterized in that, The system login module sets up two types of login entrances: user login and reward management login. Before logging in, the user environment detection module is forcibly invoked to complete risk detection. The system has a built-in step-by-step login credential verification mode and a one-time centralized login credential verification mode; In the hierarchical login credential verification mode, the system verifies login credentials level by level from the first level to the Nth level, with each level confirmed separately. If the number of consecutive incorrect entries for a single-level login credential reaches a threshold, that level of credential will be locked. If any level of login credential verification fails, the current login process will be terminated immediately. In the one-time centralized login credential verification mode, users centrally input login credentials for all levels. The page supports content correction and verification. After unified submission, the system centrally verifies login credentials for each level. If all levels of login credentials are verified successfully, the user is allowed to log in. If any level of verification fails, a unified error message is returned, and the number of errors is not recorded. The user can choose to re-enter the credentials or terminate the login.

8. The anonymous reporting system according to claim 1, characterized in that, The clue handling module includes a clue acceptance module, a preliminary review module, an investigation module, a final handling module, a feedback and communication module, a material supplementation module, and a completion and archiving module. Clues flow sequentially between these modules. The material replenishment module is a universal auxiliary module for the entire process. It can be triggered at any stage of the lead flow if there is missing material or doubt about the information. After the material is replenished, the lead returns to the original stage for further processing. The lead status is automatically updated after each module operation is completed. After the lead is closed and archived, the system pushes a reward distribution trigger flag to the reward management service process through a one-way message queue.

9. The anonymous reporting system according to claim 1, characterized in that, The "Delegate to Others" module is configured as follows: (1) Role designation and share distribution: The system generates a unique master key for each reward item, constructs a polynomial of degree P-1 with the master key as a constant term, splits it into Q subkey shares, adds a commitment value to each subkey share and distributes it to the executor and collaborators; maintains a mapping table between the unique identifier of the share and the reward item in the reward management library, and records the role type corresponding to each share; the informant must designate at least one executor and may selectively designate several collaborators, among whom only the executor has the right to receive the reward, and the collaborators only hold the subkey shares and participate in the share submission, and do not have the right to receive the reward; when the master key is restored, the number of valid shares must reach P shares during the session validity period, and at least one of them must be the valid share of the executor, where the minimum number of valid shares P and the total number of shares Q satisfy the constraints Q≥P, Q≥2, P≥2; (2) Share Submission and Identity Recognition: The executor and collaborator submit their subkey shares through the reward management login portal without needing to enter a username or login credentials at any level. The system first uses the commitment value corresponding to the share for legality verification. After the verification is passed, a session validity period is set for the share and it is counted as a valid share. After the session validity period expires, the share needs to be resubmitted. The system queries the mapping table based on the share identifier to identify the reward item and role type to which it belongs. When the number of valid shares for a certain reward item reaches the minimum number of valid shares P within the session validity period, and at least one of them contains the executor's valid share, the master key is restored and the executor is authorized to enter the reward management interface to perform the reward claim operation. Otherwise, it continues to wait for other delegates to submit shares. Whistleblowers can view the audit logs of all executors and collaborators through the user login portal, and have the right to revoke the authorization at any time. After revocation, the corresponding subkey share will immediately become invalid.

10. The anonymous reporting system according to claim 1, characterized in that, The risk management module has functions such as setting clue aliases, querying audit logs, resetting text passwords at all levels, and modifying login credentials at all levels. The alias setting for clues is used to enable anonymous display of clue information; The audit log query is used to view all login logs and operation records; The text password reset is used to reset the password when a user forgets a certain level of text password by verifying the password protection question and answer combination of that level of text password; the dynamic verification code and / or key file of that level are used as supplementary verification methods and can only be generated by reconfiguring the text password of that level, and no separate reset method is set. The login credential modification is used to allow users to independently modify text passwords at all levels after discovering an anomaly. After modification, the dynamic verification code and / or key file at that level, as a supplementary verification method, will become invalid and need to be reconfigured and generated using a new text password. The system has a built-in role-based access control model. Neither the account information table nor the login credential information table contains an administrator reset permission field. The administrator role only has read permissions for the above tables and does not have write, delete, or modify permissions. The application layer disables the API routes related to administrator reset, and the system does not provide account recovery channels other than user self-reset.

11. An anonymous reporting method based on multi-level login credentials, applied to the anonymous reporting system based on multi-level login credentials as described in any one of claims 1-10, characterized in that, Includes the following steps: Step 1: Global Three-Layer Privacy Isolation Processing: When the front-end interactive terminal loads the page, it disables the device fingerprint collection interface and cleans up local persistent data via a script. When the user enters login credentials, it collects human-computer interaction time-series data and uploads it to the back-end server. The reverse proxy middleware is configured to intercept identifiable feature fields such as client IP address and User-Agent in the request header and disable access logs. When receiving a request from the front-end interactive terminal, it removes the client IP address and User-Agent fields from the request header according to the aforementioned configuration and forwards the cleaned request to the back-end server. The back-end server uses a symmetric reversible encryption algorithm to encrypt the contact information before storing it in the database. The encryption key is managed by a hardware security module or key management service independent of the business database. Step 2, Registration Processing: The account registration module of the backend server receives the registration request and generates an anonymous account and multi-level login credentials; the website registration method generates N levels of login credentials, where N≥2, and each level of login credentials includes a required text password and an optional dynamic verification code and / or a key file as a supplementary verification method; the multi-level login credentials generated by SMS registration and email registration methods consist only of a text password; Step 3, Login Verification: The system login module of the backend server receives the login request, first calls the user environment detection module, performs risk assessment based on the human-computer interaction time sequence data collected in Step 1, and verifies multi-level login credentials after the assessment is passed. After all verifications are passed, a temporary session identifier that exists only in memory is generated. This identifier is automatically cleared after the timeout and is not written to the log or persistent storage. The verification of multi-level login credentials supports two modes: step-by-step verification and one-time centralized verification. Step 4, Clue Processing: The reporting service process on the backend server receives reporting clues, performs closed-loop management throughout the entire lifecycle, and after the clues are completed and archived, pushes a reward distribution trigger flag to the reward management service process through a one-way message queue; Step 5, Award Collection: After receiving the trigger flag through a one-way message queue, the reward management service process splits the master key into multiple sub-key shares based on the threshold secret sharing mechanism and distributes them to the executor and collaborators. The executor and collaborators submit the sub-key shares, and after the system verifies them, the master key is restored and the reward is issued.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the anonymous reporting method based on multi-level login credentials as described in claim 11.

Images