Login-free high-sensitivity service security processing method, computer device, medium and product

Abstract

The invention discloses a login-free high-sensitivity service security processing method, a computer device, a medium and a product. The login-free high-sensitivity service security processing method comprises the following steps of: compressing target service data into a short-length byte, performing authentication encryption on the byte and an operation type to obtain a target ciphertext, processing the target ciphertext to obtain a short-chain Token, and issuing touch information containing the short-chain Token; when the short-chain Token is accessed, triggering a front-end script to automatically execute rendering challenge, generating a device associated fingerprint according to the multi-dimensional device information, performing hash processing on the device associated fingerprint, and uploading the device associated fingerprint to a rear end; locking operation is executed on the short-chain Token at the rear end, decryption is carried out after the locking operation is successful, the similarity between the decrypted environment feature prompt and the equipment associated fingerprint is obtained, and a corresponding strategy is executed. According to the method, login and verification codes are not needed, security verification of the high-sensitivity service is completed through the extremely compressed security token and non-intrusive environment perception, and the service processing efficiency and the user experience are effectively improved.

Description

Technical Field

[0001] This disclosure relates to the cross-disciplinary field of computer information security and financial technology, and in particular to a method, computer device, medium, and product for handling highly sensitive business information without login. Background Technology

[0002] In highly sensitive business scenarios such as monthly payment internet insurance, the identity verification process is directly related to user renewal conversion and fund security. Traditional verification, which relies on mobile phone numbers and SMS verification codes, has four inherent limitations: First, the interaction is cumbersome, and frequent logins exacerbate the churn of monthly payment users; second, the SMS URL length is limited, and the token cannot carry enough information; third, the security dimension is singular, and the verification code is easily hijacked and cannot identify the operating environment; fourth, there is a lack of state control, making it vulnerable to replay attacks.

[0003] The existing solution 1, "SMS OTP + Temporary Session" authentication, requires users to click a link and manually enter their mobile phone number and verification code to complete the login. Its shortcomings are obvious: the interaction process is redundant, users frequently switch between applications, the server needs to maintain a large number of suspended sessions, consuming memory and connection resources and increasing concurrency pressure; its security capabilities are weak, only verifying SIM card control, unable to identify abnormal environments, and the verification code and link are easily intercepted and replayed from different locations; its protocol adaptability is poor, and URLs containing session IDs are easily truncated by the gateway or terminal due to exceeding length limits, leading to verification failure.

[0004] The existing solution two, "Ordinary Hash Token Direct Connection Without Login," generates a user token using a hash algorithm and embeds it into a link to achieve login-free access. However, this solution also has drawbacks: the token's length increases after adding security elements, raising the probability of SMS fragmentation and communication costs; it only uses ordinary hashing, lacking authentication and encryption features, resulting in weak tamper resistance and difficulty in identifying forged ciphertext in advance; and it relies solely on cache expiration for state control, lacking a circuit breaker mechanism, making it prone to token reuse under millisecond-level concurrency, thus compromising business idempotency. Summary of the Invention

[0005] In view of this, the present disclosure provides a method, computer device, medium, and product for secure processing of highly sensitive business without login, which can solve the problems that existing solutions cannot meet the high sensitivity and high conversion requirements of monthly insurance business.

[0006] In a first aspect, embodiments of this disclosure provide a method for secure processing of highly sensitive services without requiring login, including: The target business data is compressed to a preset length of bytes; the target business data includes at least the operation type; the preset length of bytes includes at least an environment feature prompt. The preset length bytes and the operation type are subjected to authentication and encryption processing to obtain the target ciphertext; the byte length of the target ciphertext is the preset length. The target ciphertext is converted to obtain a short chain token, and a delivery message containing the short chain token is sent. In response to the signal of accessing the short chain token in the reach information, the front-end script is triggered to automatically execute the rendering challenge, generate a device association fingerprint based on the collected multi-dimensional device characteristic information, and upload the device association fingerprint to the back-end after hash processing; The backend performs a locking operation on the received short chain token. If the locking is successful, the short chain token is decrypted and the decrypted environment feature prompt is extracted. Obtain the similarity between the decrypted environmental feature prompt and the fingerprint associated with the device, and execute the corresponding strategy according to the similarity level.

[0007] Secondly, this disclosure also provides a computer device, which adopts the following technical solution: The computer device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform any of the above-described login-free high-sensitivity service security processing methods.

[0008] Thirdly, embodiments of this disclosure also provide a computer-readable storage medium storing computer instructions; the computer instructions are used to cause a computer to execute any of the above-described login-free high-sensitivity business security processing methods.

[0009] Fourthly, embodiments of this disclosure also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of any of the methods described above.

