If you discover a security vulnerability, please report it to us as soon as possible. We appreciate your efforts to disclose your findings responsibly. Please email us at [SECURITY_CONTACT_EMAIL_ADDRESS_HERE - you’ll need to replace this] with a detailed description of the vulnerability and steps to reproduce it.We will acknowledge receipt of your vulnerability report promptly and work with you to understand and address the issue. We ask that you do not publicly disclose the vulnerability until we have had a chance to remediate it.
User passwords are never stored in plaintext. We employ a strong, adaptive hashing algorithm to protect user credentials.
Algorithm: We will use argon2id, which is a part of the Argon2 family of algorithms (Argon2id is generally recommended as it provides resistance against both side-channel attacks and GPU cracking attacks).
Salt Generation: A unique, cryptographically secure salt is automatically generated for each user’s password by the argon2 library at the time of account creation or password change. This salt is then stored as part of the resulting hash string.
Parameters: We use appropriate parameters for argon2 (e.g., memory cost, time cost, and parallelism) to ensure that the hashing process is computationally intensive, making brute-force attacks significantly more difficult. These parameters are chosen to balance security with acceptable performance on our servers and may be adjusted based on hardware improvements over time.
Verification: During login, the provided password and the stored salt (extracted from the hash string) are used to re-compute the hash. This newly computed hash is then compared against the stored hash in a constant-time manner (handled by the argon2 library’s verify function) to help prevent timing attacks.
This approach ensures that even if the database were compromised, recovering the original passwords would be computationally infeasible.
Session identifiers are cryptographically random (40 characters) generated using Lucia’s generateId() function and stored in secure, HTTP-only cookies to prevent XSS attacks from accessing them.
Sessions have defined expiration times (30 days from creation) to limit the window of opportunity for session hijacking.
Session data is stored in the authSession table with proper foreign key constraints to the authUser table.
Session cookies are configured with appropriate security attributes:
All incoming data from clients (e.g., API request bodies, URL parameters) is rigorously validated using JSON Schema on the server-side before being processed. This helps prevent common vulnerabilities such as injection attacks and unexpected data handling errors.
Sensitive global application settings (SMTP credentials, API keys, etc.) are encrypted at rest using industry-standard encryption.
Algorithm: AES-256-GCM (Galois/Counter Mode)
Key Derivation: Scrypt with salt for key derivation from environment secret
Authenticated Encryption: Prevents tampering with encrypted data
Unique Initialization Vectors: Each encryption operation uses a unique IV
Environment-Based Key: Encryption key derived from DEPLOYSTACK_ENCRYPTION_SECRET environment variable
Additional Authenticated Data (AAD): Extra security layer to prevent data manipulation
This approach ensures that sensitive configuration data remains secure even if the database is compromised. The encryption system is separate from password hashing to maintain proper separation of concerns.
We strive to keep our dependencies up-to-date and regularly review them for known vulnerabilities. Automated tools may be used to scan for vulnerabilities in our dependency tree.
