moai-adk 0.35.1__py3-none-any.whl

moai_adk/templates/.claude/skills/moai-security-auth0/modules/attack-protection-log-events.md

@@ -0,0 +1,225 @@
+# Attack Protection Log Events
+
+Module: moai-security-auth0/modules/attack-protection-log-events.md
+Version: 1.0.0
+Last Updated: 2025-12-24
+
+---
+
+## Overview
+
+Auth0's tenant logs contain valuable data for monitoring attack protection activity. Analyzing log data helps identify potential security threats through traffic patterns and event monitoring.
+
+---
+
+## Key Event Types
+
+### Login Failure Events
+
+f: General failed login event.
+
+fu: Failed login due to invalid email or username.
+
+fp: Failed login due to incorrect password.
+
+s: Successful login (baseline for comparison).
+
+### Attack Protection Events
+
+limit_mu: Blocked IP address due to suspicious activity.
+
+limit_wc: Blocked account due to brute force protection.
+
+pwd_leak: Breached password detected during login attempt.
+
+signup_pwd_leak: Breached password detected during signup.
+
+### Other Security Events
+
+fcoa: Failed cross-origin authentication attempt.
+
+fsa: Failed silent authentication attempt.
+
+pla: Pre-login assessment event.
+
+---
+
+## Monitoring Strategies
+
+### Login Flow Error Monitoring
+
+Purpose: Detect abnormal surges in error rates indicating potential attacks.
+
+Implementation: Build a daily histogram of failure events to establish baseline traffic patterns.
+
+Attack Indicators: Large spikes in fu events often indicate credential stuffing attacks.
+
+Action: When spikes exceed baseline thresholds, investigate and potentially enable additional protections.
+
+### Attack Protection Event Monitoring
+
+Purpose: Identify coordinated attacks across multiple accounts.
+
+Key Metrics:
+
+- Rate of breached password detections
+- Account lockout frequency
+- IP blocking frequency
+
+Attack Indicators: Unusually high rates across multiple users suggest coordinated attacks.
+
+Action: Review affected accounts and consider temporary security escalation.
+
+### Geographic Analysis
+
+Purpose: Identify suspicious traffic from unexpected locations.
+
+Limitation: IP geolocation data is not available in tenant logs unless enriched from another source.
+
+Implementation:
+
+- Extract IP addresses from log events
+- Enrich with geolocation data using external services
+- Compare against expected user locations
+
+Action: Investigate authentication attempts from unexpected geographic regions.
+
+---
+
+## Log Search and Filtering
+
+### Dashboard Access
+
+Navigate to Dashboard then Monitoring then Logs to access tenant logs.
+
+### Query Syntax
+
+Filter by Event Type: Use type filter to find specific events.
+
+Date Range: Specify time windows for analysis.
+
+User ID: Filter events for specific users.
+
+IP Address: Track activity from specific IP addresses.
+
+### Useful Queries
+
+Breached Password Events: Filter for pwd_leak and signup_pwd_leak events.
+
+Blocked IPs: Filter for limit_mu events.
+
+Failed Logins: Filter for f, fu, fp events.
+
+---
+
+## Building Monitoring Dashboards
+
+### Recommended Metrics
+
+Daily Failure Rate: Track total failed logins per day.
+
+Attack Protection Triggers: Count of limit_mu and limit_wc events.
+
+Breached Password Detections: Count of pwd_leak events.
+
+Success vs Failure Ratio: Compare successful to failed authentication.
+
+### Alerting Thresholds
+
+Set alerts when metrics exceed baseline values:
+
+- Failed login rate exceeds 2x normal baseline
+- Any limit_mu events (IP blocking)
+- Multiple pwd_leak events in short timeframe
+- Geographic anomalies detected
+
+---
+
+## Log Event Details
+
+### Event Data Structure
+
+Each log event contains:
+
+date: Timestamp of the event.
+
+type: Event type code.
+
+description: Human-readable description.
+
+connection: Connection used for authentication.
+
+client_id: Application involved.
+
+client_name: Application name.
+
+ip: Source IP address.
+
+user_agent: Client user agent string.
+
+user_id: Authenticated user identifier (if applicable).
+
+user_name: User's name or email (if applicable).
+
+### Data Retention
+
+Log retention periods vary by plan:
+
+- Free: 2 days
+- Developer: 2 days
+- Developer Pro: 10 days
+- Enterprise: 30 days
+
+For longer retention, export logs using Log Streams.
+
+---
+
+## Integration with External Systems
+
+### Log Streams
+
+Export logs to external systems for advanced analysis:
+
+- Amazon EventBridge
+- Azure Event Hubs
+- Datadog
+- Splunk
+- Sumo Logic
+- Custom webhooks
+
+### SIEM Integration
+
+Forward security events to Security Information and Event Management systems for centralized monitoring and correlation.
+
+---
+
+## Best Practices
+
+Regular Review: Establish regular log review schedules.
+
+Baseline Establishment: Create normal traffic baselines before setting alert thresholds.
+
+Automated Alerting: Configure automated alerts for critical events.
+
+Incident Response: Document procedures for responding to detected threats.
+
+Retention Planning: Plan for log retention beyond default periods if needed.
+
+---
+
+## Related Modules
+
+- attack-protection-overview.md: Attack protection configuration
+- bot-detection.md: Bot detection events
+- brute-force-protection.md: Account lockout events
+- suspicious-ip-throttling.md: IP throttling events
+- security-center.md: Security monitoring dashboard
+
+---
+
+## Resources
+
+Auth0 Documentation: View Attack Protection Log Events
+Auth0 Documentation: Log Search Query Syntax
+Auth0 Documentation: Log Streams
+Context7 Library: /auth0/auth0-docs (topic: attack-protection-logs)

