Chapter 8: Security Fundamentals

Introduction

Security is not a feature—it's a fundamental property of system design. Every distributed system must answer: Who are you? (Authentication) and What can you do? (Authorization). This chapter covers the complete security stack from cryptographic primitives to zero trust architectures.

1. Authentication vs Authorization

Clear Definitions

Request Flow

Why Separate Concerns?

• Scalability: AuthN can be centralized (issue token once), AuthZ distributed (policy enforcement at edge)
• Security: Compromised token doesn't bypass authorization checks
• Flexibility: Change permissions without re-authenticating users
• Auditability: Log who accessed what, not just who logged in

2. Authentication Methods

2.1 Password-Based Authentication

Password Hashing: Why and How

Never store plaintext passwords. Hashing is one-way—verify by hashing input and comparing. But hashing alone is vulnerable to rainbow tables.

Salt: Defeat Rainbow Tables

Salt is random data mixed with password before hashing. Each user gets unique salt (stored alongside hash). Same password → different hash per user.

// Without salt (vulnerable to rainbow table)
hash('password123') → '482c811da5d5b4bc6d497ffa98491e38'
// Attacker precomputes hash → finds password instantly

// With salt (each user unique)
user1_salt = random_bytes(16)  // e.g., '9f86d081884c7d659a2feaa0c55ad015'
user1_hash = hash('password123' + user1_salt) → 'a1b2c3d4...'

user2_salt = random_bytes(16)  // e.g., '7c211433f02071597741e6ff5a8ea34b'
user2_hash = hash('password123' + user2_salt) → 'e5f6g7h8...'
// Attacker must bruteforce each user separately

Pepper: Server Secret

Pepper is a secret key stored separately (environment variable, KMS), NOT in database. Added to password+salt before hashing. If database is compromised, attacker still needs pepper.

pepper = env('PASSWORD_PEPPER')  // Server secret, not in DB
final_hash = hash(password + salt + pepper)

Algorithm Comparison

Work Factor (Cost Parameter)

Higher cost = slower hashing = harder to bruteforce. But too slow impacts user experience. Balance security vs performance.

// bcrypt cost parameter (2^cost rounds)
cost = 10  →  ~150ms (2010 hardware)
cost = 12  →  ~600ms (2020 hardware)  ← recommended
cost = 14  → ~2400ms (too slow for login)

// Argon2 parameters
time_cost = 3       // Iterations
memory_cost = 65536 // 64 MB
parallelism = 4     // Threads

2.2 Multi-Factor Authentication (MFA)

Three Factors

• Something you know: Password, PIN
• Something you have: Phone (TOTP app), hardware key (YubiKey), smart card
• Something you are: Fingerprint, face, iris

MFA requires 2+ factors from different categories. Password + security question = same factor (both "know").

TOTP (Time-Based One-Time Password)

Algorithm: HOTP (RFC 4226) + time window. Shared secret between server and authenticator app.

FIDO2/WebAuthn (Hardware Keys)

Public key cryptography. Private key never leaves hardware device. Resistant to phishing (domain-bound).

SMS OTP (One-Time Password)

Server sends code via SMS. User enters code to verify phone possession.

MFA Security Comparison

2.3 Certificate-Based Authentication

Client presents X.509 certificate to prove identity. Used in mTLS, smart cards, device trust.

Certificate Contents (X.509)

Subject: CN=client.example.com, O=MyOrg, C=US
Issuer: CN=Internal CA, O=MyOrg
Serial Number: 04:3f:7e:...
Valid From: 2024-01-01 00:00:00 UTC
Valid To: 2025-01-01 00:00:00 UTC
Public Key: RSA 2048 bits
            30:82:01:0a:02:82:01:01:00:...
Signature Algorithm: SHA256-RSA
Extensions:
  - Key Usage: Digital Signature, Key Encipherment
  - Extended Key Usage: TLS Client Authentication
  - Subject Alternative Name: DNS:client.example.com

When to Use

• Service-to-service: mTLS for zero trust
• IoT devices: Each device has unique cert
• Employee access: Smart card with certificate
• API clients: Instead of API keys (harder to leak)

2.4 API Keys

Long-lived credentials for programmatic access. Simple but requires careful management.

Anatomy

API Key Structure:
  prefix.identifier.secret
  └─┬─┘ └────┬────┘ └──┬──┘
    │        │          └─ Random bytes (hash before storing)
    │        └─────────── Key ID (for lookup, not secret)
    └──────────────────── Prefix (e.g., 'sk_live_', 'prod_')

Example: sk_live_EXAMPLE_DO_NOT_USE_12345

Database stores:
  key_id: 4eC39HqLyjWDarjtT1zdp7dc
  hash: bcrypt(secret)
  permissions: [read:users, write:orders]
  created: 2024-01-15
  last_used: 2024-03-20

Rotation Strategy

API Key vs OAuth

2.5 Biometric Authentication

How It Works

Biometric Types

Security Considerations

• Biometric ≠ Secret: You can't change your fingerprint if compromised. Use biometric to unlock secret (private key), not as the secret itself.
• Local Processing: Template should never leave device. Server doesn't store biometric data.
• Liveness Detection: Detect fake fingerprints (conductivity), photos (depth sensing), deepfakes (challenge-response).
• Fallback Required: Biometric can fail (injury, gloves). Always provide password fallback.

System Architecture (Mobile)

3. Session Management

Server-Side Sessions

How It Works

Session Store Options

Cookie Security Flags

Set-Cookie: session_id=abc123;
  HttpOnly;     // Can't be read by JavaScript (XSS protection)
  Secure;       // Only sent over HTTPS
  SameSite=Lax; // CSRF protection (Lax allows top-level navigation)
  Domain=.example.com; // Subdomain sharing
  Path=/;       // Available to all paths
  Max-Age=3600  // Expires in 1 hour

