Skip to main content

Product Security

At Hyletic, we prioritize the security of our products to ensure the protection of our users' data and maintain the integrity of our systems. We implement robust security measures throughout the development and deployment process to mitigate potential risks and vulnerabilities. This document provides an overview of our approach to product security.

Secure Development Practices​

We follow industry best practices for secure software development to minimize the introduction of vulnerabilities during the coding process. Our development team adheres to the following practices:

Code Reviews​

All code changes undergo thorough reviews by multiple team members. This ensures that potential security flaws are identified and addressed before the code is merged into the main codebase.

Secure Coding Guidelines​

Our developers are trained in secure coding principles and follow guidelines that help prevent common vulnerabilities, such as injection attacks, cross-site scripting (XSS), and cross-site request forgery (CSRF).

Vulnerability Testing​

We conduct regular vulnerability testing and penetration testing to identify and address any security weaknesses in our products. This includes both automated scanning tools and manual testing conducted by experienced security professionals.

Data Protection​

Protecting user data is of utmost importance to us. We employ various security measures to ensure the confidentiality, integrity, and availability of user data.

Encryption​

Sensitive user data, such as passwords and personal information, is encrypted both at rest and in transit. We utilize strong encryption algorithms and protocols to protect data from unauthorized access.

Access Control​

Access to user data is strictly controlled based on the principle of least privilege. We implement role-based access control mechanisms to ensure that only authorized personnel have access to sensitive data.

Regular Data Backups​

We perform regular backups of user data to prevent data loss in the event of a system failure or security incident. These backups are securely stored and can be restored if needed.

Incident Response​

Despite our best efforts, security incidents may still occur. In such cases, we have a well-defined incident response plan in place to minimize the impact and quickly restore normal operations. Our incident response process includes:

Incident Identification and Reporting​

We have monitoring systems in place to detect unusual activities or security incidents. Once an incident is identified, it is promptly reported to the appropriate personnel for further investigation and mitigation.

Incident Response Team​

We have a dedicated incident response team consisting of security experts who are responsible for coordinating the response efforts. This team follows a predefined set of procedures to contain the incident, investigate its root cause, and implement remediation measures.

Communication and Disclosure​

In the event of a security incident that may impact our users, we maintain open and transparent communication. We promptly notify affected users and provide them with the necessary information and guidance to protect themselves.

Ongoing Security Assessment​

Ensuring the continuous security of our products is an ongoing process. We regularly assess our systems, conduct security audits, and stay updated with the latest security threats and vulnerabilities. This allows us to proactively address any emerging risks and implement necessary security enhancements.

Types of Security​

Password Security​

The user's password currently only includes the login password of the APP. Pay special attention to passwords:

  • The password is not transmitted in clear text, and the passwords of all users are encrypted by adding salt

  • Restrict user input passwords

  • Check when the user creates the password to remind the user whether the password strength is high enough

In addition, when obtaining user information, we must not open the password to the front end as personal information.

The password modification should be verified, and the verification must be completely completed by the back end, so as to ensure that the password will not be easily tampered with by others to a certain extent.

Communication Security​

  • All communications must be encrypted using HTTPS

    HTTPS can filter out most security problems. HTTPS needs to invest energy in certificate application, server configuration, performance optimization and client configuration, so developers who lack security awareness are easy to skip HTTPS or drag it to a later time to optimize when they encounter problems. Except for the trouble of performance optimization, HTTPS is simpler than expected. If you don't have the energy to optimize performance, at least HTTPS needs to be enabled in the registration and login module. This part of the business has relatively low performance requirements.

  • When using a token, you must bring a token when doing each operation to ensure the security of data transmission

  • When the HTTPS certificate is about to expire, reactivate and configure it half a month in advance

Remote Login​

Record the places where users often log in. Through a certain algorithm, when the user logs in at a strange place, the verification program will be triggered, and the user can log in only after the verification code of the mobile phone or email is correct.

Storage Security​

  • Important data shall not be saved locally, but shall be obtained through the interface as far as possible.
  • If you have to save Important data, you must save it after encryption, and decrypt the data at run time. The locally persistent user data shall be encrypted to ensure that the data can not be viewed directly by opening the app directory. If you want to store some text files and access them in binary form, you can't use the form of text files.
  • The sandbox of app also needs attention. The files in it, such as SQLite, plist, etc., do not save sensitive and key information. If you want to save it, you also need to encrypt it. Note here:
    • The data of the application itself stored in the.app file and the resource files during packaging are all in it. This directory will not be synchronized by iTunes;
    • Documents：store non renewable key data and will not be synchronized by iTunes;
    • Library:save the configuration file and some other files. The' nsuserdefault 'will be stored in the' plist 'file in the' preferences' under the 'Library'. Therefore, do not save some key data in the 'nsuserdefault' or use 'AES' encryption during storage. It will be synchronized by' iTunes';
    • temp：a temporary file. You don't need to manually delete the files in it. This directory will not be synchronized by iTunes.

Code Debugging Security​

For the Flutter project, use debugPrint instead of print. This can ensure that users can't see the printed information log when they plug the release version into the computer.

Otherwise, you can directly view IOS system logs through PP助手、iTools，; You can view the log of Android directly through ADB

Code Security​

  • Isolate the codes of different business modules, such as Flutter, Unity, Backend, PHCM, etc. Specific developers can only access specific projects.

  • For the password in the code, you can not use plain text, but use the encrypted password, which will be automatically decrypted every time you use it.

  • Do a good job of version control, and you can quickly recover the available version in case of any situation

Decompile​

The shelled 'IPA' file we downloaded from AppStore contains many resource packages. Do not store key information in the '. plist' file or static file in the project. If you want to save it, you need to encrypt it. You can use the PP software assistant on the Mac to copy the IPA file to the computer and directly obtain the IOS system directory

Password Security​

  • The password length shall not be less than 6 digits
  • The length of production system password shall not be less than 8 digits.
  • The password shall consist of upper and lower case letters, numbers, special symbols and other characters.
  • For the password in the code, you can not use plaintext, but use the encrypted password, which will be automatically decrypted every time you use it.
  • Passwords should be changed periodically.
  • Regulations on password management

Storage Security​

  • About S3 permission management

    • Divide the management account personnel with (only) S3 authority
    • All barrels shall be divided, and only barrels providing services shall be opened to the outside world
    • Strictly control the reading and writing of barrels

  • About storage on server

    • Minimize the use of server storage as a direct storage medium, especially files

Server Security​

  • The server key must be saved safely, and clear permissions must be set for different servers.

  • It shall have the ability to replace the server key and take good care of the downtime risk caused by the link replacement process.

Database Security​

  • Backup the database regularly

  • Make emergency filing

  • Control the database account.

    • The root user is generally forbidden to log in
    • For a common database, each specific database must have a separate account, and the account should only access the database.
    • If there are multiple accounts in a database, the permissions for adding, deleting, checking and modifying should also be finely controlled