Authentication and Authorization in the Trenches: The Anatomy of a Breach That Could Have Been Avoided

Hello! Today we're going to talk about something that keeps me up at night: authentication systems that seem secure but hide fatal vulnerabilities.

It was a normal Thursday when I received that call no engineer wants to receive: "I think we've been hacked." What started as a routine investigation turned into a painful lesson about how our security assumptions can betray us.

When the "Unbreakable" 2FA Was Broken

I remember the day I discovered that our "bulletproof" 2FA had been bypassed. It was supposed to be impossible, right? Wrong.

Tools like Modlishka now automate phishing attacks that bypass multi-factor authentication as if it didn't exist. They use reverse proxy – basically placing themselves in the middle of the conversation and capturing everything.

GitHub itself made 2FA mandatory for all developers. It's not paranoia – it's recognition that the game has changed.

How the hell did this happen? The answer taught me a painful lesson:

The attack was frighteningly elegant:

1. Surgical phishing: An email that seemed to come from our own CEO
2. 2FA? What 2FA?: Reverse proxy captured tokens like they were Pokémon
3. Silent escalation: From junior dev to admin in 3 clicks
4. The parting gift: Backdoors planted in critical repos

Each step could have been blocked. But here's the part that hurts: we had ALL the "best practices".

2FA? Check. Monitoring? Check. Detailed logs? Check. Compromised anyway? Unfortunately, check.

Why? Simple and painful: we treated authentication and authorization as isolated checkboxes, not as parts of a living defense organism.

The 4 Billion Dollar Confusion

Ok, But What's the Difference Really?

Let me tell you a real horror story. In 2019, Capital One lost data from 106 million customers. The cost? Billions.

Authentication asks "who are you?". Authorization asks "what can you do?".

Seems stupidly simple, right? Well, this "stupidity" has destroyed companies.

Paige Thompson, former AWS employee, didn't need to break any passwords. She was perfectly authenticated with valid credentials obtained through a misconfigured firewall.

The system knew exactly who she was. It just forgot to ask if she should be messing with 106 million records.

A misconfigured WAF gave access to AWS metadata, which kindly handed over credentials with superpowers. Game over.

Think of a military base. Authentication is the guard at the gate checking your badge. Cool, you're in.

But that's where the danger lies. Authorization decides if you can:

• Enter the server room (do you have the right role?)
• Read classified documents (are you on the ACL?)
• Work at 3 AM (does it make sense for your profile?)
• Delete the production database (hopefully not!)

Each layer is independent. Each can fail. And here's the scary part: each one NEEDS to assume the others will fail.

The Multi-Factor Illusion

MFA seems genius on paper: combine independent factors and it becomes impossible to hack. The math is beautiful.

In practice? Well, let me tell you about the times I've seen MFA fail spectacularly.

1. Something you know (or everyone discovers)

Passwords? Everyone hates them. PINs? They're just passwords that pretended to diet. Security questions? "What's your first pet's name?" Seriously? In 2025?

10 minutes on the person's Facebook and you know the dog's name, their mother's name, and probably what they had for lunch.

The real problem is that we're terrible with passwords. You can require 12 characters, Egyptian hieroglyphs, and a drop of blood – 85% of breaches will still use "password123!".

// What NOT to do - password validation that looks strong but is useless
fun isPasswordSecure(password: String): Boolean {
    return password.length >= 8 && 
           password.contains(Regex("[A-Z]")) &&
           password.contains(Regex("[0-9]")) &&
           password.contains(Regex("[!@#$%]"))
    // ✗ "Password123!" passes but is one of the most common passwords
}

// What to do - check against known password lists
fun isPasswordActuallySecure(password: String): Boolean {
    return !isInCommonPasswordList(password) &&
           calculateEntropy(password) > 50 &&
           !containsPersonalInfo(password)
}

2. Something you have (until someone steals it)

SMS for 2FA? Adorable. Except when we discover that SIM swapping exists.

You know what's easier than breaking encryption? Calling the carrier and convincing a bored attendant that you "lost your chip".

The FBI said we lost $68 million just in 2021 with this trick. It was $12 million in three years before that. The escalation is frightening.

Even Vitalik Buterin was a victim. If Ethereum's creator can be hacked, what's left for us mere mortals?

YubiKeys are great. But try convincing your company to buy one for each employee. Good luck.