Stateless Tokens (JWT)

Architecture Comparison

Trade-offs

Session Attacks & Prevention

Session Fixation

Attacker tricks user into using attacker-controlled session ID.

Prevention: Always regenerate session ID after authentication.

// Before login
session_id = 'abc123'  // Anonymous session

// After successful login
old_session_id = 'abc123'
new_session_id = generate_random()  // 'xyz789'
copy_session_data(old_session_id, new_session_id)
delete_session(old_session_id)
set_cookie('session_id', new_session_id)

Session Hijacking

Attacker steals valid session ID (XSS, network sniffing, malware).

Prevention:

• HTTPS only: Secure flag on cookies
• HttpOnly: Prevent JavaScript access
• Bind session to IP/User-Agent: Reject if changed (impacts mobile users roaming networks)
• Short expiry: 15-30 minutes, refresh token for longer access
• Concurrent session limits: Force logout of old sessions when new login

CSRF (Cross-Site Request Forgery)

Attacker tricks user's browser into making authenticated request.

Prevention:

• SameSite cookie: Browser won't send cookie on cross-site POST (modern browsers)
• CSRF token: Secret token in form, validated server-side (for older browsers)
• Custom headers: Require X-Requested-With: XMLHttpRequest (AJAX can't be forged cross-domain)
• Double-submit cookie: CSRF token in cookie + form, server compares both

Token Rotation & Refresh

Why Two Tokens?

Rotation Prevents Replay: Each refresh returns NEW refresh token, old one invalidated. If attacker steals refresh token and uses it, legitimate user's next refresh fails → detects compromise.

4. OAuth 2.0 Deep Dive

OAuth 2.0 is an authorization framework (NOT authentication protocol). It lets users grant third-party apps limited access to their resources without sharing credentials.

Core Concepts

Roles

• Resource Owner: User who owns the data (e.g., you on GitHub)
• Client: Third-party app requesting access (e.g., CI/CD tool)
• Authorization Server: Issues tokens (e.g., GitHub OAuth server)
• Resource Server: Hosts protected resources (e.g., GitHub API)

Scopes

Granular permissions. Client requests specific scopes, user consents to subset.

// GitHub scopes
repo              // Full repo access
repo:status       // Read commit status
public_repo       // Only public repos
user              // Read/write user profile
read:user         // Read-only user profile
gist              // Create gists

// Slack scopes
channels:read     // View channels
chat:write        // Post messages
files:read        // View files

// Request multiple scopes
scope=repo%20user%20gist

Grant Types (Authorization Flows)

4.1 Authorization Code Grant (Most Secure)

For web apps with backend. User redirected to authorization server, grants permission, server redirects back with code, app exchanges code for token.

Security: State Parameter

Prevents CSRF. Client generates random state, includes in authorization URL, validates it matches in callback.

// Step 1: Generate state
state = random_string(32)  // 'a3f7e9...'
store_in_session('oauth_state', state)
redirect_to('https://auth.com/authorize?state=' + state)

// Step 2: Validate state in callback
received_state = params['state']
expected_state = get_from_session('oauth_state')
if (received_state !== expected_state) {
  throw new Error('CSRF attack detected')
}

4.2 Authorization Code + PKCE (For Mobile/SPA)

PKCE (Proof Key for Code Exchange) protects public clients that can't store client secret. Uses code verifier and challenge.

PKCE Prevents Code Interception

Without PKCE, attacker intercepts code in redirect, exchanges it for token (public clients have no client secret). With PKCE, attacker needs code_verifier (which never leaves app).

4.3 Client Credentials Grant (Service-to-Service)

No user involved. Service authenticates with client ID + secret, gets token for its own access.

When to Use

• Backend service accessing its own resources
• Microservice-to-microservice auth
• Scheduled jobs, cron tasks
• CLI tools (machine-to-machine)

4.4 Device Code Grant (IoT, CLI)

For devices without browser or limited input (smart TV, CLI). User authorizes on separate device.

Real-World Examples

• AWS CLI: aws sso login
• GitHub CLI: gh auth login
• Google TV YouTube login

4.5 Implicit Grant (DEPRECATED)

Historically for SPAs. Auth server returns access token directly in redirect URL (no code exchange). Insecure—token exposed in browser history, URL logs.

OAuth vs OpenID Connect (OIDC)

OIDC Flow (Authorization Code + OIDC)

ID Token Structure (JWT)

// Header
{
  "alg": "RS256",
  "kid": "key-id-1"
}

// Payload (standard claims)
{
  "iss": "https://accounts.google.com",     // Issuer
  "sub": "1234567890",                       // Subject (user ID)
  "aud": "your-client-id.apps.googleusercontent.com", // Audience
  "exp": 1701234567,                         // Expiration
  "iat": 1701230967,                         // Issued at
  "name": "Alice Smith",
  "email": "alice@gmail.com",
  "email_verified": true,
  "picture": "https://lh3.googleusercontent.com/..."
}

// Signature (verify with public key)

OAuth Security Best Practices

1. Redirect URI Validation

Auth server MUST validate redirect_uri exactly matches pre-registered value. Prevents authorization code interception.

// ❌ BAD: Wildcard or partial match
allowed_redirects = ['https://app.com/*']  // Attacker uses app.com.evil.com

// ✓ GOOD: Exact match
allowed_redirects = [
  'https://app.com/oauth/callback',
  'https://app.com/auth/google/callback'
]

// Validate
if (request.redirect_uri not in allowed_redirects) {
  return error('invalid_redirect_uri')
}

2. Always Use HTTPS

OAuth without HTTPS = attacker intercepts code/token. Never use http:// redirect URIs in production.

3. Short-Lived Access Tokens

Access tokens should expire in 5-60 minutes. Use refresh token for long-lived access. Limits damage if token leaks.

4. Token Storage (Frontend)

5. Token Introspection vs JWT

Hybrid Approach

• Access token: JWT (short-lived, fast validation)
• Refresh token: Opaque (stored in DB, revocable)

5. JWT (JSON Web Tokens)

Structure

// Full JWT
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
└─────────── HEADER ────────────┘ └──────────────── PAYLOAD ────────────────┘ └──────── SIGNATURE ──────┘

// Decoded Header (Base64URL)
{
  "alg": "HS256",  // Algorithm: HMAC SHA-256
  "typ": "JWT"     // Type
}

// Decoded Payload (Base64URL)
{
  "sub": "1234567890",         // Subject (user ID)
  "name": "John Doe",           // Custom claim
  "iat": 1516239022             // Issued at (Unix timestamp)
}

// Signature (HMAC or RSA signature of header + payload)

Signing Algorithms

HS256 (HMAC + SHA-256) — Symmetric

Single secret key for signing AND verifying. Both auth server and API share the same secret.

// Signing (Auth Server)
header = base64url({"alg":"HS256","typ":"JWT"})
payload = base64url({"sub":"123","exp":1234567890})
signature = HMAC-SHA256(header + "." + payload, secret_key)
jwt = header + "." + payload + "." + signature

// Verification (API Server)
received_signature = jwt.split('.')[2]
computed_signature = HMAC-SHA256(jwt.split('.')[0] + "." + jwt.split('.')[1], secret_key)
if (received_signature === computed_signature) {
  // Valid
}

Pros: Fast, simple
Cons: Every service needs the secret (secrets proliferation), can't distinguish who signed it

RS256 (RSA + SHA-256) — Asymmetric

Private key for signing, public key for verifying. Auth server keeps private key, APIs get public key.

// Key Generation
openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout -out public.pem

// Signing (Auth Server)
signature = RSA-SHA256(header + "." + payload, private_key)

// Verification (API Server)
is_valid = RSA-Verify(header + "." + payload, signature, public_key)

Pros: APIs can't issue tokens (only verify), public key can be shared widely
Cons: Slower than HMAC, larger signatures

ES256 (ECDSA + SHA-256) — Asymmetric

Elliptic curve cryptography. Smaller keys and signatures than RSA, similar security.

// Key sizes for equivalent security
RSA-2048   ≈ ECDSA-256  ≈ 112-bit security
RSA-3072   ≈ ECDSA-384  ≈ 128-bit security

// Signature size
RS256: 256 bytes
ES256: 64 bytes  ← 4x smaller!

Algorithm Comparison

Standard Claims

Custom Claims

{
  // Standard claims
  "iss": "https://auth.example.com",
  "sub": "user_12345",
  "aud": "https://api.example.com",
  "exp": 1701234567,
  "iat": 1701230967,

  // Custom claims (namespaced to avoid conflicts)
  "https://example.com/roles": ["admin", "editor"],
  "https://example.com/tenant_id": "tenant_abc",
  "email": "alice@example.com",
  "email_verified": true,
  "plan": "premium"
}

JWT Validation

// JWT Validation Checklist
function validateJWT(token, expected_audience) {
  // 1. Decode header (don't trust yet)
  header = base64_decode(token.split('.')[0])

  // 2. Check algorithm (prevent algorithm confusion)
  if (header.alg !== 'RS256') {
    throw new Error('Invalid algorithm')
  }

  // 3. Verify signature
  public_key = get_public_key(header.kid)  // Key ID from header
  if (!verify_signature(token, public_key)) {
    throw new Error('Invalid signature')
  }

  // 4. Decode payload (now trusted)
  payload = json_decode(base64_decode(token.split('.')[1]))

  // 5. Check expiration
  if (payload.exp < current_time()) {
    throw new Error('Token expired')
  }

  // 6. Check not-before
  if (payload.nbf > current_time()) {
    throw new Error('Token not yet valid')
  }

  // 7. Check audience
  if (payload.aud !== expected_audience) {
    throw new Error('Invalid audience')
  }

  // 8. Check issuer (optional but recommended)
  if (payload.iss !== 'https://trusted-auth.com') {
    throw new Error('Untrusted issuer')
  }

  return payload  // Valid!
}

JWT Pitfalls

1. No Built-In Revocation

JWT is stateless—once issued, valid until expiry. If compromised, can't revoke.

Workarounds:

• Short expiry: 5-15 minutes (limits damage window)
• Blacklist: Store revoked token IDs in Redis (check on every request—defeats stateless benefit)
• Version claim: Include token_version in JWT, store current version in DB, increment on password change/logout

// Token includes version
{
  "sub": "user_123",
  "token_version": 5,
  "exp": 1701234567
}

// User table
user_id | current_token_version
user_123 | 5

// On password change or logout
UPDATE users SET current_token_version = 6 WHERE user_id = 'user_123'

// Validation
jwt_version = token.payload.token_version
db_version = db.query("SELECT current_token_version FROM users WHERE user_id = ?", token.sub)
if (jwt_version < db_version) {
  return error('Token revoked')
}

2. Token Size (HTTP Headers)

JWT can grow large (2-3KB) with many claims. Sent with every request in Authorization header. Impacts bandwidth, especially mobile.

// Small JWT (100 bytes)
{
  "sub": "123",
  "exp": 1701234567
}

// Large JWT (3KB+)
{
  "sub": "user_12345",
  "email": "alice@example.com",
  "name": "Alice Smith",
  "roles": ["admin", "editor", "viewer", "analyst"],
  "permissions": ["read:users", "write:users", "read:posts", ...],  // 100+ permissions
  "organization": {...},  // Nested objects
  "metadata": {...}
}

Solution: Keep JWT minimal (only sub, exp, iat). Fetch full user data from cache/DB.

3. Algorithm Confusion Attack

Attacker changes header from RS256 (asymmetric) to HS256 (symmetric), server verifies with public key as HMAC secret.

// 1. Original token (RS256)
Header: {"alg": "RS256", "typ": "JWT"}
Signature: RSA signature with private key

// 2. Attacker changes algorithm
Header: {"alg": "HS256", "typ": "JWT"}  ← Changed!
Payload: {... attacker payload ...}
Signature: HMAC(header + payload, public_key)  ← Uses public key as secret!

// 3. Vulnerable server
algorithm = jwt.header.alg  // HS256 (attacker-controlled)
if (algorithm === 'HS256') {
  verify_hmac(jwt, public_key)  // ❌ Uses public key as HMAC secret
} else if (algorithm === 'RS256') {
  verify_rsa(jwt, public_key)
}

Prevention: Never trust alg header. Enforce expected algorithm.

// ✓ Secure validation
EXPECTED_ALGORITHM = 'RS256'

header = decode_header(jwt)
if (header.alg !== EXPECTED_ALGORITHM) {
  throw new Error('Invalid algorithm')
}

// Now verify with correct method
verify_rsa(jwt, public_key)

4. Sensitive Data Leakage

JWT payload is Base64-encoded, NOT encrypted. Anyone can decode it.

// ❌ BAD: Sensitive data in JWT
{
  "sub": "user_123",
  "ssn": "123-45-6789",  // ← Visible to anyone who sees token!
  "credit_card": "4111111111111111"
}

// ✓ GOOD: Only non-sensitive identity
{
  "sub": "user_123",
  "email": "alice@example.com",  // OK (not secret)
  "exp": 1701234567
}

Rule: Only include data you'd put in a URL query parameter. If it's sensitive, don't put it in JWT.

Access Token vs Refresh Token vs ID Token

JWT vs Session Comparison

6. Authorization Models

6.1 RBAC (Role-Based Access Control)

Users assigned to roles, roles have permissions. Check user's roles to determine access.

Architecture

Database Schema

-- Users
users
  id | email
  1  | alice@example.com
  2  | bob@example.com

-- Roles
roles
  id | name
  1  | admin
  2  | editor
  3  | viewer

-- User-Role Assignment (many-to-many)
user_roles
  user_id | role_id
  1       | 1        -- Alice is admin
  2       | 2        -- Bob is editor

-- Permissions
permissions
  id | name
  1  | create:users
  2  | delete:users
  3  | edit:posts

-- Role-Permission Assignment
role_permissions
  role_id | permission_id
  1       | 1              -- Admin can create users
  1       | 2              -- Admin can delete users
  2       | 3              -- Editor can edit posts

Authorization Check

function canUserPerform(user_id, permission) {
  // 1. Get user's roles
  roles = db.query(`
    SELECT role_id FROM user_roles WHERE user_id = ?
  `, user_id)

  // 2. Get permissions for those roles
  permissions = db.query(`
    SELECT p.name FROM permissions p
    JOIN role_permissions rp ON p.id = rp.permission_id
    WHERE rp.role_id IN (?)
  `, roles)

  // 3. Check if permission exists
  return permissions.includes(permission)
}

// Usage
if (canUserPerform(user_id, 'delete:users')) {
  deleteUser(target_user_id)
} else {
  return 403 Forbidden
}

Role Hierarchy

Roles can inherit from other roles. Admin inherits all Editor permissions.

-- Role hierarchy table
role_hierarchy
  role_id | inherits_from_role_id
  1       | 2                      -- Admin inherits Editor
  2       | 3                      -- Editor inherits Viewer

-- Query with hierarchy
WITH RECURSIVE role_hierarchy_cte AS (
  -- Base: direct roles
  SELECT role_id FROM user_roles WHERE user_id = ?

  UNION

  -- Recursive: inherited roles
  SELECT rh.inherits_from_role_id
  FROM role_hierarchy rh
  JOIN role_hierarchy_cte rhc ON rh.role_id = rhc.role_id
)
SELECT DISTINCT p.name
FROM permissions p
JOIN role_permissions rp ON p.id = rp.permission_id
JOIN role_hierarchy_cte rhc ON rp.role_id = rhc.role_id

RBAC Pros & Cons

6.2 ABAC (Attribute-Based Access Control)

Policy-driven. Evaluate attributes of user, resource, action, and environment to make decision.

Architecture

Policy Example (XACML-style)

// Policy: Employee can edit document if they own it OR are in same department
{
  "policy_id": "allow-edit-own-or-dept-doc",
  "effect": "Allow",
  "target": {
    "action": "edit",
    "resource_type": "document"
  },
  "condition": {
    "or": [
      {
        "attribute": "resource.owner_id",
        "operator": "equals",
        "value": "user.id"
      },
      {
        "attribute": "resource.department",
        "operator": "equals",
        "value": "user.department"
      }
    ]
  }
}

// Policy: Block access outside business hours
{
  "policy_id": "block-after-hours",
  "effect": "Deny",
  "target": {
    "action": "*",
    "resource_type": "*"
  },
  "condition": {
    "or": [
      {
        "attribute": "environment.hour",
        "operator": "less_than",
        "value": 9
      },
      {
        "attribute": "environment.hour",
        "operator": "greater_than",
        "value": 17
      }
    ]
  }
}

Evaluation Flow

Real-World Example (AWS IAM Policy)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"  ← Only from office IP
        },
        "DateGreaterThan": {
          "aws:CurrentTime": "2024-01-01T00:00:00Z"
        },
        "DateLessThan": {
          "aws:CurrentTime": "2024-12-31T23:59:59Z"
        }
      }
    }
  ]
}