[0010] The login-free, high-sensitivity business security processing method disclosed in this application first compresses the target business data to a preset length of bytes, and then performs authentication and encryption processing on the preset length of bytes and the operation type to obtain the target ciphertext of the preset length. Through compression and authentication encryption, the token length is ensured to be controllable, effectively avoiding the SMS truncation problem. Then, the target ciphertext is converted to obtain a short-chain token, and a notification message containing the short-chain token is sent. The short chain does not directly expose the plaintext business data and encryption key, reducing the risk of link hijacking and information leakage. In response to the signal of the short-chain token in the access notification message, the front-end script is triggered to automatically execute the rendering challenge. Based on the collected multi-dimensional device characteristic information, a device association fingerprint is generated, and the device association fingerprint is uploaded to the back-end after hash processing. This process is interactive and login-free, with the front-end executing automatically. This system provides seamless security verification, preserving user experience and avoiding the uploading of original device characteristics, thus preventing privacy data leaks and compliance risks. On the backend, the received short-chain token is locked. If locking is successful, the token is decrypted, and the decrypted environment feature hints are extracted, effectively preventing replay attacks and avoiding issues such as repeated business operations, duplicate deductions, and duplicate operations under high concurrency. Finally, the similarity between the decrypted environment feature hints and the device's associated fingerprint is obtained, and corresponding policies are executed based on the similarity level. Legitimate devices / environments are directly embedded into the security credentials, enabling self-verification of credentials without relying on external sessions, user spaces, etc. Policies are dynamically executed based on analysis results, balancing security and user experience, and achieving a closed-loop security process for highly sensitive businesses in login-free mode.

[0011] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating the login-free high-sensitivity service security processing method provided in this embodiment of the disclosure.

[0014] Figure 2 This is a flowchart illustrating a method for compressing target business data to a preset length of bytes, as provided in an embodiment of this disclosure.

[0015] Figure 3 This is a flowchart illustrating the method for obtaining target ciphertext provided in an embodiment of the present disclosure.

[0016] Figure 4 This is a flowchart illustrating the method for converting target ciphertext according to an embodiment of the present disclosure.

[0017] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. Detailed Implementation

[0018] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0019] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0020] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0021] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The drawings only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0022] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0023] Reference Figure 1 This application discloses a method for handling high-sensitivity business security without login, including: S100 compresses the target business data to a preset length of bytes.

[0024] The target business data must include at least the operation type; the preset length bytes must include at least the environment feature prompt.

[0025] S200 performs authentication and encryption processing on the preset length bytes and operation type to obtain the target key.

[0026] The target ciphertext has a preset length in bytes.

[0027] S300 converts the target ciphertext to obtain a short-chain token and sends out a notification containing the short-chain token.

[0028] In this embodiment, the implicit binding of environmental feature prompts enables a strong binding between the token and the access terminal. Even if the connection is intercepted during transmission, attackers cannot use hint collisions on heterogeneous devices in different locations. This feature pre-setting mechanism ensures that the token has physical environment-specific characteristics when it is issued. At the same time, compression and authentication encryption ensure that the token length is controllable, effectively avoiding the problem of SMS truncation.

[0029] Among these features, the token is extremely short, making it suitable for distribution via lightweight channels such as SMS, email, QR codes, and mini-program links. It boasts strong compatibility and a good user experience. The short chain does not directly expose plaintext business data and encryption keys, reducing the risk of link hijacking and information leakage. At the same time, the delivery information (SMS / in-site messages, etc.) is bound to the user's frequently used channels, naturally possessing identity verification attributes, increasing the difficulty of unauthorized acquisition.

[0030] S400, in response to the signal of the short-chain token in the access information, triggers the front-end script to automatically execute the rendering challenge, generates a device-associated fingerprint based on the collected multi-dimensional device characteristic information, and uploads the device-associated fingerprint to the back-end after hash processing.

[0031] Among these, the device-associated fingerprint is the physical device fingerprint, which can be uploaded to the backend after being processed by asymmetric encryption or salted hashing. In this step, it is preferable to run in an H5 container to obtain multi-dimensional fingerprints through rendering challenges (Canvas / WebGL) and hardware attributes. That is, fingerprints are collected silently in the H5 environment using rendering challenges. The frontend automatically collects device fingerprints without requiring manual input from the user, effectively improving the user experience.

[0032] This step is interactive and login-free, requiring users not to enter account passwords or verification codes, significantly improving the convenience and conversion rate of highly sensitive businesses; the front end executes automatically, with seamless security verification that does not disrupt the user experience; at the same time, multi-dimensional device characteristics are more difficult to forge, tamper with, or transfer than single cookies / sessions, significantly improving device uniqueness and anti-counterfeiting capabilities, and the device fingerprint is strongly bound to the user device, achieving a "device + credential" dual binding, so even if the token is leaked, it is difficult for other people's devices to pass the verification.

[0033] S500 performs a locking operation on the received short chain token in the backend. If the locking is successful, the short chain token is decrypted and the decrypted environment feature prompt is extracted.

[0034] In this step, the backend locking mechanism can effectively prevent concurrent replay attacks, and device fingerprint comparison increases environmental awareness and improves security.

