We release patches for security vulnerabilities in the current major version of Hakanai. We recommend all users to upgrade to the latest version as soon as possible after a security release.
We take the security of Hakanai seriously. If you believe you have found a security vulnerability, please report it to us as described below.
- Open a public GitHub issue
- Post about it on social media
- Exploit the vulnerability beyond necessary verification
- Go to the Security tab in our repository
- Click "Report a vulnerability"
- Fill out the private security advisory form
- This creates a private discussion that only maintainers can see
- Contact the maintainer @czerwonk directly through GitHub
- Include "SECURITY" in your message title
- PGP key available at https://github.com/czerwonk.keys for encrypted communication
- Affected version(s)
- Steps to reproduce the issue
- Potential impact
- Suggested fix (if available)
- Initial Response: Within 48 hours
- Status Update: Within 7 days
- Resolution Timeline: Typically within 30 days for critical issues
- We will confirm receipt and begin investigation
- We will work to verify and reproduce the issue
- We will prepare a fix and coordinate disclosure
- We will credit you in the security advisory (unless you prefer to remain anonymous)
Hakanai implements a zero-knowledge architecture where:
- All encryption/decryption happens client-side
- Server never has access to plaintext data or encryption keys
- Secrets are automatically deleted after first access
- Mandatory content integrity verification via SHA-256 hashes
- Algorithm: AES-256-GCM (authenticated encryption)
- Key Generation: Cryptographically secure random generation
- Nonce: Unique per encryption operation
- Hash Verification: SHA-256 truncated to 128 bits (tradeoff between security and URL practicality)
- 128-bit truncation provides 2^64 collision resistance
- Balances strong tamper detection with manageable URL length and QR code scannability
- TLS/HTTPS: Must be terminated at reverse proxy
- Rate Limiting: Implement at reverse proxy level
- DDoS Protection: Use appropriate infrastructure protection
- Firewall Rules: Restrict Redis access to application only
- Authentication: Token-based with SHA-256 hashing
- Input Validation: UUID format validation, size limits
- CORS Policy: Restrictive by default
- Security Headers: X-Frame-Options, X-Content-Type-Options, HSTS
- Memory Safety: Sensitive data zeroized after use
- Always run behind a reverse proxy with TLS
- Configure rate limiting based on your usage patterns
- Regularly update to the latest version
- Monitor logs for suspicious activity
- Restrict Redis network access
- Use strong admin tokens (if admin API enabled)
- Set appropriate size limits for your use case
- Use the
--separate-keyoption for highly sensitive data - Share URLs and keys through different communication channels
- Verify the HTTPS certificate before entering secrets
- Use appropriate TTL values (shorter is more secure)
- Never share secret URLs in public forums or logs
- Server compromise (zero-knowledge architecture)
- Data persistence (automatic deletion after access)
- Replay attacks (single-view design)
- Content tampering (mandatory hash verification)
- Unauthorized access (token authentication)
- Compromised client devices
- Network eavesdropping without TLS
- Malicious reverse proxy
- Physical access to Redis storage
- Social engineering for URL/key disclosure
- Browser cache/history on client devices
- 2025-01-07: Internal security audit completed (Grade: A-)
- Regular dependency updates via Dependabot
We follow coordinated disclosure practices:
- Security issues are fixed in private
- New version is released with the fix
- Security advisory is published after release
- Credit given to reporters (with permission)
We thank the following for their responsible disclosure and contributions to Hakanai's security:
- Your name could be here
This security policy is based on industry best practices and follows the guidelines from securitytxt.org and GitHub's security policy templates.