ABAC Pros & Cons

6.3 ReBAC (Relationship-Based Access Control)

Model permissions as relationships in a graph. Used by Google (Zanzibar), Airbnb, Dropbox.

Architecture (Google Zanzibar)

Tuple Format

Relationships stored as tuples: (object, relation, subject)

// Tuple structure
(doc:financial-report, owner, user:alice)
(doc:financial-report, parent, folder:2024-reports)
(folder:2024-reports, viewer, group:eng-team)
(group:eng-team, member, user:bob)

// Query: Can bob view financial-report?
Check(doc:financial-report, viewer, user:bob)

// Zanzibar evaluates:
1. Is bob directly viewer of doc? → No
2. Is doc's parent folder visible to bob? → Check folder
3. Is eng-team viewer of folder? → Yes
4. Is bob member of eng-team? → Yes
Result: ALLOW

Real-World Schema (SpiceDB / AuthZed)

// Schema definition
definition user {}

definition group {
  relation member: user
}

definition folder {
  relation viewer: user | group#member
  relation editor: user | group#member
}

definition document {
  relation parent: folder
  relation owner: user
  relation viewer: user | group#member

  // Computed permission: can view if owner OR parent folder viewer
  permission view = owner + parent->viewer
  permission edit = owner
}

// Tuples (relationship instances)
document:financial-report#owner@user:alice
document:financial-report#parent@folder:2024-reports
folder:2024-reports#viewer@group:eng-team#member
group:eng-team#member@user:bob

