// networking basics — module 09

Module 9 — Identity, Authentication & Access

Soren Brumbach · · 8 min read

Thesis: Credentials are the single most fought-over thing in security — the front door to everything. Most real intrusions don't "hack in"; they log in with stolen or guessed credentials. Understand the machinery of identity before the split, because both tracks spend enormous energy attacking or protecting exactly this.

Prerequisite: Module 8 — Operating Systems Under a Security Lens: Linux & Windows (SIDs, tokens, AD) and Module 7 — Cryptography Fundamentals (hashing, salting). This module is where those two meet.

9.1 Why identity is the main battleground

Firewalls, patches, and encryption all matter — but the overwhelming majority of real breaches happen through valid credentials misused. An attacker with your password doesn't need an exploit; they walk through the front door and look, to most systems, exactly like you. That's why identity is where both tracks concentrate: attackers steal, crack, and abuse credentials to become legitimate users; defenders enforce, monitor, and constrain identity to make that as hard and as visible as possible. Everything in this module is about that front door.

9.2 Authentication vs. authorization, reinforced

From Module 0, sharpened now that you've seen the machinery:

  • Authentication (AuthN) proves who you are. (Password check, key verification, biometric.)
  • Authorization (AuthZ) decides what you're allowed to do, once you're known. (Permissions, ACLs, roles.)

They are separate steps and fail separately. A system can authenticate you perfectly and still authorize you for far too much — which is the essence of the least-privilege failures below. When you read Module 6's 401 (not authenticated) vs 403 (authenticated but not allowed), you're reading exactly this distinction on the wire.

9.3 Authentication factors and MFA

Authentication relies on one or more factors, categorized by what kind of thing proves you:

  • Something you know — a password, PIN, or passphrase.
  • Something you have — a phone, hardware token, or smart card generating/receiving codes.
  • Something you are — a biometric: fingerprint, face, iris.

MFA (Multi-Factor Authentication) combines factors from different categories (a password and a phone code). This is one of the highest-impact defenses in existence: a stolen password alone is useless if the attacker doesn't also have your second factor. Note the "different categories" requirement — two passwords aren't MFA; a password plus a phone code is. MFA is why credential theft, though still the top attack, is far less catastrophic when MFA is in place — which is precisely why attackers work to bypass it (stealing session tokens, §9.6, is one way around it).

9.4 Passwords under the hood

Building on Module 7's hashing:

  • How they should be stored — never plaintext; salted and hashed with a slow algorithm (bcrypt/scrypt/Argon2/PBKDF2). A database stored this way is expensive to crack even if stolen. Stored as fast, unsalted hashes (or plaintext), it's a jackpot.
  • Length beats complexity. A long passphrase (correct horse battery staple) resists cracking far better than a short "complex" password (P@ss1!), because cracking difficulty grows with length far faster than with a few substituted symbols. Modern guidance favors length and blocking known-breached passwords over forced complexity rules.
  • Why a password database is the crown jewel of a host — crack it offline (no rate limits, no lockouts, billions of guesses per second on weak hashes) and you may recover credentials that work elsewhere, especially if users reuse passwords (which drives credential stuffing).

9.5 Windows authentication: NTLM and Kerberos

You need the shape of these, because credential attacks and defenses in a Windows/AD environment (Module 8) revolve around them. Not every detail yet — the silhouette.

  • NTLM — the older, challenge-response, hash-based protocol. The server challenges, the client proves it knows the password by responding with something derived from the password hash. A crucial consequence: because the hash itself is what proves identity, an attacker who steals a hash can sometimes authenticate without ever knowing the password — the infamous pass-the-hash technique. NTLM is legacy and weaker; defenders work to retire it.

  • Kerberos — the modern, ticket-based protocol AD uses by default. A central authority, the KDC (Key Distribution Center) running on the domain controller, issues time-limited tickets:

    • You authenticate once to the KDC and get a TGT (Ticket-Granting Ticket) — a master ticket proving you're you.
    • To use a service, you present the TGT and get a service ticket for that specific service.
    • You hand the service ticket to the service, which trusts it because the KDC signed it — without the service ever seeing your password.
   You ──(prove identity once)──► KDC ──► gives you a TGT
   You ──(TGT, "I want fileserver")──► KDC ──► gives you a service ticket
   You ──(service ticket)──► Fileserver ──► "KDC vouched for you — welcome"

