All Categories
How authentication and authorization protect accounts, and how attackers bypass each layer
Account Security Fundamentals
The Story
Monday, 2:47 PM. Senior fraud analyst Jennifer Walsh stares at an alert that makes no sense. Help desk intern Michael Chen just approved a $2.7 million wire transfer to a cryptocurrency exchange.
Michael resets passwords. He doesn't touch wires. He definitely can't approve seven-figure transactions.
Jennifer pulls the IAM audit trail and finds a six-month nightmare:
| Date | What Changed | What the Attacker Did Next |
|---|---|---|
| Jan 4 | Added "view wire queue" permission | Observed approval patterns and timing |
| Feb 19 | Added "export CSV" permission | Downloaded 3,000 customer records |
| Apr 7 | Role changed to CSR-Temp | Tested with a $5 loan approval |
| May 22 | Added "approve wire" permission | Tested with a $2,700 wire |
| Jun 30 | Executive role added | Approved $2.7 million wire |
Michael's credentials were stolen months ago. Looking back at authentication logs, Jennifer sees that every single login passed MFA. The attacker had Michael's password and access to his phone (probably through a SIM swap, she suspects). Authentication was never the problem.
The problem was authorization. But how did a help desk intern end up with executive powers?
Jennifer digs deeper. The bank's access request system lets employees submit tickets for additional permissions. A manager is supposed to review and approve each request. But the system has a flaw: if a request sits unreviewed for 72 hours, it auto-approves. The attacker submitted permission requests late Friday afternoons, knowing they'd slip through over the weekend.
Each request was small and plausible: "Need wire queue visibility for a customer complaint investigation." "Need CSV export for a compliance audit." The requests referenced real ticket numbers from cases Michael had worked on. By the time the wire went through, the attacker had spent six months exploiting a broken process that nobody was watching.
The $2.7 million was already in a mixing service. It wasn't coming back.
This story is fictional, but the patterns are real.
Why This Matters
In ATO 101, you learned how attackers obtain credentials and take over accounts. But getting in is only half the story. What happens next depends on two things: what the attacker can prove (authentication) and what they're allowed to do (authorization).
These two concepts are constantly confused, even by security professionals. Understanding the difference is essential for investigating account compromises. When you're tracing how an attacker turned a compromised help desk account into a $2.7 million theft, you need to know which security layer failed and when.
This article covers how accounts are protected and how each protection layer can be bypassed or abused.
Authentication: Proving Who You Are
Authentication answers one question: "Are you who you claim to be?"
When you log into any system, you're making an identity claim. Authentication is the process of proving that claim is true. Most authentication relies on one or more of three factor types:
| Factor Type | What It Means | Examples |
|---|---|---|
| Knowledge | Something you know | Passwords, PINs, security questions |
| Possession | Something you have | Phone, hardware key, smart card |
| Inherence | Something you are | Fingerprint, face, voice |
Single-factor authentication uses just one (usually a password). Multi-factor authentication (MFA) combines two or more, making compromise harder because an attacker needs to steal multiple things.
Passwords: The Weakest Link
Passwords remain the most common authentication factor, and the most frequently compromised. You saw in ATO 101 how credential stuffing works: attackers test stolen username/password combinations across sites, exploiting the fact that people reuse passwords.
But password problems go deeper than reuse:
Weak passwords remain common despite decades of warnings. "123456" and "password" still appear in breach after breach. Attackers maintain dictionaries of common passwords and run them against targets.
Predictable patterns make supposedly complex passwords guessable. "Summer2024!" follows a pattern (Season + Year + Symbol) that attackers know to try. So does "CompanyName123" for corporate accounts.
Password storage failures mean that when companies get breached, attackers sometimes get passwords in plaintext or weakly hashed formats that can be reversed.
The fundamental problem: passwords are knowledge that can be stolen, guessed, or extracted from breaches. Once an attacker knows your password, they can use it from anywhere in the world.
Multi-Factor Authentication
MFA adds a second (or third) factor, so stealing a password alone isn't enough. But not all MFA is equally strong.
SMS codes are the weakest form of MFA. Your phone receives a text with a six-digit code. The problem: phone numbers can be stolen through SIM swapping (covered in Attack Methods), and SMS messages can be intercepted. Attackers who compromise your phone number receive your MFA codes.
Time-based one-time passwords (TOTP) use apps like Google Authenticator or Authy. The app and server share a secret key, and both generate the same six-digit code every 30 seconds. This is stronger than SMS because there's no phone number to steal. But TOTP codes can still be phished: if you enter your password and TOTP code on a fake login page, the attacker captures both and uses them immediately on the real site.
Push notifications send an approval request to your phone. You tap "Approve" or "Deny." Convenient, but vulnerable to fatigue attacks: an attacker with your password can spam approval requests at 3 AM until you tap "Approve" just to make it stop. Some push systems now require number matching (enter "47" on your phone to approve) which helps, but determined attackers may still find ways around this through social engineering.
Hardware security keys (YubiKey, Titan Key) are the strongest common MFA factor. You physically insert or tap the key to authenticate. These are phishing-resistant because the key cryptographically verifies it's talking to the legitimate site. A fake login page can't trigger your hardware key because the key checks the site's identity. The weakness: physical theft or loss of the key.
Biometrics (fingerprint, face, voice) are convenient but have unique risks. You can't change your fingerprint if it's compromised. Biometrics can sometimes be spoofed with photos, recordings, or physical replicas. Most systems use biometrics as a convenience layer on top of other factors rather than as the sole authentication method.
Security Questions: The Forgotten Weakness
"What's your mother's maiden name?" Security questions were designed for account recovery but became an authentication factor. The problem: most answers are either publicly discoverable (social media, genealogy sites, public records) or guessable (common pet names, popular first cars).
Attackers research targets on social media to answer security questions. That Facebook post about your first car? Your high school mascot in your profile? Your mother's maiden name on Ancestry.com? All ammunition for bypassing security questions.
Account Recovery: The Backdoor
Every authentication system needs a way to recover access when someone forgets their password or loses their phone. These recovery flows are often the weakest point in the entire system.
Common recovery methods and their vulnerabilities:
| Recovery Method | How Attackers Exploit It |
|---|---|
| Email reset link | Compromise the email account first (email is the "master key" from ATO 101) |
| SMS reset code | SIM swap to receive the code |
| Security questions | Research answers on social media |
| Support call | Social engineer the support agent |
| Backup codes | Find them in password managers or note apps on compromised devices |
| ID verification | Deepfakes and synthetic media |
The recovery flow often has weaker authentication than the primary login. An account that requires a password plus hardware key might allow recovery with just an email link. Attackers target whatever path has the fewest obstacles.
ID Verification and Deepfake Bypasses
High-value accounts increasingly require identity verification for recovery: upload a photo of your government ID, then take a selfie or short video proving you're a real person (liveness detection). The system compares your face to the ID photo.
These checks were designed to stop attackers who only have stolen credentials. But generative AI has changed the equation.
Synthetic ID documents can be created by editing real ID templates with a target's stolen personal information. The result might look authentic enough to pass some automated document verification systems.
Deepfake videos might defeat liveness checks that ask you to blink, smile, or turn your head. An attacker with photos of the target (social media provides plenty) could potentially generate a video that follows the liveness prompts. The quality varies, and more sophisticated liveness systems are harder to fool.
The combination can be powerful: a synthetic ID with the victim's information, plus a deepfake video matching that ID's photo. Some attackers have attempted real-time deepfake software during video calls with support agents, with varying success.
This doesn't mean ID verification is useless. It still raises the bar significantly and stops many attacks. But for sophisticated attackers targeting specific high-value accounts, it may not be the definitive check it was designed to be.
Authorization: Controlling What You Can Do
Authorization answers a different question: "Now that we know who you are, what are you allowed to do?"
This is where Michael Chen's story becomes relevant. The attacker authenticated successfully every time (they had his credentials and MFA access). But the real attack was on authorization: slowly expanding what his account was permitted to do.
The Critical Distinction
| Authentication | Authorization | |
|---|---|---|
| Question answered | "Who are you?" | "What can you do?" |
| What it proves | Identity | Permissions |
| When it fails | Wrong person gets in | Right person does wrong things |
Perfect authentication doesn't protect you if authorization is broken. An attacker with valid credentials (stolen, phished, or bought) passes authentication. The damage they can do depends entirely on what that account is authorized to access.
Access Control Models
Organizations manage authorization through access control systems. The two most common models:
Role-Based Access Control (RBAC) assigns users to roles, and roles have permissions. A "Help Desk" role might include permissions to reset passwords and view basic account info. A "Wire Approver" role includes permissions to approve wire transfers up to a certain limit.
User → Role → Permissions
├── Jennifer → Fraud Analyst → [view transactions, flag accounts, escalate]
├── Michael → Help Desk → [reset passwords, view basic info]
└── Sarah → Wire Approver → [approve wires up to $50K]
RBAC is simple and easy to audit. The weakness: it can become unwieldy when organizations have hundreds of roles, and it doesn't handle context well (same permissions regardless of time, location, or other factors).
Attribute-Based Access Control (ABAC) makes decisions based on attributes of the user, the resource, and the context. Instead of fixed roles, policies evaluate conditions:
IF user.department = "Finance"
AND resource.type = "wire"
AND resource.amount < user.approval_limit
AND time.hour BETWEEN 9 AND 17
AND user.location = "corporate_network"
THEN allow
ABAC is more flexible and context-aware. The weakness: complex policies are harder to understand and audit. Misconfigurations can create unexpected gaps.
Least Privilege and Segregation of Duties
Two principles govern good authorization design:
Least privilege means users get only the minimum permissions needed for their current job. Not permissions they "might need someday." Not permissions from their previous role. Just what they need right now. Michael should never have had wire approval permissions because that wasn't part of his job.
Segregation of duties means no single person controls an entire high-risk process. The person who creates a wire request shouldn't approve it. The person who adds a vendor shouldn't authorize payments to that vendor. This prevents both insider abuse and limits damage from compromised accounts.
Authorization Vulnerabilities
Even well-designed authorization systems develop weaknesses over time:
Privilege escalation is gaining permissions beyond what was intended. It comes in two forms:
| Type | What Happens | Example |
|---|---|---|
| Vertical | Lower-privilege user gains higher privileges | Help desk account gets executive powers |
| Horizontal | Same-level user accesses another user's resources | Customer A views Customer B's account details |
Michael's story was vertical privilege escalation: a low-privilege account accumulated high-privilege permissions.
Privilege escalation can happen through several paths:
- Broken request processes like Michael's case, where access requests auto-approve or skip proper review
- User management flaws where someone with permission to create accounts can assign roles higher than their own
- Misconfigured systems that grant broader access than intended
- Social engineering where attackers convince admins to grant permissions through fake requests
Permission creep happens when users accumulate permissions over time but never lose old ones. Someone who transferred from Finance to Marketing might still have Finance system access years later. After several job changes, a user might have far more access than their current role requires.
Role stacking creates dangerous combinations. Consider three roles that seem reasonable alone:
Role A: Can create wire requests
Role B: Can approve wires under $1,000
Role C: Can modify wire amounts
A + B + C together = Can create a wire, modify the amount, and approve it
No single role allows self-approval of large wires. But someone assigned all three roles can do exactly that.
Ghost accounts are accounts that remain active after employees leave, or service accounts with unclear ownership. Nobody monitors these accounts because nobody owns them. They can become attractive targets for attackers who want persistent access without triggering alerts on real user accounts.
The Joiner-Mover-Leaver Lifecycle
Organizations manage authorization through the employee lifecycle:
| Event | What Should Happen | Typical Timeline |
|---|---|---|
| Joiner | Grant permissions appropriate for starting role | Day 1 |
| Mover | Adjust permissions for new role, revoke old ones | Within 24 hours of transfer |
| Leaver | Revoke all access | Within 24 hours of departure |
The "Mover" stage is where permission creep happens. When someone changes roles, their old permissions should be removed. In practice, this often doesn't happen because it's easier to add access than remove it, and nobody wants to break someone's workflow by accidentally revoking something they still need.
Recertification is the periodic review (usually quarterly) where managers confirm their team members still need their current access levels. This catches permission creep, but only if managers actually review carefully rather than rubber-stamping approvals.
Key Takeaways
- Authentication and authorization solve different problems. Authentication verifies identity (who you are). Authorization controls permissions (what you can do). Compromised credentials bypass authentication, but the damage depends on authorization.
- Not all MFA is equal. SMS codes can be intercepted via SIM swap. TOTP codes can be phished in real-time. Push notifications can be fatigue-attacked. Hardware keys are phishing-resistant but can be physically stolen. Understand the weaknesses of each factor.
- Recovery flows are often the weakest point. An account with strong MFA might allow password reset via email link alone. Attackers target whatever path has the fewest obstacles.
- Authorization vulnerabilities accumulate over time. Permission creep, role stacking, and ghost accounts create gaps that attackers exploit. The attacker in Michael's case spent six months building permissions before striking.
- Privilege escalation turns small compromises into major breaches. A compromised help desk account shouldn't be able to approve million-dollar wires. When it can, authorization has failed.
What's next: The Advanced Authentication article covers modern authentication systems like OAuth, SAML, and SSO, and how they create new attack surfaces. The Attack Methods article explores specific techniques including SIM swapping and social engineering.
Key Terms
| Term | Definition |
|---|---|
| Authentication (AuthN) | The process of verifying identity (proving who you are) |
| Authorization (AuthZ) | The process of verifying permissions (determining what you can do) |
| Multi-factor authentication (MFA) | Requiring two or more authentication factors (knowledge, possession, inherence) |
| TOTP | Time-based one-time password, generated by apps like Google Authenticator |
| Hardware security key | Physical device (YubiKey, Titan Key) that provides phishing-resistant authentication |
| Liveness detection | Identity check requiring real-time actions (blink, turn head) to prove you're not a photo |
| Deepfake | AI-generated synthetic media that mimics a real person's appearance or voice |
| RBAC | Role-Based Access Control: assigning permissions through roles |
| ABAC | Attribute-Based Access Control: permission decisions based on user, resource, and context attributes |
| Least privilege | Principle of granting only minimum necessary permissions |
| Segregation of duties | Principle that no single person should control an entire high-risk process |
| Privilege escalation | Gaining permissions beyond what was intended (vertical or horizontal) |
| Permission creep | Accumulation of permissions over time without removal of old ones |
| Ghost account | Account that remains active without clear ownership or monitoring |
Generated with AI assistance. Reviewed by humans for accuracy.
Test Your Knowledge
Ready to test what you've learned? Take the quiz to reinforce your understanding.