Account Security Fundamentals

Account security rests on two distinct mechanisms: authentication, which proves who is logging in, and authorization, which controls what they can do once inside. Most account-takeover incidents do not fail at authentication alone; they fail because authorization is too generous, recovery flows are too weak, or both. This article covers the authentication factors that protect accounts, the authorization models that limit damage after a compromise, and the specific gaps attackers exploit at each layer.

The Story

Jennifer stared at the alert. Michael Chen, a help desk intern, had just approved a $2.7 million wire to a cryptocurrency exchange.

That didn't make sense. Help desk interns reset passwords. They don't touch wires.

She pulled the IAM audit trail and found a six-month nightmare:

She checked the authentication logs. Every login passed MFA. The attacker had Michael's password and access to his phone. Probably a SIM swap months ago. Authentication was never the problem.

Authorization was the problem.

She dug into the access request system. Employees could submit tickets for additional permissions. Manager review required. But if a request sat unreviewed for 72 hours, it auto-approved.

The attacker had submitted permission requests late Friday afternoons. Small, plausible asks. "Need wire queue visibility for a customer complaint." "Need CSV export for a compliance audit." Each request referenced real ticket numbers from cases Michael had actually worked.

Six months of slow escalation. Nobody watching. By the time the wire went through, a help desk account had executive powers.

The $2.7 million was already in a mixing service.

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. NIST SP 800-63B groups authentication into one or more of three factor types: "something you know," "something you have," and "something you are."^[1]

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.

Why Are Passwords the Weakest Link?

Passwords remain the most common authentication factor, and the most frequently compromised. Microsoft's 2024 Digital Defense Report puts password-based attacks at more than 99% of the roughly 600 million daily identity attacks it observes, with about 7,000 blocked per second.^[2] 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 combo lists these breaches produce flow into the same criminal infrastructure that powers credential stuffing at scale.

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.

How Strong Is Each MFA Factor?

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. NIST SP 800-63B treats SMS over PSTN as a "restricted" authenticator: still permitted, but only with documented risk mitigation, user notification, and a plan to migrate to stronger factors.^[1]

Time-based one-time passwords (TOTP) use apps like Google Authenticator, Microsoft Authenticator, or 1Password. 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. NIST SP 800-63B explicitly tells verifiers to cap the rate and total number of push prompts to defend against this fatigue.^[1] 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. NIST formalises this property: an authenticator is "phishing-resistant" only when it binds to the verifier through channel binding (e.g., client-authenticated TLS) or verifier name binding (e.g., WebAuthn/FIDO2), which manual-entry codes like OTP cannot do.^[1] 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.

Why Is Account Recovery the Weakest Path?

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:

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. This is also why mailbox controls like email authentication matter for account security: if the recovery channel is email, the security of that mailbox is the real ceiling.

Can Deepfakes Defeat ID Verification?

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 are the same controls used at account opening, covered in KYC 101, now repurposed to gate recovery instead of onboarding.

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

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.

How Do RBAC and ABAC Differ?

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.

Where Do Authorization Systems Break Down?

Even well-designed authorization systems develop weaknesses over time:

Privilege escalation is gaining permissions beyond what was intended. It comes in two forms:

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.

Why Does Permission Creep Happen?

Organizations manage authorization through the employee lifecycle:

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

---

References

1. NIST Special Publication 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management (2025)↗ (factor categories; SMS over PSTN as a restricted authenticator; rate limiting against push fatigue; phishing-resistance via channel or verifier-name binding)

2. Microsoft Digital Defense Report 2024↗ (password-based attacks over 99% of ~600M daily identity attacks; ~7,000 password attacks blocked per second)