moai_adk/templates/.claude/skills/moai-security-auth0/modules/attack-protection-overview.md

@@ -0,0 +1,140 @@
+# Attack Protection Overview
+
+Auth0 provides layered protection using multiple risk signals to detect and mitigate attacks. Configure response settings in Dashboard > Security > Attack Protection.
+
+## Core Protection Features
+
+### Bot Detection
+
+Risk Signal: IP reputation analysis based on traffic quality patterns.
+
+Mechanism: Triggers authentication challenges when login attempts originate from IPs suspected of bot activity. Uses statistical models analyzing login, signup, and password reset traffic patterns.
+
+Configuration Options:
+- Sensitivity Levels: Low, Medium (default), High
+- Response Types: Auth Challenge (CAPTCHA-free JavaScript verification), Simple CAPTCHA, third-party integrations (reCAPTCHA)
+- IP AllowList: Up to 100 discrete addresses or CIDR ranges
+
+Supported Flows:
+- Auth0 Universal Login
+- Classic Login (default)
+- Lock.js v12.4.0 and later
+- Native apps with Auth0.swift 1.28.0+ or Auth0.Android 1.25.0+
+
+Unsupported Flows:
+- Enterprise connections
+- Social login
+- Cross-origin authentication flows
+
+Signup Detection: Uses a distinct model addressing different attack patterns than login flows. Requires updated library versions (Auth0.js 9.28.0+, Lock 13.0+).
+
+### Breached Password Detection
+
+Risk Signal: Compromised passwords found in dark web databases and third-party breach data.
+
+Detection Methods:
+
+Standard Detection:
+- Tracks publicly released breach data
+- Detection time: 7-13 months after breach disclosure
+- Available on B2B/B2C Professional or Enterprise plans
+
+Credential Guard (Enterprise add-on):
+- Accesses non-public breach data through dedicated security teams
+- Detection time: 12-36 hours
+- Coverage: 200+ countries
+
+Response Scenarios:
+- Block compromised credentials for new account signup
+- Block compromised user accounts from logging in
+- Block compromised credentials during password reset
+
+Notification Options:
+- User notifications when credentials are compromised
+- Admin alerts for signup/login attempts with breached passwords
+- Frequency: Immediate, Daily, Weekly, or Monthly
+
+Testing: Use any password starting with AUTH0-TEST- to trigger detection for verification without real alerts.
+
+### Brute Force Protection
+
+Risk Signal: Velocity of login attempts targeting a specific account.
+
+Mechanism: Identifies repeated failed login attempts from a single IP address within defined periods. When triggered, blocks the suspicious IP from logging in as that user.
+
+Configuration Settings:
+- Brute Force Threshold: Default 10 failed attempts (configurable 1-100)
+- IP AllowList: Exempt trusted IP addresses or CIDR ranges
+- Response Options: Block brute-force logins (IP-based), Account lockout (any IP), User notifications
+
+Block Removal Events:
+- 30 days pass since the last failed attempt
+- User changes password on all linked accounts
+- Administrator removes the block or raises threshold
+- User selects unblock link in notification email
+
+Special Considerations:
+- Resource Owner Password Flow: Include user IP via auth0-forwarded-for header
+- Proxy Users: More likely to trigger protection; use IP AllowList
+- Multi-Account Users: Must change passwords on all linked accounts
+
+### Suspicious IP Throttling
+
+Risk Signal: Velocity of login attempts from an IP across multiple accounts.
+
+Mechanism: Automatically blocks traffic from IP addresses exhibiting high-velocity login or signup attempts. Responds with HTTP 429 (Too Many Requests) status codes.
+
+How Velocity Detection Works:
+
+Login Attempts:
+- Tracks failed login attempts per IP address daily
+- Once threshold exceeded, throttles subsequent attempts
+- Rate distributed evenly across 24 hours
+- Example: Rate of 100 grants approximately one attempt every 15 minutes
+
+Signup Attempts:
+- Counts all attempts (successful or failed) within one-minute window
+- When IP surpasses limit, further signups blocked
+- Throttling rate distributes attempts over 24 hours
+- Example: Rate of 72,000 allows roughly one attempt per second
+
+Configuration Options:
+- Maximum failed login attempts (per day threshold)
+- Maximum signup attempts (per minute threshold)
+- Throttling rates for both categories
+- IP AllowList (up to 100 addresses/CIDR ranges)
+- Administrator email notifications
+
+Important Notes:
+- Malformed requests and schema validation errors do not count toward thresholds
+- For Resource Owner Password Grant, manually pass client IP for proper detection
+- Enabled by default on new tenants
+
+## Monitoring Mode
+
+Enable features without response settings to activate monitoring mode. This records events in tenant logs for analysis and decision-making before deploying active blocking mechanisms.
+
+## User Notifications
+
+During attacks, users receive email alerts once per hour regardless of attempt volume. Password reset links are valid for 5 days. Administrators receive hourly notifications when traffic blocking occurs.
+
+## Configuration Best Practices
+
+Initial Deployment:
+1. Enable features in monitoring mode first
+2. Analyze tenant logs for false positive patterns
+3. Configure IP AllowLists for trusted sources
+4. Gradually enable response actions
+5. Set appropriate notification frequencies
+
+Threshold Tuning:
+- Balance security with user experience
+- Consider your user base login patterns
+- Account for users behind shared IPs or proxies
+- Review and adjust based on actual attack data
+
+Recommended Starting Configuration:
+- Bot Detection: Medium sensitivity with Auth Challenge
+- Breached Password Detection: Block on signup and login with user notifications
+- Brute Force Protection: 10 attempts with IP blocking and user notifications
+- Suspicious IP Throttling: Default thresholds with admin notifications

