Section 6: Authentication Protocols

The Big Picture: Proving a Secret Without Saying It

Suppose you want to prove to a friend, over a phone line that others can listen to, that you know a secret number, without saying it. One trick: your friend says a random word. You mix the secret with that word and say the result. Your friend, who also knows the secret, does the same mix and checks the answer. A listener hears only the random word and the result. They never hear the secret.

This is the idea behind authentication protocols. A protocol is a set of agreed steps two sides follow so they understand each other. Windows has three main ways to prove who you are: NTLM (older), Kerberos (modern, in domains) and Windows Hello (device-based, no password sent).

 Authentication package   Used for                      Age
 ──────────────────────   ────────────────────────────  ──────────────
 NTLM (via MSV1_0)        local accounts, old networks  legacy
 Kerberos                 domain accounts               modern default
 Windows Hello            PIN / fingerprint / face      modern, device-bound

An authentication package is a Windows module loaded into LSASS that knows one of these methods. LSASS picks the right one.

6.1 NTLM (Legacy Challenge-Response)

What it is: NTLM (NT LAN Manager) is the older Windows authentication protocol. It works by challenge and response. The password itself is never sent over the wire.

The steps:

  CLIENT (you)                              SERVER (or domain controller)

  1. "I'd like to sign in as Harshil."  ──────────────────────►
                                        ◄──────────────────────  2. CHALLENGE:
                                                                    a random number
  3. Mix the challenge with the secret
     derived from my password.
     Send the RESULT.                   ──────────────────────►
                                                                 4. Server does the same
                                                                    mix with ITS copy of the
                                                                    secret, compares.
                                        ◄──────────────────────  5. Match: ACCEPTED

• The secret used in the mix is derived from your password (the stored hash, Section 1.2), not the plain password.
• The challenge is a fresh random number each time, so an old recorded answer is useless for a new sign-in.
• For a local account, the check happens against the SAM on the same PC (inside the MSV1_0 authentication package: MSV stands for "Microsoft Version 1.0"). For network sign-in to another PC, the server either checks its own SAM or passes the challenge and answer to a domain controller to check.

Why NTLM is called legacy. It is older and has known weaknesses: it does not check that the server is who it claims to be (one-way trust), and it is open to certain relay tricks. Modern Windows still supports it for compatibility, for example with old devices, or when a Kerberos server cannot be found (such as connecting by IP address). Security teams often try to reduce NTLM use over time. Hedge: how much NTLM your PC uses depends on your network.

Where you meet it: a home PC signing in to a local account, and connecting to a shared folder on another home PC by user name and password.

6.2 Kerberos (Modern Ticket-Based, Domain Environments)

What it is: Kerberos is the default authentication protocol in a Windows domain (Active Directory). It is named after the three-headed dog of Greek myth, because it involves three parties: the client, the service, and a trusted middle party.

The trusted middle party is the KDC (Key Distribution Center), a service that runs on every domain controller. It hands out tickets.

What is a ticket? A ticket is a small, signed, time-limited pass. It proves "the KDC has already checked this person." Think of cinema tickets: you pay once at the box office (the KDC), and then every door staff member just looks at the ticket. They do not need to call the box office each time.

The main steps:

 YOU                 KDC (on domain controller)            FILE SERVER
  │                         │                                   │
  │ 1. sign in: prove you   │                                   │
  │    know the password ──►│                                   │
  │ ◄── TGT (Ticket-Granting│                                   │
  │     Ticket), valid ~10h │                                   │
  │                                                             │
  │ 2. "I want to use the file server" + TGT ──►│               │
  │ ◄── SERVICE TICKET for that file server     │               │
  │                                                             │
  │ 3. present the service ticket ─────────────────────────────►│
  │ ◄───────────────────────── accepted, access granted         │

Why it is better than NTLM:

• Passwords are not sent for each service. You sign in once and reuse tickets (this is a form of single sign-on: sign in once, use many services).
• Mutual authentication: the client can check that the server is genuine too.
• Tickets are time-limited (a TGT is typically valid for about 10 hours; hedge, set by policy), so a stolen ticket stops working.
• The KDC does the heavy checking once, so servers stay simple.

Clocks matter. Tickets contain timestamps. If your PC's clock differs too much from the domain controller's (by default more than 5 minutes, called clock skew), Kerberos refuses the sign-in. A "time is wrong" fault is a classic cause of mysterious domain sign-in failures. Chapter 4 covered how a PC keeps time with its real-time clock; Windows also syncs time with the domain.

See your tickets. Open Command Prompt and run:

klist

• On a domain-joined PC you will see a list of tickets (a "Cached Tickets" count, then a TGT for krbtgt/... and others).
• On a home PC with a local or Microsoft account and no domain, the list is empty (it shows zero cached tickets). That is normal, not a fault. Kerberos is simply not used there.

klist only reads your own tickets. Do not share its output in public, because it shows names of servers in your network.

6.3 Windows Hello (Biometric/PIN, Hardware-Backed)

What it is: Windows Hello lets you sign in with a PIN, fingerprint or face, instead of typing a password. It is more than convenience: it is stronger than a typical password.

Biometrics means measuring your body (fingerprint ridges or facial shape). Windows Hello face sign-in needs a special infrared camera; fingerprint needs a fingerprint reader. Many laptops have one or both.

How it works, in plain words:

1. When you enroll (set it up), Windows creates a key pair for that device and your account. A key pair is two linked numbers: a private key (kept secret) and a public key (shared freely). Only the private key can make a valid signature.
2. The private key is stored in the TPM (Trusted Platform Module), a small security chip on the motherboard (or a similar protected hardware area). It cannot be copied out. The security architecture chapter explained how the TPM stores secrets.
3. When you sign in, you unlock the key with your PIN or biometric. The TPM then signs a request. The server checks the signature with the public key.

 PIN / finger / face ──► unlocks ──► [ TPM: private key ]
                                           │ signs a challenge
                                           ▼
                          server checks signature with public key
                          (no password crosses the network)

Why a PIN can be safer than a password:

Hedge: exact behaviour, for example how the key is used with a Microsoft account, a domain, or Microsoft Entra ID, depends on your setup.

Your biometric data stays on the device. Windows stores a mathematical template, not a picture, and it does not leave the PC. Biometrics only unlock the key; the key does the signing.

Where to check it: Settings → Accounts → Sign-in options shows which Windows Hello methods are set up and available. You will look at it in the lab (looking only, no changes).

Summary