// Query API
CheckPermission(document:financial-report, view, user:bob)
→ ALLOWED (via parent folder → group membership)

Advantages Over RBAC

• Resource ownership: "Can edit if you're the owner" naturally modeled
• Hierarchies: Folder permissions inherit to documents
• Group membership: Add user to group, instantly get all group's permissions
• Delegation: Share document with someone, they can share with others

ReBAC Pros & Cons

6.4 ACL (Access Control Lists)

Simple list attached to each resource specifying who can access it.

Structure

// File system ACL (Unix)
file: /home/alice/document.txt
owner: alice (rwx)
group: staff (r--)
other: (---)

// AWS S3 Bucket ACL
{
  "Owner": {"ID": "alice123"},
  "Grants": [
    {
      "Grantee": {"Type": "User", "ID": "bob456"},
      "Permission": "READ"
    },
    {
      "Grantee": {"Type": "Group", "URI": "http://acs.amazonaws.com/groups/global/AllUsers"},
      "Permission": "READ"  ← Public read
    }
  ]
}

// Database table ACL
resource_id | user_id | permission
document_1  | alice   | owner
document_1  | bob     | read
document_1  | charlie | write

Authorization Check

function canAccess(user_id, resource_id, required_permission) {
  acl = db.query(`
    SELECT permission FROM acl
    WHERE resource_id = ? AND user_id = ?
  `, resource_id, user_id)

  return acl.permission >= required_permission
}