3. Something you are (and can't change)

Biometrics seems like the future, right? Until you think about it a bit.

Fingerprint? You leave it on every coffee cup you touch. Face ID? Your 500 Instagram selfies say thanks. Iris scan? Cool, until deepfakes get good enough.

Here's an inconvenient truth: biometrics aren't passwords, they're public usernames.

When your password leaks, you change it. When your fingerprint leaks... what do you do? Cut your finger off?

I once worked on a project where the client wanted "just biometrics, no password." I had to explain why this was like locking the door and leaving the key under the mat.

4. Context (or: how you act)

This is where it gets interesting. The smartest systems today look at how you do things.

You always log in from São Paulo at 9 AM? Strange to see this login from Moscow at 3 AM. You type 80 words per minute? Suspicious that this person is typing too slowly.

Is it Big Brother? Maybe. But it works frighteningly well.

data class AuthenticationContext(
    val ipLocation: String,
    val deviceFingerprint: String,
    val timeOfAccess: Long,
    val behaviorProfile: UserBehaviorProfile
)

fun shouldRequireStepUp(user: User, context: AuthenticationContext): Boolean {
    return when {
        context.isFromNewLocation() -> true
        context.isOutsideNormalHours() -> true
        context.deviceRiskScore() > 7.5 -> true
        context.deviatesFromBehaviorProfile() -> true
        else -> false
    }
}

The Inconvenient Truth About MFA

Microsoft says MFA blocks 99.9% of attacks. They analyzed 1.2 million hacked accounts.

Sounds great, right? Until you realize that the 0.1% that get through are exactly the ones that make the news.

Let me translate that for you:

Scenario 1 - The Classic Brute Force Attack

• Simple password: 1 attempt in 1,000 works
• Password + SMS: 1 attempt in 1,000,000 works
• 99.9% risk reduction ✅

Scenario 2 - The Modern Targeted Attack

• Phishing + reverse proxy: Captures complete session
• SIM swapping: Controls SMS
• Social engineering: Convinces support to reset account
• MFA is completely irrelevant ❌

MFA is like locking your front door. It deters opportunistic thieves but doesn't stop someone who really wants to get in.

Mass attacks? MFA destroys them. Targeted attacks? MFA is just an annoying obstacle.

MFA is the minimum, not the maximum. It's wearing a seatbelt, not driving a tank.

The future isn't about stacking more factors like it's a sandwich. It's about being smarter.

Level 1: Regular user browsing

• SMS + password is enough
• Blocks script kiddies
• Perfect for your Facebook

Level 2: Employee accessing systems

• Authenticator app + known device
• Abnormal behavior? More checks
• What I use at most companies

Level 3: Paranoia mode (justified)

• YubiKey + biometrics + someone has to approve
• Zero trust, continuous verification
• When you're moving millions or keeping state secrets

What Really Works (When Done Right)

OAuth 2.0 and OpenID Connect

It's not sexy, but OAuth 2.0 + OIDC still solves 90% of problems. The drama? Everyone implements it wrong.

I've seen people validating JWTs by just looking at the local signature. It's like verifying if a check is signed without calling the bank.

// OAuth implementation that is NOT secure
fun validateOAuthToken(token: String): User? {
    // ❌ Local validation only - can be forged
    val claims = JWT.decode(token).claims
    return getUserFromDatabase(claims["sub"])
}

// Secure OAuth implementation
fun validateOAuthToken(token: String): User? {
    return try {
        // ✅ Validation at authorization server
        val userInfo = oauthClient.getUserInfo(token)
        val user = getUserFromDatabase(userInfo.sub)
        
        // ✅ Additional permission verification
        if (user.isActive && user.hasValidSubscription()) user else null
    } catch (e: Exception) {
        logger.warn("Token validation failed", e)
        null
    }
}

JWT: The Misunderstood

I'll be direct: JWT isn't a session. JWT isn't a database. JWT is just a fancy envelope for data.

I've lost count of how many systems I've seen broken because someone thought JWT was magical. Spoiler: it's not.

Practical Actions for Monday

1. The Hunt for Lost Tokens

Reserve 1 hour. Just 1 hour. Look for ALL the places where your app "remembers" the user:

• That cookie that never expires
• The 1-year JWT token (yes, I've seen it)
• "Trust this IP" (terrible idea)
• The classic "remember me for 30 days"

For each one, note: when does it die? how to kill it? what does it access? how to know if it was stolen?

2. Alerts That Save Lives

Set up these alerts TODAY:

• John always logs in from SP, now he's in China?
• Maria works 9-6, logging in at 3 AM?
• Peter always uses Chrome, now it's curl?

Doesn't need to be fancy. An email already saves lives.

3. When Everything Goes Wrong (Survival Mode)

Your auth system is down? Don't panic:

• Let them use it, but read-only
• Log EVERYTHING (who, when, what)
• Sessions of 5 minutes maximum
• Notify the user they're in safe mode

4. War Plan (You'll Need It)

When (not if, when) they hack you:

• 5 minutes: How do you find out? (Spoiler: usually it's a user complaining)
• 15 minutes: Red "general logout" button - do you have one?
• 1 hour: What data did the attacker see? (Logs are your friends)
• 4 hours: Return to normal without leaving gaps
• All the time: Who do you notify? CEO? Users? Lawyer?

The Lesson That Cost Dearly

After years debugging breaches, I learned something: security isn't about having the perfect lock. It's about knowing when someone is messing with the lock.

Systems fail when:

• You treat each part as an island
• Copy "best practices" without thinking
• Focus only on preventing, not detecting
• Think security and usability are enemies

What really works:

• Assume they'll hack you (because they will)
• Detect fast, respond faster
• Adapt security to context
• Make security that people actually use

The Final Plot Twist

Remember the breach I mentioned at the beginning? Know how we discovered it?

It wasn't the million-dollar IDS. It wasn't the fancy SIEM. It was a dev who found it strange to see logins at 4 AM and decided to investigate.

A human paying attention.

That's the truth nobody wants to hear: there's no perfect system. But there are systems that scream when something goes wrong.

Auth isn't a problem you solve. It's a garden you cultivate. Every day there's new weeds to pull.

Next time you implement authentication, don't just ask "is it secure?".

Ask:

• How will I know when they break it?
• What happens when it fails?
• How will users try to bypass it?
• What alarms should I set up?

Because at the end of the day, real security isn't about building impenetrable walls.

References and Sources

Real Breach Cases

• Capital One Data Breach 2019 - Official Statement
• Capital One breach: 106 million affected - CNN Business
• What We Can Learn from the Capital One Hack - Krebs on Security
• Coinbase 2FA bypass attack affects 6,000+ users - The Record

Attack Tools and Techniques

• Modlishka: Automated 2FA-bypassing phishing tool - IPification
• SIM Swapping: What is it and how does it work? - Cointelegraph

Security Statistics

• Microsoft: One simple action to prevent 99.9% of attacks
• FBI: SIM Swap Schemes Statistics - IC3

Industry Initiatives

• GitHub's 2FA mandate for developers - GitHub Blog