RUSTSEC-2023-0071 (Marvin Attack on RSA) affects this framework when using MySQL storage through the SQLx dependency chain. This is a timing side-channel vulnerability in RSA PKCS#1 v1.5 decryption operations.

Key Details:

• CVE: CVE-2023-49092
• Severity: Medium (CVSS 5.9)
• Risk Assessment: EXTREMELY LOW in typical production environments
• Affected Features: MySQL storage (mysql-storage feature)

The vulnerability poses minimal practical risk because:

1. Network Access Required: Attacker needs ability to trigger RSA operations remotely
2. Complex Attack: Requires sophisticated timing analysis over many operations
3. Limited Exposure: RSA operations in SQLx are primarily for TLS connection setup
4. Infrastructure Protection: Production environments typically have network isolation

We strongly recommend using PostgreSQL instead of MySQL to completely eliminate this vulnerability:

[features]
default = ["postgres-storage"]  # Instead of mysql-storage

Benefits of PostgreSQL Migration:

• ✅ Complete RSA elimination - No RSA dependencies in the chain
• ✅ Better performance - Native Rust PostgreSQL drivers
• ✅ Enhanced features - Superior JSON support, full-text search
• ✅ Minimal migration effort - SQLx provides database-agnostic interface

If PostgreSQL migration is not immediately feasible:

1. Network Isolation: Ensure database connections are not exposed to untrusted networks
2. VPN/Private Networks: Use secure, isolated network channels for database communication
3. Connection Pooling: Use connection pooling to reduce RSA handshake frequency
4. Monitoring: Monitor for unusual timing patterns in database operations

• Production Safe: Framework is secure for production use with proper network isolation
• No Immediate Action Required: Vulnerability is not practically exploitable in typical deployments
• Long-term Recommendation: Migrate to PostgreSQL for optimal security posture

For detailed technical analysis, see RUSTSEC-2023-0071_COMPREHENSIVE_ANALYSIS.md.

Currently supported versions of the Auth Framework with security updates:

The Auth Framework is designed with security as a primary concern. However, security is a shared responsibility between the library maintainers and the users implementing it.

This library provides:

• Secure Token Management: JWT tokens with proper signing and validation
• Password Hashing: Argon2 and bcrypt implementations
• Rate Limiting: Protection against brute force attacks
• Session Management: Secure session handling with expiration
• Constant-Time Operations: Protection against timing attacks
• Input Validation: Comprehensive input sanitization
• Audit Logging: Security event tracking

When using this library, ensure:

• Secret Management: Never hardcode secrets in your application
• HTTPS: Always use HTTPS in production
• Key Rotation: Regularly rotate signing keys and secrets
• Dependency Updates: Keep all dependencies updated
• Configuration Review: Regularly review security configurations
• Monitoring: Monitor for suspicious authentication patterns

We take security vulnerabilities seriously. If you discover a security issue:

Instead, please:

1. Email: Send details to security@example.com
2. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if any)
3. Encrypt: Use PGP if possible (key available on request)

1. Acknowledgment: We will acknowledge receipt within 48 hours
2. Assessment: We will assess the vulnerability within 5 business days
3. Fix: We will work on a fix and coordinate disclosure
4. Release: Security fixes will be released as soon as possible
5. Credit: We will credit the reporter unless they prefer to remain anonymous

// Use strong secrets
let config = AuthConfig::new()
    .security(SecurityConfig::secure()) // Use secure defaults
    .rate_limiting(RateLimitConfig::new(100, Duration::from_secs(60)));

// Good: Use environment variables
let secret = std::env::var("JWT_SECRET").expect("JWT_SECRET must be set");

// Bad: Hardcoded secret
let secret = "hardcoded-secret"; // DON'T DO THIS

// Use secure storage in production
let storage = RedisStorage::new("rediss://user:pass@redis.example.com:6380")?;

// Not recommended for production
let storage = MemoryStorage::new(); // Only for development/testing

• No hardcoded secrets or passwords
• Proper input validation
• Constant-time operations for sensitive comparisons
• No sensitive data in logs
• Proper error handling without information leakage
• Secure defaults in configurations
• Updated dependencies

• Test with invalid/malformed inputs
• Test rate limiting functionality
• Test token expiration and revocation
• Test permission boundaries
• Test against common attack vectors

• User credentials and authentication data
• Session tokens and API keys
• User personal information
• System configuration and secrets

• Credential Stuffing: Automated attempts using stolen credentials
• Brute Force: Systematic password guessing attempts
• Session Hijacking: Stealing or intercepting session tokens
• Privilege Escalation: Gaining unauthorized access levels
• Timing Attacks: Exploiting time differences in operations
• Injection Attacks: Malicious input exploitation

• Rate limiting and account lockout
• Strong password requirements
• Secure session management
• Proper authorization checks
• Constant-time operations
• Input validation and sanitization

This library aims to help users meet common security standards:

• OWASP Top 10: Address common web application vulnerabilities
• NIST Cybersecurity Framework: Implement security controls
• PCI DSS: Payment card industry security standards
• GDPR: Data protection compliance features

We regularly audit and update dependencies. Security-sensitive dependencies include:

• ring: Cryptographic operations
• jsonwebtoken: JWT implementation
• argon2: Password hashing
• redis: Storage backend
• tokio: Async runtime

Security-related changes will be clearly marked in the changelog with the [SECURITY] tag.

For security questions or concerns:

• Email: security@example.com
• PGP Key: Available on request

We thank the security researchers and community members who help keep this project secure.

This security policy is subject to updates. Please check regularly for the latest version.