[0035] By locking the short chain token on the backend, replay attacks are effectively prevented. That is, when the same short chain is requested multiple times concurrently, only one valid processing is allowed. At the same time, race conditions are effectively prevented, avoiding problems such as repeated execution of business, repeated deductions, and repeated operations under high concurrency. This ensures that the short chain takes effect only once, guaranteeing the idempotency and security of highly sensitive business operations.

[0036] S600 obtains the similarity between the decrypted environmental feature prompt and the device-associated fingerprint, and executes the corresponding policy according to the similarity level.

[0037] This step supports tiered handling, balancing security and user experience. Without requiring user account and password logins or complex interactive verification, this method ensures the confidentiality, integrity, and authenticity of business data through mechanisms such as data compression, authentication encryption, short chain encapsulation, and token locking, effectively resisting replay, tampering, forgery, and theft attacks. Furthermore, it achieves strong binding between devices and the access environment through multi-dimensional device fingerprint collection, hash privacy processing, and similarity-based tiered verification, balancing privacy compliance and anti-forgery capabilities. It also boasts advantages such as high processing efficiency, adaptability to lightweight distribution channels, flexible and adjustable risk control, and low system invasiveness, significantly improving the convenience of high-sensitivity business operations and user experience. It is suitable for the secure implementation of various login-free, high-sensitivity business scenarios.

[0038] Salted hashing is preferably performed using random salt hashing. This means that before hashing the original data (such as a password), a randomly generated string of a specific length (i.e., the salt) is appended to it, and then the hash operation is performed on the concatenated string. The salt is a cryptographically secure random number and cannot be predictable information such as user IDs or usernames. Each user and each record uniquely corresponds to a different salt.

[0039] Reference Figure 2 The method for S100 "compressing target business data to a preset length of bytes" specifically includes: S110: Retrieve the target business data corresponding to the user from the business database.

[0040] The target business data also includes a user unique identifier field, a policy identifier field, a timestamp field, a user's historical trusted devices, and a verification field.

[0041] S120 compresses the target business data to a preset length of bytes on the server side.

[0042] This step specifically includes: hashing the user's unique identifier field and taking the low-order bits, mapping it to a byte of the first length; compressing the policy identifier field and mapping it to a byte of the second length; obtaining the offset of the current timestamp field relative to the business origin and mapping it to a byte of the third length; mapping the operation type field to a byte of the fourth length, such as 0x01 for monthly payment confirmation and 0x02 for information change. Extracting the fingerprint hash of the user's historical trusted device and taking its first N bits as an environment feature hint, which is a byte of the fifth length; specifically, the fingerprint hash of the user's historical trusted device can be extracted, and its first 16 bits (i.e., 2 bytes) can be embedded in plaintext as a Device Hint. Mapping the verification field to a byte of the sixth length, the sum of the first, second, third, fourth, fifth, and sixth lengths is the preset length.

[0043] The extraction of fingerprint hashes from a user's historical trusted devices specifically includes: obtaining devices that the user has previously authenticated and marked as secure (such as their own mobile phone or computer); generating a unique or highly distinguishable hash value (e.g., a SHA-256 string) by collecting device hardware and software characteristics (such as screen size, font, browser plugins, hardware ID, etc.); and finally, truncating the first 16 bits of the complete fingerprint hash (e.g., a1b2c3d4e5f67890). This step reduces the static characteristics of historical trusted devices to 16 bits using perceptual hashing, allowing for a certain degree of device changes (e.g., minor system updates) to still be considered the same environment, thus improving the user experience.

[0044] The preset length is preferably 12-14 bytes. In one specific embodiment, the first length, second length, third length, fourth length, fifth length, and sixth length are 3 bytes, 3 bytes, 2 bytes, 1 byte, 2 bytes, and 1 byte, respectively, so the preset length is 12 bytes. Specifically, the user's unique identifier is hashed (using common hash algorithms such as MD5 or SHA-256) to obtain a hash value of a fixed length. For example, SHA-256 outputs a 32-byte hash value. The lower 3 bytes (i.e., the last 3 bytes) of the hash value are truncated as the mapping result of the field. For example, if the user's unique identifier is "13800138000", the byte array obtained after hashing is [0x12, 0x34, 0x56, 0x78, 0x90, 0xAB, ..., 0xEF, 0xCD]. The last 3 bytes are taken as [0x90, 0xAB, 0xCD], that is, the mapping result of the field is 3 bytes of 0x90ABCD.

[0045] The policy identifier is standardized, such as removing non-numeric / alphanumeric characters and unifying uppercase and lowercase letters; it is mapped to 3-byte data using hashing (a hash algorithm with the same unique user identifier) ​​or numerical compression (if the policy number is purely numeric, it can be converted to an integer and the lower 24 bits, i.e., 3 bytes, are taken); if the value of the policy identifier after conversion exceeds the range of 3 bytes (0~0xFFFFFF), the result is ensured to be 3 bytes by modulo (modulo 0x1000000) or hash truncation. Example: The policy number "P202603030001" is standardized to "202603030001", which is converted to an integer to 202603030001. Taking the lower 24 bits (i.e., modulo 0x1000000) yields 0x123456, corresponding to 3 bytes [0x12, 0x34, 0x56].