// Usage
if (canAccess(user_id, 'document_1', 'write')) {
  updateDocument('document_1', new_content)
}

ACL Pros & Cons

Comparison Table: When to Use Each

Decision Tree

7. Encryption

7.1 Symmetric Encryption

Same key for encryption and decryption. Fast, but key distribution is the challenge.

AES (Advanced Encryption Standard)

Industry standard since 2001. Block cipher (encrypts 128-bit blocks).

Modes of Operation

AES-GCM Anatomy

// AES-256-GCM encryption
key = random_bytes(32)        // 256-bit key
nonce = random_bytes(12)      // 96-bit nonce (MUST be unique per message)
plaintext = "Sensitive data"
aad = "user_id:12345"         // Additional Authenticated Data (optional)

ciphertext, tag = AES_GCM_encrypt(key, nonce, plaintext, aad)

// Ciphertext: encrypted data
// Tag: authentication tag (128 bits) proves integrity

// Decryption
plaintext = AES_GCM_decrypt(key, nonce, ciphertext, tag, aad)
// If tag doesn't match → decryption fails (tampered data)

AEAD (Authenticated Encryption with Associated Data): Provides both confidentiality (encryption) and integrity (authentication). AES-GCM is an AEAD cipher.

ChaCha20-Poly1305

Alternative to AES-GCM. Faster on mobile (no hardware AES), constant-time (resistant to timing attacks).

7.2 Asymmetric Encryption

Public key encrypts, private key decrypts. Solves key distribution but much slower.

RSA (Rivest-Shamir-Adleman)

RSA Usage: Hybrid Encryption

RSA is slow for large data. Use RSA to encrypt symmetric key, use symmetric key to encrypt data.

ECDSA (Elliptic Curve Digital Signature Algorithm)

Smaller keys, faster than RSA for signatures. Used in TLS, Bitcoin, SSH.

Ed25519 (EdDSA with Curve25519)

Modern signing algorithm. Faster than ECDSA, simpler implementation, resistant to side-channel attacks.

// Key generation
private_key = random_bytes(32)  // 256 bits
public_key = derive_public_key(private_key)

// Signing
message = "Transfer $100 to Bob"
signature = Ed25519_sign(private_key, message)

// Verification
is_valid = Ed25519_verify(public_key, message, signature)

RSA vs ECDSA vs Ed25519

7.3 Encryption at Rest

Disk Encryption (Full-Disk)