The takeaway: Kerberos is "tickets vouched for by a trusted third party," and attacking it means stealing or forging tickets (techniques with names like pass-the-ticket, Kerberoasting, golden ticket — you don't need them now, just know they target this machinery). Both NTLM and Kerberos revolve around the truth from §9.4: it's often the hash or ticket, not the plaintext password, that an attacker actually needs.

9.6 Sessions and tokens — staying logged in

Authenticating every single request would be miserable, so after you prove yourself once, the system issues something that keeps you logged in:

  • Session cookies (web — Module 6): the server remembers your session and your browser presents the cookie each request.
  • Access tokens (APIs, OS — Module 8's Windows access token, or a JWT/OAuth token): a credential you carry that says "this identity is already authenticated."

The security consequence is enormous and worth stating plainly: stealing a valid session or token bypasses authentication entirely — including MFA. The attacker never touches your password or your second factor; they just replay the token and are you until it expires. This is why session/token theft (via cross-site scripting, malware, or sniffing weak setups) is such a prized attack, and why protecting tokens (short lifetimes, HttpOnly/Secure cookies, binding tokens to devices) is a core defense.

9.7 SSO and federation

Managing separate credentials for every app is unmanageable, so organizations use SSO (Single Sign-On): authenticate once to a central identity provider (IdP) and access many services without logging in again. The enabling protocols, at a glance:

  • SAML — XML-based, common for enterprise web SSO.
  • OAuth 2.0 / OpenID Connect — token-based; the "Log in with Google/Microsoft" you see everywhere. (OAuth is really about authorization/delegated access; OpenID Connect adds the authentication layer on top.)

The trade-off is concentration: SSO is convenient and lets you enforce MFA and policy in one place (a defensive win), but it also means the IdP is a single, extremely high-value target — compromise the identity provider and you may reach everything it signs people into. Federation extends this trust between organizations.

9.8 Least privilege in practice

Module 0's principle, made concrete around identity — because over-privileged accounts are the root of a huge share of breaches:

  • Local vs. domain admin — a local admin controls one machine; a domain admin controls the entire AD domain (Module 8). Domain admin credentials are the ultimate prize; they should be rare, tightly guarded, and never used for everyday work.
  • Service accounts — non-human accounts that run services. They're often over-privileged and rarely rotated, making them a favorite target (their tickets can be attacked, per §9.5).
  • The core failure — accounts (human and service) accumulating more privilege than they need. Least privilege means each identity gets exactly what its job requires and no more, so a single compromised account is contained rather than catastrophic.

9.9 → Red/Blue

Red teams steal, crack, relay, and abuse credentials and tickets to move through a network: dumping and cracking password hashes, pass-the-hash and Kerberos ticket attacks, hijacking sessions and tokens to bypass MFA, and hunting for over-privileged accounts to escalate toward domain admin. Blue teams enforce MFA and least privilege, store passwords correctly, monitor authentication logs (the failed/successful logons of Module 8, the auth events of Module 11), and detect credential abuse — impossible-travel logins, pass-the-hash patterns, anomalous ticket requests, service accounts behaving like humans. Every technique on both sides assumes the identity fundamentals in this module.

Lab 9

Stay within your own accounts and your lab.

  1. Watch MFA's factors. Turn on MFA somewhere you have an account (if it isn't already). Log in and consciously name which factor each step uses — password (know) then phone/app code (have). Notice you needed both.

  2. Reason about length vs. complexity. Estimate (a search for a "password strength / crack time" explainer is fine) how long it takes to crack P@ss1! versus correct-horse-battery-staple. Write one paragraph explaining why length wins against a cracker.

  3. Contrast NTLM and Kerberos. In your own words, describe the difference: challenge-response with a hash (NTLM) versus tickets vouched for by a KDC (Kerberos). Explain what "the hash/ticket, not the password, is what's stolen" means for each.

  4. Session theft thought experiment. Recall your session-cookie work from Module 6. Explain how copying a valid session token lets an attacker bypass MFA entirely, and why that makes token protection a first-class defense.

  5. Find over-privilege. On your own systems, identify one account or service that has more privilege than it needs (an app running as root/admin, a personal account with admin it rarely uses). Describe what least privilege would change.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

  1. Why do most real breaches involve logging in rather than breaking in?
  2. Authentication vs. authorization — define both and give a case where one succeeds and the other fails.
  3. Name the three authentication factor categories. What makes something MFA (and what doesn't)? Why is MFA so high-impact?
  4. How should passwords be stored, and why does length beat complexity?
  5. Contrast NTLM and Kerberos. In each, what is it that an attacker actually needs to steal — and why isn't it always the plaintext password? What are the KDC, the TGT, and a service ticket?
  6. How can stealing a session or token bypass authentication and MFA?
  7. What is SSO, what does an identity provider concentrate, and what's the trade-off?
  8. Local admin vs. domain admin — why is the latter the ultimate prize, and what does least privilege do to contain a compromise?

And perform cold:

  • Log in with MFA and correctly name the factor category of each step.
  • Explain, end to end, how a stolen session token defeats a password + MFA setup.

When all of that is effortless: Module 10 — Scripting & Automation: Bash, Python, and Regex