[0046] The mapping process for the offset of the current timestamp field relative to the business origin includes: determining the business origin time (e.g., 2026-01-01 00:00:00, corresponding to the Unix timestamp 1740921600); calculating the offset between the current timestamp and the business origin (offset = current timestamp - business origin timestamp); converting the offset to a 2-byte unsigned integer (range 0~0xFFFF, i.e., the maximum offset is 65535 seconds, approximately 18.2 hours); if the offset exceeds the 2-byte range, it can be moduloed (modulo 0x10000) or truncated according to business rules to ensure the result is 2 bytes. Example: The current timestamp is 1740928800, the business origin is 1740921600, the offset = 7200 seconds (2 hours), which is converted to 2 bytes as 0x1C20 (corresponding to decimal 7200), i.e., the mapping result is [0x1C, 0x20].

[0047] The mapping process for operation type fields includes: a predefined mapping table between operation types and 1-byte hexadecimal values, such as monthly payment confirmation → 0x01, information change → 0x02, policy cancellation → 0x03, payment failure → 0x04, etc. Other operation types are mapped to 0x05~0xFF in sequence; based on the actual operation type, the corresponding 1-byte value is directly taken as the mapping result.

[0048] The acquisition of the environment feature prompt specifically includes: extracting the fingerprints of all the user's historical trusted devices, performing a hash calculation on each fingerprint (e.g., SHA-256); selecting the primary trusted device, such as the fingerprint hash value of the user's most recently used device, and extracting its first 2 bytes (16 bits) as the environment feature prompt; if the user has no historical trusted devices, it is filled with 0x0000 by default. Example: The fingerprint hash of the user's primary trusted device is [0xAA, 0xBB, 0xCC, 0xDD, ...], and the first 2 bytes are [0xAA, 0xBB], that is, the mapping result is 0xAABB.

[0049] The mapping method for the verification field specifically includes: performing verification calculations on the first 11 bytes of data, such as summation verification, XOR verification, CRC8 verification, etc., and converting the verification result into a 1-byte value as the verification field.

[0050] Example: The first 11 bytes are [0x90, 0xAB, 0xCD, 0x12, 0x34, 0x56, 0x1C, 0x20, 0x01, 0xAA, 0xBB]. Using a summation check, all bytes are added together and the lower 8 bits are taken: 0x90+0xAB+0xCD+0x12+0x34+0x56+0x1C+0x20+0x01+0xAA+0xBB = 0x506. Taking the lower 8 bits is 0x06, that is, the check field is 0x06.

[0051] Finally, the mapping results of the above 6 fields are concatenated in order to obtain 12 bytes of final business data, balancing data compression and retention of core information.

[0052] Reference Figure 3 The method of S200, which involves "authenticating and encrypting bytes of a preset length and operation type to obtain the target ciphertext," specifically includes the following: S210, obtain the first subkey and the second subkey according to the preset master key.

[0053] In this embodiment, the preset master key K is preferably a 256-bit master key K; specifically, two 128-bit subkeys K1 (i.e., the first subkey) and K2 (i.e., the second subkey) are derived from the 256-bit master key K. K1 is used for CMAC authentication (i.e., for message authentication code calculation), and K2 is used for CTR encryption (i.e., for counter mode encryption).

[0054] This step enables key separation, using different subkeys for authentication and encryption functions, effectively improving security (even if one part is compromised, the other part remains secure), while ensuring that K1 and K2 remain consistent each time the same K is used for encryption.

[0055] S220: Use the preset length bytes as plaintext and the operation type as associated data; perform CMAC operations on the associated data and plaintext based on the first subkey to obtain the first authentication value and the second authentication value.

[0056] In this embodiment, it is preferable to use 12 bytes as plaintext (P) and operation type (1 byte) as associated data (AD). Calculate the CMAC (i.e., the first authentication value) of the associated data: T1 = CMAC(K1, AD), and output 16 bytes; calculate the CMAC (i.e., the second authentication value) of the plaintext: T2 = CMAC(K1, P), and output 16 bytes.

[0057] S230: Perform a bitwise XOR operation on the first authentication value and the second authentication value to obtain the composite vector.

[0058] This step combines the fingerprints of the plaintext and associated data into a unique SIV (Synthetic Vector). Any tampering with P or AD will change the SIV; the same (P, AD) always produces the same SIV, facilitating verification and deduplication. Furthermore, this step eliminates the need for random numbers, effectively avoiding the management and transmission overhead of random IVs.

[0059] S240 generates a key stream sequence based on the synthesis vector, the second subkey, and the AES-CTR algorithm.

[0060] S250, take the first preset length bytes from the key stream sequence as the encryption key stream.

[0061] S260, perform a bitwise XOR operation between the encryption key stream and the plaintext to obtain ciphertext of a preset length of bytes.