moai_adk/templates/.claude/skills/moai-security-auth0/modules/bot-detection.md

@@ -0,0 +1,144 @@
+# Bot Detection
+
+Auth0 Bot Detection mitigates scripted attacks by identifying requests likely originating from bots using traffic pattern analysis and IP reputation data.
+
+## How It Works
+
+Auth0 uses large amounts of data and statistical models to identify patterns signaling when bursts of login, signup, or password reset traffic are likely from a bot or script. When detected, the system triggers authentication challenges.
+
+## Configuration
+
+### Dashboard Navigation
+
+Access: Dashboard > Security > Attack Protection > Bot Detection
+
+### Detection Sensitivity
+
+Three risk levels available:
+
+Low Sensitivity:
+- Fewer users challenged
+- May miss sophisticated bots
+- Best for high-friction tolerance applications
+
+Medium Sensitivity (Default):
+- Balanced detection approach
+- Recommended for most applications
+- Good trade-off between security and UX
+
+High Sensitivity:
+- Maximum bot detection
+- More legitimate users may be challenged
+- Best for high-security applications
+
+### Response Types
+
+Auth Challenge (Recommended):
+- CAPTCHA-free verification requiring JavaScript execution
+- Minimal user friction
+- Detects non-browser clients automatically
+
+Simple CAPTCHA:
+- Traditional CAPTCHA interface
+- Works in non-JavaScript environments
+- Higher user friction but more accessible
+
+Third-Party Integration:
+- reCAPTCHA integration available
+- Other CAPTCHA providers supported
+- Configure via Authentication API
+
+### CAPTCHA Trigger Modes
+
+Configure when CAPTCHA displays:
+- Never: Disable challenges entirely
+- When Risky: Challenge based on detection level (recommended)
+- Always: Challenge every request
+
+### IP AllowList
+
+Supports up to 100 entries:
+- Discrete IP addresses
+- CIDR range notation
+- Useful for trusted office networks
+- Prevents blocking of known-good sources
+
+## Supported Flows
+
+Fully Supported:
+- Auth0 Universal Login (recommended)
+- Classic Login
+- Lock.js v12.4.0 and later
+- Auth0.swift 1.28.0 and later (iOS)
+- Auth0.Android 1.25.0 and later
+
+Not Supported:
+- Enterprise connections (SAML, OIDC, AD/LDAP)
+- Social login providers
+- Cross-origin authentication flows
+
+## Signup vs Login Detection
+
+Auth0 uses distinct detection models for signup and login flows:
+
+Login Detection:
+- Focuses on credential stuffing patterns
+- Analyzes failed authentication velocity
+- Considers account targeting patterns
+
+Signup Detection:
+- Addresses automated account creation
+- Analyzes registration velocity
+- Requires updated library versions:
+  - Auth0.js 9.28.0+
+  - Lock 13.0+
+
+## Monitoring Mode
+
+Enable bot detection without response settings to record risk assessment details in tenant logs without enforcing actions. Useful for:
+- Baseline traffic analysis
+- False positive assessment
+- Threshold calibration
+- Pre-deployment validation
+
+## Tenant Log Events
+
+Bot detection events appear in tenant logs with:
+- Risk assessment scores
+- IP reputation data
+- Device fingerprinting results
+- Challenge outcomes
+
+## Implementation Considerations
+
+User Experience:
+- Auth Challenge has minimal friction
+- Consider fallback for JavaScript-disabled users
+- Test challenge flows thoroughly
+
+Performance:
+- Minimal latency impact
+- Client-side challenge execution
+- No server-side processing delay
+
+Integration:
+- Works with Universal Login out-of-box
+- Custom UI requires Auth0.js integration
+- Native apps need SDK updates
+
+## Troubleshooting
+
+False Positives:
+- Add IP to AllowList if consistent
+- Lower sensitivity level
+- Review user agent patterns
+
+Bots Not Detected:
+- Increase sensitivity level
+- Enable Always challenge mode temporarily
+- Review traffic patterns in logs
+
+Challenge Failures:
+- Verify JavaScript execution environment
+- Check third-party CAPTCHA configuration
+- Test network connectivity to Auth0