Encrypts entire disk. Protects if physical disk is stolen. Key stored in TPM or entered at boot.

Technologies: BitLocker (Windows), FileVault (macOS), LUKS (Linux)

Pros: Transparent, protects all data
Cons: Doesn't protect if disk is mounted (attacker with shell access sees plaintext)

Database Encryption (Column-Level)

Encrypt specific columns (e.g., SSN, credit card). Allows indexing on non-encrypted columns.

-- Encrypted columns
users
  id  | email              | ssn_encrypted
  1   | alice@example.com  | 0x9f86d081...  ← AES-GCM(SSN)

-- Application layer encryption
plaintext_ssn = "123-45-6789"
encrypted_ssn = AES_encrypt(plaintext_ssn, data_encryption_key)
db.insert("INSERT INTO users (email, ssn_encrypted) VALUES (?, ?)", email, encrypted_ssn)

-- Reading
encrypted_ssn = db.query("SELECT ssn_encrypted FROM users WHERE id = 1")
plaintext_ssn = AES_decrypt(encrypted_ssn, data_encryption_key)

Application-Level Encryption

Encrypt before writing to storage. Most flexible, requires key management.

Encryption at Rest: Comparison

7.4 Encryption in Transit (TLS)

TLS (Transport Layer Security) encrypts data between client and server. Prevents eavesdropping and tampering.

TLS Handshake (Simplified)

Why Hybrid Crypto?

• Asymmetric (RSA/ECDHE): Exchange session key securely (slow, only at handshake)
• Symmetric (AES): Encrypt bulk data (fast, after handshake)

TLS 1.3 Improvements

Forward Secrecy

Even if private key is compromised later, past sessions can't be decrypted. Achieved with ephemeral key exchange (ECDHE).

7.5 End-to-End Encryption (E2EE)

Only sender and recipient can decrypt. Server can't read content (zero-knowledge).

Signal Protocol (Double Ratchet)

Used by Signal, WhatsApp, Facebook Messenger (secret chats).

E2EE Challenges

• Key Exchange: How do Alice and Bob share keys securely? (Pre-keys uploaded to server)
• Trust: How does Alice know she has Bob's real key? (Safety numbers, out-of-band verification)
• Multi-Device: Alice has phone + laptop. How to decrypt on both? (Device-specific keys, or backup key)
• Search: Server can't search encrypted messages. (Client-side search only)
• Recovery: Lose key = lose all messages. (No password reset!)

7.6 Key Management

Key Hierarchy (Envelope Encryption)

Use master key to encrypt data keys, data keys to encrypt data. Rotating master key doesn't require re-encrypting all data.

// Encryption
data_key = random_bytes(32)  // Generate random AES-256 key
encrypted_data = AES_encrypt(plaintext, data_key)
encrypted_key = KMS.encrypt(data_key)  // Encrypt key with master key

store_in_db(encrypted_data, encrypted_key)

// Decryption
encrypted_key = db.get('encrypted_key')
data_key = KMS.decrypt(encrypted_key)  // Decrypt with master key
plaintext = AES_decrypt(encrypted_data, data_key)

Key Rotation

Regularly change keys to limit damage if compromised.

KMS (Key Management Service)

HSM (Hardware Security Module)

Tamper-resistant hardware for storing keys. Keys never leave HSM in plaintext.

• FIPS 140-2 Level 3/4: Government-grade (physical tamper detection)
• Use Cases: Root CA keys, payment processing (PCI DSS), signing certificates
• Cloud HSM: AWS CloudHSM, Azure Dedicated HSM (you manage keys, cloud can't access)

8. Mutual TLS (mTLS)

Both client and server authenticate with certificates. Standard TLS = server proves identity, mTLS = both prove identity.

Standard TLS vs mTLS

mTLS Handshake

Certificate Lifecycle

1. Certificate Generation (CSR)

// Generate private key
openssl genrsa -out client.key 2048

// Create Certificate Signing Request (CSR)
openssl req -new -key client.key -out client.csr \
  -subj "/CN=client.example.com/O=MyOrg/C=US"

// Submit CSR to CA
// CA signs CSR with its private key → Client Certificate

2. Certificate Signing (CA)

// CA signs the CSR
openssl x509 -req -in client.csr \
  -CA ca.crt -CAkey ca.key \
  -out client.crt \
  -days 365 \
  -sha256

// Result: client.crt (signed certificate)
// Contains: client's public key + CA's signature

3. Certificate Verification (Server)

// Server verifies client certificate
1. Check signature (signed by trusted CA?)
   verify(client.crt.signature, ca.public_key) == true

2. Check validity period
   now >= client.crt.valid_from && now <= client.crt.valid_to

3. Check revocation (CRL or OCSP)
   is_revoked(client.crt.serial_number) == false

4. Check usage
   client.crt.ext_key_usage includes "TLS Client Authentication"

5. Verify client possesses private key
   Client signs handshake with private key
   Server verifies signature with client.crt.public_key

Certificate Revocation

CRL (Certificate Revocation List)

CA publishes list of revoked certificate serial numbers. Server downloads periodically.

Pros: Simple
Cons: CRL can be huge, stale (updated daily/weekly), requires download

OCSP (Online Certificate Status Protocol)

Server queries CA in real-time: "Is cert 456 revoked?"

Pros: Real-time, smaller payloads
Cons: Latency (extra network call), OCSP responder can be DDoS'd, privacy (CA sees who's checking what)

OCSP Stapling

Server fetches OCSP response, includes it in TLS handshake. No client→OCSP call.

// Server caches OCSP response
Server → OCSP: Is my cert valid?
OCSP → Server: Signed response (valid 7 days)