[0062] Specifically, SIV is used as the initial counter in CTR mode. During the AES-CTR algorithm, the second subkey K2 is used for encryption to generate a keystream sequence. Since the plaintext is only 12 bytes, only the first 12 bytes of the keystream sequence are needed as the encryption keystream; the ciphertext is C: C = P ⊕ Keystream, i.e., a bitwise XOR operation, outputting 12 bytes.

[0063] This embodiment can select the output format based on transmission constraints (complete output ensures decryptability, while simplified output saves space). If the SIV is transmitted, its integrity can be verified during decryption; if not transmitted, the receiver needs to know the SIV (e.g., deduce it from the context) to still guarantee encryption strength. By using the business operation type as associated data in the authentication calculation, extreme compression of the token length (Base58 encoded characters) can be achieved without sacrificing financial-grade security, effectively solving the link failure problem caused by SMS protocol truncation.

[0064] Reference Figure 4 The method of S300, which "transforms the target ciphertext to obtain a short-chain token and sends out outreach information containing the short-chain token," specifically includes the target ciphertext transformation method: S310 converts the target ciphertext based on Base58 to obtain a short-chain token.

[0065] In this step, Base58 is used to map the target ciphertext because the Base58 character set does not include obfuscating characters such as 0, O, I, and l, thus avoiding visual confusion and reducing input errors. Base58 encoding can convert binary data of any length (such as encrypted ciphertext) into shorter strings, effectively compressing the length.

[0066] Specifically, the target ciphertext (binary data) is processed byte by byte and converted into a large integer; it is then repeatedly divided by 58, and the remainders are mapped to the Base58 character set to obtain the reversed character sequence; the sequence is then reversed to obtain the Base58 encoded string, which is concise, efficient, and less prone to errors during subsequent transmission.

[0067] S320 sends out a notification message containing a short-chain token through a preset message channel.

[0068] The preset message channels can be SMS, templates, etc., which are common and have wide coverage. For example, with SMS, the token can be concatenated into a complete short URL (e.g., https: / / example.com / token) and then sent to the user. If using a template, the token can be populated as a variable in the template and then sent through the appropriate channel. Short tokens can greatly reduce message length and save costs (e.g., SMS is billed per message); short links are easy to click and share, providing a better user experience.

[0069] For S400, the goal is to proactively probe device capabilities through rendering challenges, rather than passively collecting information, thereby obtaining deeper and more difficult-to-forge device characteristics. When a user clicks the short link to enter the H5 page, the front-end script automatically executes the rendering challenge, collecting multi-dimensional information to generate a stable, unique, and distinguishable comprehensive fingerprint of device, environment, and behavior, used to differentiate between a real user's browser and automated tools / emulators / virtual machines.

[0070] Specifically, the method in S400 that "in response to a signal from a short-chain token in the access information, triggers the front-end script to automatically execute a rendering challenge and generate a device-associated fingerprint based on the device's hardware and software characteristics" includes: A100, in response to a signal from a short-chain token in the access information, performs the first rendering challenge in a hidden off-screen rendering container, draws a preset geometry and reads its pixel data, and generates rendering challenge features.

