Account Security 101

Note: Narrative vignettes are fictional composites for teaching purposes. Last updated: 2025-08-26 (ET) · Estimated time: 5–7 min

Most ATO war stories start with stolen passwords—this one starts with a help-desk badge.

1. The Story – When a Help‑Desk Intern Became a "Bank President"

Tuesday, 09:23 AM – Senior fraud analyst Jennifer Walsh sees an alert: help‑desk intern Michael Chen just approved a $2.7 USD million wire to a crypto exchange (an irreversible cash-out channel). Must be a glitch; Michael only resets passwords… right?

Jennifer checks the logs. Michael's login passed MFA and, shockingly, carried wire approval rights. She dives into the IAM audit trail (Identity and Access Management system, a ledger of every login, role grant, and permission change) and finds a slow-burn nightmare. Over six months an attacker quietly hijacked Michael's credentials, stacking roles (adding them one by one) and permission creeping their way to executive power.

By 14:45 Jennifer confirms Michael is a victim. The attacker weaponised his account through privilege escalation. Since every change was logged as "approved," the fraud team's customer‑centric rules never fired.

---

2. Six‑Month Escalation Timeline

Scenario timeline values are illustrative (fictional).

CSR = Customer Service Representative

---

3. Core Concepts

3.1 Authentication (AuthN) vs Authorization (AuthZ)

Simple auth flow

Loading diagram...

1. AuthN check — user proves identity (password and MFA).
2. AuthZ check — system validates the user's role permissions.
3. Action — approve the wire if the role allows it; otherwise block and alert.

Takeaway: Perfect AuthN can't save you if AuthZ silently expands.

3.2 Role‑Based Access Control (RBAC)

1. Define roles → Help Desk, CSR, Loan Officer
2. Attach permissions → reset password, approve loan
3. Assign users → place staff in roles

Failure patterns Role confusion (blurry job lines), permission creep (rights never revoked), role stacking (toxic combos), ghost accounts (employees who left)

Guard rails Least Privilege — grant only today's access Segregation of Duties (SoD) — no user should both create and approve a high-risk action

Joiner → Mover → Leaver lifecycle (JML / IGA) Grant starter role, adjust on job change, revoke within 24 h of exit. Quarterly recertification curbs permission creep and works for ABAC too.

3.3 Privilege Escalation Basics

Red flags: gradual role adds, sudden high‑value access, out‑of‑hours grants.

3.4 UI vs API Paths (and BOLA)

Customers and attackers reach your service through the UI or via API calls. API endpoints often expose BOLA (Broken Object Level Authorisation): /accounts/123 → /accounts/124 lets an attacker change an ID to access another customer's data.

BOLA Attack Example:

Loading diagram...

The Problem: The API checks who you are (authentication) but not whether you own that specific resource (authorization).

Design note: Apply the same AuthZ checks to UI and API. A wire‑approval API must enforce the same role as the UI button.

---

4. Common Security Failures and Why They Happen

Understanding these failure patterns helps you recognize vulnerabilities before they become incidents:

Permission Creep

• Users accumulate privileges over time but never lose old ones
• Job changes add new roles without removing previous access
• Result: Help desk intern with executive wire approval rights

Role Stacking

• Users granted multiple overlapping roles instead of one comprehensive role
• Each role seems harmless individually but combined creates dangerous permissions
• Result: Customer service + temp admin + wire access = full system control

Ghost Accounts

• Former employees retain active accounts after departure
• Service accounts with unclear ownership and excessive permissions
• Result: Dormant accounts become attack vectors

Broken Segregation of Duties

• Single user can both initiate AND approve high-risk transactions
• No oversight or approval workflow for sensitive actions
• Result: One compromised account can cause maximum damage

---

5. Why These Fundamentals Matter for Fraud Analysts

Understanding authentication and authorization isn't just theoretical. It's the foundation of effective fraud investigation:

In Payment Fraud

• Merchant accounts use both authentication (login credentials, MFA) and authorization (who can update bank details, process refunds, access transaction data)
• Understanding both helps you investigate cases where criminals compromise merchant accounts to redirect payments or access customer data

In Account Security

• User accounts have authentication methods (passwords, MFA) and authorization levels (view-only, admin, etc.)
• Knowing how these work helps you investigate suspicious account activity

In System Design

• Every fraud prevention system relies on proper authentication and authorization
• Understanding the fundamentals helps you evaluate security controls and recommend improvements

---

6. Key Takeaways for Fraud Professionals

Master These Fundamentals

• Authentication verifies identity - "Who are you?"
• Authorization controls permissions - "What can you do?"
• Both must work together for effective security

Remember the Common Failures

• Permission creep - users accumulate too many privileges over time
• Role stacking - multiple roles create dangerous permission combinations
• Broken segregation - single users can both create and approve transactions
• Ghost accounts - former employees or unclear service accounts

Apply to Your Daily Work

• Every fraud investigation involves authentication and authorization concepts
• Understanding these fundamentals helps you evaluate security controls
• Use this knowledge to recommend better fraud prevention systems

---

7. Key Terms

For complete definitions of authentication and ATO terminology, see the ATO Glossary.

Core concepts from this module:

• AuthN vs AuthZ - Identity verification vs permission checking
• RBAC - Role-Based Access Control for managing user permissions
• BOLA - Broken Object Level Authorization (API security vulnerability)
• Permission creep - Gradual accumulation of privileges over time
• Privilege escalation - Gaining higher permissions than originally granted

---

All names, companies, and incidents are fictional and provided for educational use only.

---

Next module → ATO 101 — How criminals exploit authentication and authorization weaknesses in account takeover attacks.

---

Quiz (5 questions)

Q1. Which scenario best illustrates privilege escalation? A. A user resets their forgotten password B. A help‑desk role gains access to approve wires after roles are combined C. A customer changes their email address D. A session times out after inactivity

Answer: B — Combining low-risk permissions can create unintended high-impact access.

Q2. What control most directly limits credential‑stuffing risk? A. Block all logins from new devices B. Rate‑limit and require multi‑factor auth after failures C. Auto‑unlock accounts after 5 minutes D. Force password rotation monthly

Answer: B — Rate‑limiting plus step‑up MFA reduces automated guessing success (see OWASP).

Q3. When documenting incidents, which time notation should you use here? A. EST/EDT B. Local time only C. ET D. GMT

Answer: C — We standardize to ET to avoid seasonal confusion.

Q4. Which is the safest way to grant temporary elevated access? A. Shared admin account B. Permanent role change C. Just‑in‑time access with approval and auto‑expiry D. Send credentials over email

Answer: C — JIT access limits exposure and creates an audit trail.

Q5. What is the main signal of lateral movement in account security logs? A. Repeated password resets B. Sudden access to unrelated systems or data C. Profile picture change D. Frequent logouts

Answer: B — Accessing new systems/data unexpectedly suggests privilege misuse.

Known limitations

• Story vignettes are fictional; dollar figures and times in stories are illustrative.
• Some vendor‑specific behaviors vary by implementation; standards links are provided for general guidance.
• Statistics cited reflect their sources' methodologies and reporting periods.

See also

• Account Takeover (ATO 101)
• Attack Methods
• Advanced Authentication
• Glossary

---

Navigation: You are here: Account Security 101 · Next → Ato 101