// Client connects
Client → Server: ClientHello
Server → Client: Certificate + OCSP Response (stapled)
Client: Verify OCSP response signature (CA signed it)
        ✓ Cert is valid, no need to contact OCSP

Service Mesh mTLS

Automatic mTLS between all services. Sidecar proxy handles certificates.

Architecture (Istio / Linkerd)

SPIFFE/SPIRE

Standard for service identity. SPIFFE = spec, SPIRE = implementation.

// SPIFFE ID (unique service identity)
spiffe://trust-domain/namespace/service-a

// SPIRE issues short-lived X.509 certs
- Workload requests cert from SPIRE agent
- Agent verifies workload identity (k8s service account)
- Agent requests cert from SPIRE server
- Server issues cert with SPIFFE ID (TTL: 1 hour)
- Workload uses cert for mTLS
- Cert auto-rotates before expiry

Benefits

• Zero trust: Every service authenticates every call
• Automatic rotation: Short-lived certs (hours), no manual renewal
• No secrets in config: Certs issued at runtime
• Observability: Service mesh logs all mTLS connections

When to Use mTLS

9. Zero Trust Architecture

"Never trust, always verify." Traditional perimeter security assumes inside = trusted. Zero trust assumes breach and verifies every request.

Traditional vs Zero Trust

Core Principles

1. Verify Explicitly

Authenticate and authorize based on all available data: identity, location, device, risk.

// Every request evaluated
if (!authenticated(request)) return 401
if (!authorized(user, resource, action)) return 403
if (!device_trusted(request.device_id)) return 403
if (risk_score(request) > threshold) require_mfa()

2. Least Privilege Access

Grant minimum permissions needed. Just-in-time (JIT) access.

// Traditional: Always-on admin access
user.role = 'admin'  // Forever

// Zero Trust: Temporary elevated access
grant_access(user, 'admin', duration='1 hour', reason='incident-123')

// Access auto-expires
// Approval workflow for sensitive operations

3. Assume Breach

Design for inevitable compromise. Minimize blast radius, detect quickly, contain.

• Microsegmentation: Firewall between every service (not just perimeter)
• Encryption everywhere: TLS for all traffic (internal + external)
• Audit everything: Log every access, detect anomalies
• Immutable infrastructure: Rebuild, don't patch (no persistent compromise)

BeyondCorp (Google's Implementation)

Key Components

Microsegmentation

Divide network into small zones. Firewall between each zone. Limits lateral movement.

Implementation

// Kubernetes NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: service-b-allow-from-a
spec:
  podSelector:
    matchLabels:
      app: service-b
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: service-a
    ports:
    - protocol: TCP
      port: 8080

// Result: Only service-a can reach service-b
// All other traffic denied by default

Zero Trust for APIs

Zero Trust Maturity Model

Zero Trust: Production Implementation Challenges

Implementing zero trust in production is hard. Here are the real operational challenges and their solutions:

Challenge 1: Certificate Rotation Failures

Problem: If a certificate expires, service-to-service calls fail completely. In a microservices architecture with 100+ services using mTLS, a single cert expiry can cascade into a full outage.

Solution:

• Auto-renewal 30 days before expiry: Use cert-manager (Kubernetes) or Vault PKI to automatically renew certs
• Monitoring: Alert on certs expiring within 7 days (Prometheus: x509_cert_expiry < 7*24*3600)
• Grace period: Accept certs up to 24 hours after expiry (not recommended for production, but helpful during incidents)
• Canary rotation: Rotate 1% of services first, monitor error rates, then roll out

\ cert-manager Kubernetes config
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: service-a-tls
spec:
  secretName: service-a-tls
  duration: 720h  # 30 days
  renewBefore: 240h  # Renew 10 days before expiry
  issuerRef:
    name: internal-ca
    kind: ClusterIssuer

Challenge 2: Policy Engine as Bottleneck

Problem: Every request needs an authorization check. At 100,000 requests/sec, the policy engine must handle 100,000 authorization decisions/sec. A centralized policy engine becomes a bottleneck and single point of failure.

Solution:

• Cache decisions: Cache authZ results for 5-60 seconds per (user, resource, action) tuple
• OPA as sidecar: Deploy Open Policy Agent as sidecar in each pod (local evaluation, no network hop)
• Policy compilation: Pre-compile policies to WebAssembly for 10x faster evaluation
• Tiered caching: L1 = in-memory (1ms), L2 = Redis (5ms), L3 = policy engine (20ms)

\ OPA sidecar with caching (Kubernetes pod)
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    image: myapp:v1
  - name: opa
    image: openpolicyagent/opa:latest
    args:
    - "run"
    - "--server"
    - "--addr=localhost:8181"
    - "--set=decision_logs.console=true"
    - "--set=caching.inter_query_builtin_cache.max_size_bytes=104857600"  // 100MB cache

Challenge 3: Device Trust Failure

Problem: If the MDM (Mobile Device Management) service goes down, you can't verify device posture. Do you deny all access (availability hit) or allow without device check (security risk)?

Solution:

• Grace period: Use last-known-good device state for 4 hours if MDM is unreachable
• Fallback to MFA: If device trust fails, require additional MFA challenge (FIDO2 key)
• Tiered access: Allow read-only access without device trust, require full trust for write operations
• Redundant MDM: Deploy MDM in multiple regions, failover on 503 errors

Challenge 4: Lateral Movement Detection

Problem: Even with zero trust, once an attacker compromises a service, they can move laterally between services. Traditional firewalls don't stop east-west traffic within a cluster.

Solution:

• Microsegmentation: NetworkPolicies (Kubernetes) or security groups (AWS) to deny-by-default and allow-list only necessary service-to-service paths
• Service identity (SPIFFE): Each service has a cryptographic identity, verified on every call
• Anomaly detection: Alert on unusual service-to-service patterns (e.g., service-a calls service-z for the first time, service-b has 90% authZ failures)
• Honeypot services: Deploy fake services that should never be called; if they receive traffic, it's an attack

\ Kubernetes NetworkPolicy: service-a can only talk to service-b
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: service-b-ingress
spec:
  podSelector:
    matchLabels:
      app: service-b
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: service-a
    ports:
    - protocol: TCP
      port: 8080

\ Result: service-c, service-d, etc. CANNOT reach service-b
\ Attacker compromising service-c cannot pivot to service-b

BeyondCorp Components Table

Google's BeyondCorp implementation (reference architecture):

10. API Security

10.1 Rate Limiting

Prevent abuse by limiting requests per time window. Multiple dimensions: per-user, per-IP, per-endpoint.

Algorithms

Token Bucket

Bucket holds tokens. Each request consumes token. Tokens refill at constant rate. Allows bursts.

class TokenBucket:
  def __init__(self, capacity, refill_rate):
    self.capacity = capacity
    self.tokens = capacity
    self.refill_rate = refill_rate  // per second
    self.last_refill = now()

  def allow_request(self):
    // Refill tokens
    elapsed = now() - self.last_refill
    self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)
    self.last_refill = now()

    // Check token
    if self.tokens >= 1:
      self.tokens -= 1
      return True
    return False  // Rate limited