[0071] When a user accesses a notification containing a short-link token, the front-end script automatically parses the token parameter in the URL, using it as a trigger signal to initiate the device fingerprint generation process. First, a hidden off-screen rendering container is initialized. This container is set to an invisible state (outside the page's visible area, transparent) to handle all subsequent rendering challenge operations, avoiding interference with the user's normal browsing experience. It also provides a unified execution environment for the three rendering challenges, ensuring the stability of feature collection.

[0072] Specifically, the core of the first rendering challenge is to leverage the differences in Canvas rendering across different devices to extract device-specific rendering features. Within a hidden off-screen container, Canvas elements are dynamically created with fixed sizes. A 2D rendering context is obtained, and pre-defined geometric shapes are drawn, including circles, polygons, and text in specific fonts. Complex colors and line styles are configured to amplify the rendering differences between devices (such as different graphics cards and browser rendering engines). After the graphics are drawn, the complete pixel data of the Canvas is read, and statistical analysis is performed on the pixel information, rather than storing all pixel data (to reduce resource consumption): the average RGB and transparency of the pixels are calculated, the number of unique pixel values ​​is counted, and whether the device has Canvas anti-aliasing enabled (anti-aliasing settings are a significant difference in device rendering characteristics) is detected. These statistical data are then hashed to generate standardized rendering challenge features.

[0073] This step involves the extremely small, detectable differences at the pixel level that occur when the GPU (or CPU's software renderer) renders the same graphics instruction. These differences are caused by subtle hardware-level variations (such as transistor-level tolerances and minor differences in anti-aliasing algorithm implementations) and variations in the driver layer and the version and configuration of the operating system's rendering stack. These differences can reflect the soft physical characteristics exhibited by the combination of hardware and software.

[0074] A200 calls the WebGL interface to perform the second rendering challenge, obtains the renderer description string of the graphics processor, and generates audio response features.

[0075] This step reflects hardware response characteristics. Specifically, the second rendering challenge extracts the underlying hardware characteristics of the graphics processing unit (GPU) by calling the WebGL interface, i.e., extracting GPU-related characteristics as an important component of the device fingerprint. Similarly, a WebGL canvas is created in a hidden off-screen container to obtain the WebGL context (compatible with WebGL1, WebGL2, and various browser versions). Core GPU hardware information is extracted, including renderer description strings (such as GPU model and related configurations), GPU manufacturer, WebGL version, shader version, maximum texture size, maximum render buffer size, and the number of WebGL extensions supported by the device. Simultaneously, differences in GPU precision settings are detected. These GPU characteristics are integrated and hashed to generate standardized feature data, i.e., audio response characteristics (essentially GPU hardware characteristics).

[0076] The A300 initializes the audio context and executes the third rendering challenge, sampling the amplitude-frequency response of the audio processing nodes to generate hardware topology features.

[0077] The purpose of this step is to generate hardware configuration parameters. Specifically, the third rendering challenge initializes the audio context, samples the amplitude and frequency response of the audio processing nodes, extracts the topological features of the device's audio hardware, and leverages the performance differences of different device audio hardware (such as sound cards and audio decoders) to generate unique features. First, the audio context is initialized to ensure compatibility with API differences across browsers and to handle browser user interaction limitations—if no user interaction is triggered, silent initialization or listening for minor user interactions (such as clicks) can be attempted to ensure the audio context starts normally and that no sound is output to the speakers to avoid interfering with the user. After the audio context initialization is complete, a simplified audio processing chain is constructed, including an oscillator, gain node, filter node, and analysis node. A swept-frequency sine wave test signal (from 20Hz to 20kHz, quickly covering the audible frequency range) is configured and transmitted through the audio processing chain. The analysis node samples the frequency response data. Subsequently, statistical analysis is performed on the sampled data to calculate the average amplitude, peak frequency, and peak amplitude. Simultaneously, hardware parameters such as the audio context's sampling rate and base latency are recorded. This data is then hashed to generate hardware topological features.

[0078] A400 obtains device-associated fingerprints based on rendering challenge features, audio response features, and hardware topology features.

[0079] After three rendering challenges are completed, all generated features (rendering challenge features, audio response features, and hardware topology features) are collected. The feature set is standardized to filter invalid information and error records, and sorted in a fixed order (ensuring that the feature strings generated by the same device are consistent each time). The sorted feature set is then converted into a string. An encrypted hash algorithm (SHA-256 is preferred for security; if the device does not support it, MD5 is used as a fallback) is used to process the feature string to generate a fixed-length, unique hash value, which is the device-associated fingerprint.

[0080] This embodiment employs a multi-dimensional feature fusion model, covering three core layers: device rendering (Canvas), GPU hardware (WebGL), and audio hardware (Web Audio). These features are based on the inherent differences in the underlying hardware and software of the device, and are not software configurations that can be arbitrarily modified, making them difficult to simulate or tamper with through software. Simultaneously, features are solidified through a hash algorithm. Even if some features are maliciously modified, the final generated device fingerprint will change significantly, effectively identifying tampering and ensuring the uniqueness and stability of the fingerprint. Fingerprints generated by the same device at different times and in different scenarios remain consistent.

[0081] All rendering challenges are performed within a hidden off-screen container, detached from the page's visible area. Users are unaware of any rendering operations, ensuring a seamless browsing experience. Simultaneously, the audio challenges do not output sound to speakers, preventing noise interference. The entire process is automatically triggered by a short-chain token, eliminating manual user intervention and reducing user resistance, thus enhancing the solution's usability. The solution only collects the device's underlying hardware and software characteristics, without acquiring any user privacy data (such as cookies, local files, or personal information), complying with current privacy protection standards and avoiding privacy leaks. Furthermore, the characteristic data is processed using a hash algorithm before being uploaded to the backend. Even if intercepted during transmission, the original characteristic information cannot be reverse-engineered, improving data transmission security. This hardware-based characteristic collection method makes it difficult to forge device fingerprints using emulators, virtual machines, or other tools, providing strong anti-cheating capabilities and effectively preventing malicious device simulation.

[0082] This embodiment automatically executes a series of graphics, audio, and hardware capability challenges through a front-end script without the user's awareness. It collects tamper-proof or difficult-to-forge device characteristics from multiple levels, including the underlying hardware, driver layer, and browser engine, constructing a high-precision, simulation-resistant device fingerprint. Attackers find it difficult to simultaneously and accurately forge all dimensions of characteristics. These characteristics are mostly tightly bound to hardware or drivers and are relatively stable throughout the device's lifecycle (unlike IP addresses, which change frequently). The entire process is completed automatically and silently in an H5 environment through a script, without the user's awareness and without requiring additional permissions.

[0083] The S600 method of "obtaining the similarity between the decrypted environmental feature prompt and the device-associated fingerprint, and executing the corresponding strategy according to the similarity level" includes: S610, obtain the Jaccard similarity coefficient between the decrypted environmental feature prompt and the device-associated fingerprint.

[0084] The Jaccard similarity coefficient is: , Associate fingerprint with device This is the decrypted environment feature prompt.

[0085] S620, when the Jaccard similarity coefficient meets the first preset range, execute the instruction for the short chain token.

[0086] In a preferred embodiment, when the similarity coefficient of Jaccard is ≥90%, the instructions of the short chain token are executed directly, such as issuing a renewal success page.

[0087] S630, when the Jaccard similarity coefficient meets the second preset range, reject the instruction for short-chain tokens and generate a lightweight verification window.

[0088] In a preferred embodiment, if the similarity coefficient is 70% ≤ Jaccard similarity < 90% (e.g., the user has changed devices), the system will automatically pop up a lightweight verification window asking for the last four digits of the policyholder's ID card, without requiring a verification code, and will reject the current short chain token instruction.

[0089] S640, when the Jaccard similarity coefficient meets the third preset range, a forced login page will automatically pop up.

[0090] In a preferred embodiment, when the Jaccard similarity coefficient is less than 70%, a forced login page is automatically displayed.

[0091] This embodiment uses an environmental feature similarity grading strategy to trigger circuit breakers (such as interception and secondary verification) in real time, replacing passive protection that relies solely on cache expiration.

[0092] Furthermore, this application also includes the following: upon receiving the short-chain token, the backend immediately executes `UPDATEState=Locked WHERE Token=H(T) AND State=Active` in the shadow table. If the number of affected rows is 0, it is considered an illegal replay and the circuit breaker is triggered immediately. After successful business processing, the shadow table status is updated to Used, and the newly collected device fingerprint is recorded as a reference for the evolution of next month's payment.

[0093] The method disclosed in this embodiment eliminates proactive interactions such as SMS verification codes in high-frequency scenarios like monthly insurance payments, effectively reducing renewal churn by approximately 15%-25%. This solution replaces the repeated collection of sensitive personal privacy information (phone number) with implicit awareness of device characteristics, aligning with the principle of minimizing data utilization in the fintech field.

[0094] This application utilizes a front-end script to automatically collect multi-dimensional device characteristics (such as screen resolution, browser fingerprint, hardware information, etc.), generate a device-associated fingerprint, and upload it via hash. This ensures that each access is strongly linked to the terminal's physical environment. Even if an attacker intercepts an SMS link, they cannot simulate the original device fingerprint. The system can identify abnormal environments through similarity comparison, blocking unauthorized operations and effectively preventing attacks from remote / heterogeneous devices. Employing Authentication and Encryption (AEAD) technology (such as AES-GCM), it ensures that the ciphertext (short-chain token) cannot be tampered with during transmission (bit-flip attacks are ineffective), and verifies integrity upon decryption. While guaranteeing extremely high security, it achieves a seamless user experience, minimizes communication costs, and lightens server load, making it particularly suitable for high-sensitivity, high-frequency business scenarios such as insurance payments and financial authorizations.

[0095] A computer device according to embodiments of the present disclosure includes a memory and a processor. The memory is used to store non-transitory computer-readable instructions. Specifically, the memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, flash memory, etc.

[0096] The processor may be a central processing unit (CPU) or other processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the computer device to perform desired functions. In one embodiment of this disclosure, the processor is used to execute computer-readable instructions stored in the memory, causing the computer device to perform all or part of the steps of the login-free high-sensitivity business security processing method described in the foregoing embodiments of this disclosure.

[0097] Those skilled in the art will understand that, in order to solve the technical problem of how to achieve a good user experience, this embodiment may also include well-known structures such as communication buses and interfaces, and these well-known structures should also be included within the protection scope of this disclosure.

[0098] like Figure 5 This is a schematic diagram of a computer device provided for an embodiment of the present disclosure. It illustrates a structural schematic diagram suitable for implementing the computer device in the embodiments of the present disclosure. Figure 5 The computer device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0099] like Figure 5 As shown, a computer device may include a processor (such as a central processing unit, graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) or programs loaded from storage devices into random access memory (RAM). The RAM also stores various programs and data required for the operation of the computer device. The processor, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0100] Typically, the following devices can be connected to the I / O interface: input devices, such as sensors or visual information acquisition devices; output devices, such as displays; storage devices, such as magnetic tapes or hard drives; and communication devices. Communication devices allow the computer device to communicate wirelessly or wiredly with other devices (such as edge computing devices) to exchange data. Although Figure 5A computer apparatus with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or included alternatively.

