🔐 Platform Security Features
The platform is designed with a "security-first" philosophy, building a seven-layer defense-in-depth system covering account, access, data, operations, API, operations & maintenance, and compliance scenarios, comprehensively safeguarding system and user data security.
🛡️ Strong Password Policy for User Accounts
As the first line of defense protecting user accounts, strong passwords are enforced to prevent accounts from being easily compromised due to weak credentials.
Design Philosophy
Following the latest industry standards, the emphasis is on password length over complexity — longer passwords are harder to brute-force and easier for users to remember.
Core Rules
- Minimum Length Requirement: Password length is recommended to be at least 12-16 characters, supporting a mix of Chinese, English, numbers, and special characters
- Real-time Strength Assessment: The system dynamically detects password strength and prohibits common weak passwords such as
password,123456, and known compromised passwords - Password History Check: Users are prohibited from reusing any of their last 5 passwords, preventing password cycling risks
- Expiry & Forced Reset: Supports flexible password expiration configuration, requiring users to change their initial password upon first login
⏱️ Login Failure Rate Limiting / Lockout
Effectively prevents attackers from brute-forcing the login interface using automated tools, increasing the cost of attacks.
Multi-Dimensional Rate Limiting Strategy
- IP-Level Rate Limiting: Limits the login request frequency of individual IP addresses, preventing distributed brute-force attacks
- Account-Level Lockout: After 5 consecutive failed login attempts within 15 minutes, the system automatically locks the account for 30 minutes, with administrator manual unlock support
- Progressive Lockout Strategy: Lockout duration gradually increases with the number of failures, intelligently resisting persistent attacks
Technical Implementation
Uses a Redis-based sliding window rate limiting algorithm, supporting accurate counting in distributed environments and stable rate limiting under high concurrency.
🔑 Multi-Factor Authentication (2FA) Capabilities
Adds a second layer of verification to the login process, greatly reducing the risk of unauthorized account access after credential leaks.
Supported Authentication Methods
TOTP (Time-based One-Time Password)
- Mechanism: Users scan a QR code generated by the platform using authenticator apps such as Google Authenticator or Microsoft Authenticator to bind their account; when logging in, they enter a dynamic verification code that refreshes every 30 seconds
- Advantages: No network dependency, mature and stable, extremely low cost, high security
SMS (Text Message Verification Code)
- Mechanism: The system sends a time-limited 6-digit verification code to the user's bound phone number
- Advantages: High user acceptance, low barrier to entry, suitable for general audiences
Passkey
- Mechanism: Based on the WebAuthn standard, users authenticate using device biometrics (fingerprint, facial recognition) or PIN code, without entering a password
- Advantages: Extremely strong anti-phishing capability, smooth user experience, the future direction of authentication
🌐 API Key IP Whitelist
Allows users to restrict API key usage to specific IP addresses or IP ranges, preventing unauthorized use even if the key is leaked.
Defense Effect
Even if an API Key is accidentally leaked, attackers cannot use it from non-whitelisted IP addresses, fundamentally preventing credential theft and unauthorized access.
Feature Support
- Supports configuring individual IPs, IP ranges, or CIDR format address ranges
- Supports configuration at API Key creation time or at any time after creation
- The system strictly validates the source IP for all API requests, rejecting all requests not in the whitelist
🔒 Admin Panel Strong Permission Validation
Ensures all backend management operations are subject to strict permission controls, preventing unauthorized access and operations.
RBAC Permission Model
Uses the classic RBAC (Role-Based Access Control) model for fine-grained permission management:
- Users: Administrator accounts operating the backend
- Roles: Collections of permissions, such as "Super Admin", "Financial Auditor", "Model Operator"
- Permissions: Atomic operations such as create, read, update, and delete on specific functional modules
Security Validation Principle
Permission validation logic must be enforced at the backend API level and cannot rely solely on frontend interface hiding or disabling. When the frontend calls any interface, the backend must automatically validate whether the current user's role has the corresponding permissions, technically eliminating the possibility of unauthorized operations.
📝 Admin Panel Sensitive Operation Audit Logs
Detailed recording of all sensitive operations in the admin panel, ensuring all critical actions are traceable and meet security audit and compliance requirements.
Recorded Content
Each log entry includes: operation time, operator IP, operator account, operation module, operation type, operation target, operation result, request parameters, and other key information.
Sensitive Operation Scope
Including but not limited to:
- Account & Permissions: Creating/deleting users, modifying role permissions, changing passwords
- Key Management: Creating, deleting, disabling API Keys
- Model Management: Adding, modifying, deleting models or Provider configurations
- Billing & Budget: Modifying model pricing multipliers, adjusting user budgets
Log Security
Audit logs themselves are tamper-proofed and desensitized — for example, plaintext passwords and keys are not recorded — and only authorized auditors can access them.
🔐 Provider Token Security Management
Manages the API Tokens used by the platform to call underlying AI services (such as OpenAI, Anthropic, etc.), ensuring full lifecycle security.
Core Security Principle
Token plaintext is never displayed to users. Users or administrators can only perform operations such as "bind", "revoke", "unbind", and "rotate", and cannot view or copy plaintext tokens through the interface.
Full-Chain Security Protection
- Secure Storage: All Provider Tokens are encrypted and stored in the database using AES-256 strong encryption
- Transport Security: Tokens only interact through backend APIs during transmission, using HTTPS encryption throughout
- Transparent Usage: When business systems request AI services, the platform backend decrypts the Token from the database and adds it to the request headers; the entire process is completely transparent to end users