Sliding Window

Count requests in rolling time window. More accurate than fixed window.

// Fixed Window (inaccurate)
Window 1 (0-60s):  100 requests at t=59s  ✓ Allowed
Window 2 (60-120s): 100 requests at t=61s ✓ Allowed
// 200 requests in 2 seconds! Burst at boundary.

// Sliding Window (accurate)
window_size = 60s
max_requests = 100

requests_in_last_60s = count_requests(now() - 60s, now())
if requests_in_last_60s < max_requests:
  allow()
else:
  reject()

Multi-Tier Rate Limiting

Implementation (Redis)

// Token bucket with Redis
key = f"rate_limit:{user_id}"

// Get current tokens
tokens = redis.get(key) or bucket_capacity
last_refill = redis.get(f"{key}:last_refill") or now()

// Refill
elapsed = now() - last_refill
tokens = min(bucket_capacity, tokens + elapsed * refill_rate)

// Check
if tokens >= 1:
  redis.set(key, tokens - 1)
  redis.set(f"{key}:last_refill", now())
  return allow()
else:
  return reject(429, headers={
    'X-RateLimit-Limit': bucket_capacity,
    'X-RateLimit-Remaining': 0,
    'X-RateLimit-Reset': next_refill_time
  })

10.2 Input Validation & Sanitization

Validation Rules

• Type checking: email = string, age = int > 0
• Length limits: username max 50 chars, bio max 500
• Format validation: email regex, UUID format, phone number
• Whitelist: Accept only known-good values (enum: ['admin', 'user'])
• Blacklist (weak): Reject known-bad values (easily bypassed)

// ❌ BAD: No validation
function updateUser(data) {
  db.query(`UPDATE users SET name = '${data.name}' WHERE id = ${data.id}`)
}

// ✓ GOOD: Validate + parameterized query
function updateUser(data) {
  // Validate
  if (typeof data.id !== 'number' || data.id <= 0) throw Error('Invalid ID')
  if (typeof data.name !== 'string' || data.name.length > 100) throw Error('Invalid name')
  if (!/^[a-zA-Z0-9\s]+$/.test(data.name)) throw Error('Name contains invalid characters')

  // Parameterized query (prevents SQL injection)
  db.query('UPDATE users SET name = ? WHERE id = ?', [data.name, data.id])
}

SQL Injection Prevention

// ❌ VULNERABLE
query = f"SELECT * FROM users WHERE username = '{username}'"
// Attacker input: username = "admin' OR '1'='1"
// Query: SELECT * FROM users WHERE username = 'admin' OR '1'='1'
// Result: Returns all users!

// ✓ SAFE: Parameterized query
query = "SELECT * FROM users WHERE username = ?"
db.execute(query, [username])
// Library escapes input, treats as literal string

10.3 CORS, CSRF, XSS

CORS (Cross-Origin Resource Sharing)

Browser security: prevent site A from reading responses from site B (unless B allows it).

// Browser at https://example.com
fetch('https://api.bank.com/balance')

// Server response headers
Access-Control-Allow-Origin: https://example.com  // Allow this origin
Access-Control-Allow-Credentials: true            // Allow cookies
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Authorization

// Without CORS headers → Browser blocks response

Access-Control-Allow-Origin: *  // Allow any origin!
Access-Control-Allow-Credentials: true  // + Send cookies!
// = Any website can read your bank balance if you're logged in

CSRF (Cross-Site Request Forgery)

See Session Management section. Prevention: SameSite cookies + CSRF tokens.

XSS (Cross-Site Scripting)

Attacker injects malicious JavaScript into your site.

// ❌ VULNERABLE
comment = request.body.comment
html = f"
{comment}
"  // Directly inserted

// Attacker input:
comment = ""
// Result: Your JavaScript runs on victim's browser, steals cookies

// ✓ SAFE: Escape HTML
import html
comment = html.escape(request.body.comment)  // <script> instead of 



    function toggleTheme() {
      const html = document.documentElement;
      const currentTheme = html.getAttribute('data-theme');
      const newTheme = currentTheme === 'dark' ? 'light' : 'dark';
      html.setAttribute('data-theme', newTheme);
      mermaid.initialize({ startOnLoad: true, theme: newTheme });
      location.reload();
    }