[0101] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processor, all or part of the steps of the login-free high-sensitivity business security processing method of embodiments of this disclosure are performed.

[0102] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0103] A computer-readable storage medium according to embodiments of the present disclosure stores non-transitory computer-readable instructions. When the non-transitory computer-readable instructions are executed by a processor, all or part of the steps of the login-free high-sensitivity service security processing method described in the foregoing embodiments of the present disclosure are performed.

[0104] The aforementioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or portable hard drive), media with built-in rewritable non-volatile memory (e.g., memory card), and media with built-in ROM (e.g., ROM cartridge).

[0105] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0106] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0107] In this disclosure, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, devices, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0108] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0109] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0110] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0111] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0112] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A method for secure handling of highly sensitive business processes without requiring login, characterized in that, include: Compress the target business data to a preset length of bytes; The target business data includes at least the operation type; the preset length bytes include at least the environment feature prompt. The preset length bytes and the operation type are subjected to authentication and encryption processing to obtain the target ciphertext; the byte length of the target ciphertext is the preset length. The target ciphertext is converted to obtain a short chain token, and a delivery message containing the short chain token is sent. In response to the signal of accessing the short chain token in the reach information, the front-end script is triggered to automatically execute the rendering challenge, generate a device association fingerprint based on the collected multi-dimensional device characteristic information, and upload the device association fingerprint to the back-end after hash processing; The backend performs a locking operation on the received short chain token. If the locking is successful, the short chain token is decrypted and the decrypted environment feature prompt is extracted. Obtain the similarity between the decrypted environmental feature prompt and the fingerprint associated with the device, and execute the corresponding strategy according to the similarity level.

