This article aims to deeply explore the technical details of the Huawei HarmonyOS Next system (up to API 12 as of now) in developing multilingual e-commerce platforms, and is summarized based on actual development practices. It mainly serves as a vehicle for technical sharing and communication. Mistakes and omissions are inevitable. Colleagues are welcome to put forward valuable opinions and questions so that we can make progress together. This article is original content, and any form of reprint must indicate the source and the original author.
In e-commerce applications, secure payment and password protection are crucial links to ensure the safety of users' funds and the smooth progress of transactions. Based on the HarmonyOS Next system, this article will elaborate on how to construct a secure and reliable payment system for e-commerce applications, covering the whole process from application scenario analysis to preparation for going live.
I. E-commerce Application Scenarios and Security Requirements
(I) Payment Process and Password Protection Requirements
Payment Process
In e-commerce applications, users usually go through the following payment process: select products and add them to the shopping cart, enter the checkout page, select a payment method (such as bank card payment, third-party payment, etc.), then enter the payment password or perform other identity verification operations, and finally complete the payment. The entire payment process needs to ensure the accuracy, integrity, and confidentiality of the data to prevent the payment information from being stolen or tampered with.-
Password Protection Requirements
- High-Strength Password: The payment password should have a relatively high strength, requiring it to contain letters, numbers, special characters, and meet certain length requirements to prevent it from being easily cracked.
- Secure Storage: The payment password must be securely stored in encrypted form on both the device and the server side to ensure that even if the device is attacked or the server data is leaked, the password will not be directly obtained.
- Prevention of Brute-Force Cracking: The application should have a mechanism to prevent brute-force cracking, such as limiting the number of password attempts. After multiple incorrect password entries, the account should be temporarily locked or other security measures should be taken to protect the safety of the users' payment passwords.
(II) Considerations for User Data Security
Protection of User Information
Besides the payment password, e-commerce applications also involve a large amount of user information, such as user names, addresses, contact information, bank card information, etc. These information need to be strictly encrypted during storage and transmission to prevent risks such as fraud caused by the leakage of user information.Security of Transaction Data
Transaction data, including order information, payment amount, product information, etc., also need to ensure their integrity and confidentiality. During transmission, a secure network protocol should be adopted to prevent the data from being tampered with or stolen; during storage, reasonable encryption and backup should be carried out to deal with possible data loss or damage situations.
II. Architecture Planning and Module Division
(I) Layered Architecture Design
Presentation Layer
Responsible for displaying the user interface of the e-commerce application, including product display pages, shopping cart pages, checkout pages, payment pages, etc. On the payment page, provide interface elements such as payment method selection and password input boxes. Use ArkUI components to build a beautiful and easy-to-use interface to guide users to complete the payment operation.Application Layer
Coordinate the execution of business logic and handle users' payment requests. During the payment process, interact with the payment module in the domain layer to verify the legality of the payment information, call the password management module to verify the password, and then communicate with the data layer to send the payment data to the server for processing.Domain Layer
Contains the core business logic of the e-commerce application, such as product management, order processing, payment logic, etc. In terms of password management, it is responsible for password strength verification, formulation of password encryption rules, password verification, and other business logic. The domain layer is independent of specific technical implementations to ensure the stability and extensibility of the business logic.Data Layer
Responsible for data storage and retrieval, interacting with databases, payment servers, etc. Store user information, product information, order information, payment password, etc. When storing the payment password, use a secure encryption algorithm to perform encryption processing to ensure the security of the data. When communicating with the payment server, ensure the security and stability of data transmission.
(II) Responsibilities of Password Management-Related Modules
Password Generation Module
Generate a secure payment password for users according to the set password strength rules. For example, combine the rules of the password autofill service to generate a random password containing uppercase letters, lowercase letters, numbers, and special characters to ensure the complexity and security of the password.Password Verification Module
Responsible for verifying whether the payment password entered by the user is correct. During the verification process, first obtain the encrypted password from the secure storage, then use the corresponding decryption algorithm and verification logic to compare the password entered by the user with the stored password, and return the verification result.Password Storage Module
Use a secure encryption algorithm to encrypt the payment password and store the encrypted password in the local database or securely interact with the server to store the password in the server-side secure storage area. Ensure the confidentiality of the password during storage to prevent it from being illegally obtained.Password Update Module
When the user needs to modify the payment password, be responsible for handling the password update operation. Verify the user's identity (such as by entering the old password or other identity verification methods), and then follow the process of password generation and storage to update the user's payment password.
III. Setting and Management of Payment Passwords
(I) Password Strength Verification and Rule Setting
Password Strength Verification
On the payment password setting page, perform real-time strength verification on the password entered by the user. According to the set rules, check whether the password contains sufficient character types (uppercase letters, lowercase letters, numbers, special characters) and meets the length requirements. For example, require that the password length be at least 8 digits and must contain at least one uppercase letter, one lowercase letter, one number, and one special character. If the password does not meet the strength requirements, display the corresponding prompt information on the interface to guide the user to set a stronger password.Rule Setting
You can flexibly set password rules according to the security requirements of the application and the user experience. For example, allow users to customize password strength requirements, or provide different strength levels of password options for users to choose from. At the same time, refer to the relevant functions of the password autofill service to generate strong password suggestions that meet the rules for users, facilitating users to set secure payment passwords.
(II) Encrypted Storage and Reading of Passwords
- Encrypted Storage Use the secure encryption API of HarmonyOS Next to encrypt and store the payment password. You can use a hash algorithm (such as SHA-256) combined with salting technology to convert the password into an irreversible ciphertext form. When storing the password, store the salt value together with the password hash value to increase the difficulty of password cracking. For example:
import { hash } from '@ohos.security';
async function encryptPaymentPassword(password: string, salt: string): Promise<string> {
const hashedPassword = await hash(password + salt, 'SHA-256');
return hashedPassword;
}
- Reading Password When it is necessary to verify the payment password, read the encrypted password and the salt value from the secure storage. Then use the same hash algorithm and salt value to hash the password entered by the user and compare it with the stored password hash value. If the two match, the password verification is passed. For example:
async function verifyPaymentPassword(inputPassword: string, storedHashedPassword: string, salt: string): Promise<boolean> {
const hashedInputPassword = await hash(inputPassword + salt, 'SHA-256');
return hashedInputPassword === storedHashedPassword;
}
IV. Security Measures during the Payment Process
(I) Security of Communication with the Payment Server
Adoption of a Secure Network Protocol (HTTPS)
When the e-commerce application communicates with the payment server, it must use the HTTPS protocol to ensure the confidentiality and integrity of the data during transmission. The HTTPS protocol encrypts the data through the SSL/TLS encryption layer to prevent the data from being stolen or tampered with in the network. Configure the correct SSL certificate in the application to ensure a secure connection with the server.Data Signing and Verification
Sign the data sent to the payment server to ensure the integrity and authenticity of the data. Use an asymmetric encryption algorithm (such as RSA), where the application end uses the private key to sign the data, and the payment server uses the public key to verify the signature. For example, when sending payment order information, sign the order data. After the payment server receives the data, it verifies the signature. If the signature is invalid, the transaction is rejected to prevent the data from being tampered with during transmission.
(II) Prevention of Data Leakage and Tampering
Input Data Verification
On the payment page, strictly verify all the data entered by the user, including payment amount, bank card number, expiration date, CVV code, etc. Check whether the data format is correct to prevent malicious input or injection attacks. For example, use the Luhn algorithm to verify the validity of the bank card number; verify the range of the payment amount to prevent transactions with abnormal amounts.Prevention of Data Caching and Logging of Sensitive Information
Avoid caching payment-related sensitive data such as payment password and bank card information on the device. At the same time, do not record any sensitive information in the application's log. To prevent user data security problems caused by log leakage. During the development process, review the code to ensure that there are no unexpected storage or recording situations of sensitive data.
V. Integration of the Password Autofill Service (Optional)
(I) Enhancement of User Payment Experience
Convenient Password Input
If the password autofill service is integrated, in the payment password input box, users can choose to use the saved payment password for quick filling, reducing the cumbersome process of manual password input and improving the payment efficiency. Especially when users frequently perform payment operations, it can significantly enhance the user experience.Enhancement of User Memory
For some cases where users may forget the payment password, the password autofill service can provide password hints or automatic filling functions to help users complete the payment smoothly, reducing the trouble of payment failure or password retrieval caused by forgetting the password.
(II) Security Guarantee Measures
Identity Authentication and Authorization
When using the password autofill service, strictly follow the identity authentication mechanism of HarmonyOS Next. Ensure that only authorized users (such as those authenticated through lock screen passwords, fingerprint recognition, facial recognition, etc.) can use the password autofill function to prevent illegal users from obtaining the payment password.Data Encryption Transmission and Storage
Even when using the password autofill service, the payment password remains in an encrypted state during transmission and storage. The password autofill service works closely with the application's password management module to ensure the security of the password during the filling process, preventing the password from being leaked at any stage.
VI. Security Testing and Preparation for Going Live
(I) Simulation of Attack Testing
Password Brute-Force Cracking Testing
Use professional password cracking tools to simulate a brute-force cracking attack on the payment password. Test whether the prevention mechanism of the application is effective, such as whether the limit on the number of password attempts and the account locking function work normally. Ensure that when subjected to a brute-force cracking attack, the application can protect the safety of the users' payment passwords and not be easily cracked.Man-in-the-Middle Attack Testing
By setting up a man-in-the-middle attack environment, simulate an attacker intercepting and tampering with data between the application and the payment server. Check whether the application can detect the man-in-the-middle attack, such as whether the SSL/TLS certificate verification is strict and whether the data signing verification is effective. Ensure the integrity and confidentiality of the data during transmission to prevent the data from being stolen or tampered with by the man-in-the-Middle.SQL Injection and Other Vulnerability Testing
Perform SQL injection testing on the part of the application that interacts with the database to check whether the application has SQL injection vulnerabilities, preventing attackers from obtaining user data or destroying the database through malicious SQL statements. At the same time, perform testing for other common vulnerabilities, such as cross-site scripting attacks (XSS), buffer overflow, etc., to ensure the security of the application.
(II) Performance and Compatibility Testing
Performance Testing
Test the performance of the application during the payment process, including password verification speed, response time of communication with the payment server, interface loading speed, etc. Test under different network environments (such as 4G, 5G, WiFi) and device performance conditions to ensure that the application can provide a smooth payment experience in all cases. Optimize the password encryption algorithm and network communication logic to reduce performance overhead and improve payment efficiency.Compatibility Testing
Perform compatibility testing on different models and different operating system versions of HarmonyOS Next devices to ensure that the payment function of the application works normally, the interface is displayed correctly, and the password management-related functions are free from abnormalities. At the same time, check the compatibility with different payment servers and third-party payment platforms to ensure that the payment process goes smoothly and there are no payment failures or errors caused by compatibility issues.
Through the above comprehensive practical steps, we have constructed a secure payment and password protection system for e-commerce applications based on HarmonyOS Next. During the actual development process, continuously pay attention to the development of security technologies and changes in user requirements, continuously optimize and improve the payment security mechanism to provide users with a safe and convenient e-commerce shopping experience. Before going live, through strict security testing and performance compatibility testing, ensure the quality and security of the application to win the trust of users.
Top comments (0)