moai_adk/templates/.claude/skills/moai-security-auth0/modules/breached-password-detection.md

@@ -0,0 +1,187 @@
+# Breached Password Detection
+
+Auth0 Breached Password Detection protects applications by identifying when user credentials appear in known security breaches and taking appropriate action.
+
+## How It Works
+
+Auth0 monitors third-party data breaches and compares user credentials against known compromised credential databases. When a match is found, the system can block access and notify affected parties.
+
+## Detection Methods
+
+### Standard Detection
+
+Included with B2B/B2C Professional or Enterprise plans.
+
+Characteristics:
+- Tracks publicly released breach data
+- Detection time: 7-13 months after breach disclosure
+- Relies on public breach announcements and databases
+- Comprehensive coverage of major breaches
+
+### Credential Guard (Enterprise Add-on)
+
+Enhanced detection with dedicated security team access.
+
+Characteristics:
+- Accesses non-public breach data
+- Detection time: 12-36 hours
+- Coverage: 200+ countries
+- Proactive breach intelligence
+- Dark web monitoring
+
+## Configuration
+
+### Dashboard Navigation
+
+Access: Dashboard > Security > Attack Protection > Breached Password Detection
+
+### Response Scenarios
+
+Block on Signup:
+- Prevents account creation with compromised credentials
+- User must choose a different password
+- Immediate protection for new accounts
+
+Block on Login:
+- Prevents authentication with breached passwords
+- Existing users must reset password
+- Protects against credential stuffing
+
+Block on Password Reset:
+- Prevents setting compromised passwords during reset
+- Ensures clean password after breach detection
+- Maintains protection through password changes
+
+### Notification Configuration
+
+User Notifications:
+- Alert users when their credentials are found in breaches
+- Includes password reset instructions
+- Configurable messaging
+
+Admin Notifications:
+- Alerts for signup attempts with breached passwords
+- Alerts for login attempts with compromised credentials
+- Frequency options: Immediate, Daily, Weekly, Monthly
+
+### Response Combinations
+
+Recommended for Most Applications:
+- Block on signup: Enabled
+- Block on login: Enabled
+- User notifications: Enabled
+- Admin notifications: Weekly
+
+High-Security Applications:
+- All blocking options enabled
+- User notifications: Enabled
+- Admin notifications: Immediate
+
+Monitoring Only:
+- All blocking disabled
+- User notifications: Disabled
+- Admin notifications: Enabled (for analysis)
+
+## Testing
+
+Auth0 provides test credentials for verification:
+
+Test Password Pattern: Any password starting with AUTH0-TEST-
+
+Examples:
+- AUTH0-TEST-password123
+- AUTH0-TEST-breached
+- AUTH0-TEST-anything
+
+Testing Process:
+1. Enable breached password detection
+2. Attempt signup or login with test password
+3. Verify blocking or notification behavior
+4. Confirm expected user experience
+
+Note: Test passwords trigger detection without affecting production breach databases.
+
+## Library Requirements
+
+Ensure SDK versions support breached password detection:
+
+Lock.js:
+- Version 11.33.3 or later
+- Full feature support
+
+Auth0.js:
+- Latest version recommended
+- Full feature support
+
+Native SDKs:
+- Auth0.swift: 1.28.0+
+- Auth0.Android: 1.25.0+
+
+## User Experience
+
+When Blocked on Signup:
+- User sees password requirement message
+- Must choose different password
+- Clear guidance on password selection
+
+When Blocked on Login:
+- User sees account security message
+- Directed to password reset flow
+- Email sent with reset instructions
+
+Notification Content:
+- Explains credentials found in breach
+- Does not reveal which breach
+- Provides password reset link
+- Valid for 5 days
+
+## Integration Considerations
+
+Password Requirements:
+- Combine with strong password policies
+- Consider password strength meters
+- Provide clear error messaging
+
+User Communication:
+- Customize breach notification templates
+- Explain without causing panic
+- Emphasize security benefits
+
+Recovery Flows:
+- Ensure password reset works smoothly
+- Consider step-up authentication
+- Monitor reset completion rates
+
+## Metrics and Monitoring
+
+Track in Tenant Logs:
+- Blocked signup attempts
+- Blocked login attempts
+- Notification deliveries
+- Password reset completions
+
+Dashboard Metrics:
+- Detection counts over time
+- Block rates by scenario
+- User compliance rates
+
+## Best Practices
+
+Deployment:
+1. Enable in monitoring mode first
+2. Review detection rates
+3. Enable blocking on signup
+4. Enable blocking on login after communication
+5. Monitor user support requests
+
+Communication:
+- Announce security feature to users
+- Explain why passwords may be rejected
+- Provide password manager recommendations
+- Set expectations for breach notifications
+
+Ongoing Management:
+- Review detection metrics regularly
+- Adjust notification frequency based on volume
+- Keep SDKs updated for latest breach data
+- Consider Credential Guard for enhanced protection