2. The method for handling high-sensitivity services without login as described in claim 1, characterized in that, The step of compressing the target business data to a preset length of bytes includes: Retrieve the target business data corresponding to the user from the business database; the target business data also includes a user unique identifier field, a policy identifier field, a timestamp field, the user's historical trusted devices, and a verification field; On the server side, the target business data is compressed to a preset length of bytes.

3. The method for handling high-sensitivity services without login as described in claim 2, characterized in that, The step of compressing the target business data to a preset length of bytes on the server side includes: The user unique identifier field is hashed and the low-order bits are taken and mapped to bytes of the first length; The policy identifier field is compressed and mapped to bytes of a second length; Obtain the offset of the current timestamp field relative to the business origin and map it to bytes of the third length; Map the operation type field to bytes of a fourth length; Extract the fingerprint hash of the user's historical trusted device, and take its first N bits as the environment feature prompt, wherein the environment feature prompt is a fifth byte in length; Map the verification field to bytes of the sixth length; The sum of the first length, the second length, the third length, the fourth length, the fifth length, and the sixth length is the preset length.

4. The method for handling high-sensitivity services without login as described in claim 1, characterized in that, The step of performing authentication and encryption processing on the preset length bytes and the operation type to obtain the target ciphertext includes: Obtain the first subkey and the second subkey based on the preset master key; The preset length bytes are used as plaintext, and the operation type is used as associated data; Based on the first subkey, CMAC operations are performed on the associated data and the plaintext respectively to obtain the first authentication value and the second authentication value; Perform a bitwise XOR operation on the first authentication value and the second authentication value to obtain a composite vector; Based on the synthesis vector and the second subkey, a key stream sequence is generated; Take the first preset length bytes from the key stream sequence as the encryption key stream; Perform a bitwise XOR operation between the encryption key stream and the plaintext to obtain ciphertext of a preset length in bytes.

5. The method for handling high-sensitivity services without login as described in claim 1, characterized in that, The process of converting the target ciphertext to obtain a short-chain token and sending out outreach information containing the short-chain token includes: The target ciphertext is converted based on Base58 to obtain a short-chain token; The system sends out a notification message containing the short-chain token through a pre-defined message channel.

6. The method for handling high-sensitivity services without login as described in claim 1, characterized in that, The signal in response to accessing the short-chain token in the reach information triggers the front-end script to automatically execute a rendering challenge, generating a device-associated fingerprint based on the device's hardware and software characteristics, including: In response to a signal to access the short-chain token in the access information, a first rendering challenge is performed in a hidden off-screen rendering container, a preset geometry is drawn and its pixel data is read, and rendering challenge features are generated. Call the WebGL interface to perform the second rendering challenge, obtain the renderer description string of the graphics processor, and generate audio response features; Initialize the audio context and execute the third rendering challenge, sample the amplitude frequency response of the audio processing node, and generate hardware topology features; Based on the rendering challenge features, the audio response features, and the hardware topology features, a device-associated fingerprint is obtained.

7. The method for handling high-sensitivity services without login as described in claim 1, characterized in that, The step of obtaining the similarity between the decrypted environmental feature prompt and the device-associated fingerprint, and executing a corresponding strategy based on the similarity level, includes: Obtain the Jaccard similarity coefficient between the decrypted environmental feature prompt and the fingerprint associated with the device; When the Jaccard similarity coefficient meets the first preset range, the instruction of the short chain token is executed; When the Jaccard similarity coefficient meets the second preset range, the instruction to reject the short chain token is rejected, and a lightweight verification window is generated; When the Jaccard similarity coefficient meets the third preset range, a forced login page will automatically pop up.

8. A computer device, characterized in that, The computer device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the login-free high-sensitivity service security processing method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions; the computer instructions are used to cause the computer to execute the login-free high-sensitivity business security processing method as described in any one of claims 1-7.

10. A computer program product comprising computer instructions, characterized in that, When executed by a processor, the computer instructions implement the steps of the method according to any one of claims 1-7.

Images