← スキル一覧に戻る

authentication-security-pattern
by igbuend
A repository of security related skills - like secure code review and pentesting - for Claude and other AI.
⭐ 2🍴 1📅 2026年1月24日
SKILL.md
name: authentication-security-pattern description: Security pattern for implementing authentication in software systems. Use when designing or reviewing authentication mechanisms, implementing login systems, verifying user identity, protecting system access, or addressing OWASP authentication flaws. Provides guidance on enforcers, verifiers, evidence providers, subject registration, credential management, and security considerations.
Authentication Security Pattern
Authentication verifies that a subject (user, service, device) is who they claim to be before allowing system access. This pattern is a prerequisite for authorization and auditing.
Core Components
Roles
| Role | Type | Responsibility |
|---|---|---|
| Subject | Entity | Requests actions from the system |
| Enforcer | Enforcement Point | Intercepts requests; ensures authentication before processing. Must be incorporated into the system |
| Verifier | Decision Point | Validates credentials against evidence to determine authentication success |
| Evidence Provider | Entity | Stores/provides evidence for credential verification (internal or external) |
Data Elements
- credential: Proof of identity provided by Subject
- evidence: Data used by Verifier to validate credentials
- principal: Authenticated identity established after successful verification
- action: The operation Subject wants to perform
Authentication Flow
Subject → [action + credential] → Enforcer
Enforcer → [credential] → Verifier
Verifier → [request evidence] → Evidence Provider
Evidence Provider → [evidence] → Verifier
Verifier → [principal or error] → Enforcer
Enforcer → [action + principal] → System (if authenticated)
→ [error] → Subject (if failed)
- Subject requests action with credential
- Enforcer intercepts and forwards credential to Verifier
- Verifier requests evidence from Evidence Provider
- Verifier compares credential against evidence
- On success: Enforcer forwards action + principal to System
- On failure: Subject receives authentication error
Subject Registration
Registration establishes the credential/evidence pair. Three approaches:
- Subject-provided: Subject chooses both identifier and credential
- Hybrid: Subject provides identifier; system generates credential
- System-assigned: System generates both identifier and credential
Key requirements:
- Verify Subject actually owns the claimed identity (e.g., email verification)
- Protect credential transmission during registration
- Consider secure channels for initial credential delivery
Credential and Evidence Selection
Credential factors:
- Something you know: passwords, PINs
- Something you have: tokens, keys, devices
- Something you are: biometrics
Evidence guidelines:
- Never store credentials directly; use derived evidence (e.g., hashed passwords)
- Evidence leakage should not directly reveal credentials
- Protect evidence integrity to prevent tampering
Security Considerations
Enforcer Placement
- Must be impossible to bypass
- Place at system boundary where all requests enter
- Consider defense in depth with multiple enforcement points
Evidence Protection
- Encrypt evidence at rest
- Implement integrity checks to detect tampering
- Limit access to Evidence Provider
Rate Limiting
Prevent brute-force attacks:
- Limit authentication attempts per time window
- Implement exponential backoff
- Consider account lockout policies
- Protect against DoS on authentication endpoints
Credential Change
- Require current credential verification before changes
- Force re-authentication after credential updates
- Invalidate active sessions on credential change
Credential Reset
- Use out-of-band verification (email, SMS)
- Time-limit reset tokens
- Never expose whether an account exists
Logging
- Log authentication attempts (success and failure)
- Never log credentials
- Include timestamps and source identifiers
Related Patterns
- Password-based authentication: Uses identifier + password as credential
- Opaque token-based authentication: Uses system-issued tokens (e.g., session IDs)
- Verifiable token-based authentication: Uses self-contained tokens (e.g., JWTs)
- Multi-factor authentication: Combines multiple credential factors
- Session-based access control: Combines opaque tokens with authorization
Common Vulnerabilities (OWASP/IEEE Top 10)
- Broken authentication mechanisms
- Credential stuffing susceptibility
- Weak credential policies
- Missing rate limiting
- Insecure credential storage
- Session fixation
- Bypassing authentication checks
Implementation Checklist
- Enforcer intercepts ALL entry points
- Credentials never stored in plaintext
- Evidence protected at rest and in transit
- Rate limiting implemented
- Failed attempts logged (without credentials)
- Secure credential reset flow
- Session invalidation on credential change
- Identity verification during registration
References
- Source: Security Pattern Catalogue - DistriNet Research
- OWASP Authentication Cheat Sheet
- IEEE Top 10 Security Flaws
スコア
総合スコア
70/100
リポジトリの品質指標に基づく評価
✓SKILL.md
SKILL.mdファイルが含まれている
+20
✓LICENSE
ライセンスが設定されている
+10
✓説明文
100文字以上の説明がある
+10
○人気
GitHub Stars 100以上
0/15
○最近の活動
3ヶ月以内に更新がある
0/10
○フォーク
10回以上フォークされている
0/5
✓Issue管理
オープンIssueが50未満
+5
✓言語
プログラミング言語が設定されている
+5
○タグ
1つ以上のタグが設定されている
0/5
レビュー
💬
レビュー機能は近日公開予定です