Authentication - Learning Module

Loading content...

0/240

Authentication Protocols

Proving Identity Across the Network

When you log into your company's network, a remarkable choreography unfolds behind the scenes. Your workstation communicates with a domain controller, proves your identity, receives cryptographic tickets, and uses those tickets to access file servers, email systems, and business applications—all without transmitting your password over the network.

This is the realm of authentication protocols: the precisely specified message exchanges that enable secure identity verification between parties who may not trust the network connecting them. A poorly designed protocol can render even the strongest password useless; a well-designed protocol can protect credentials even against sophisticated network attackers.

From the classic challenge-response patterns to enterprise systems like Kerberos, and modern web standards like OAuth 2.0 and OpenID Connect, authentication protocols form the invisible infrastructure of secure networked computing.

What You Will Learn

By the end of this page, you will understand why transmitting passwords directly is dangerous, how challenge-response protocols protect credentials, how Kerberos enables enterprise single sign-on, the role of OAuth and OpenID Connect in modern web authentication, and the security properties that distinguish robust protocols from vulnerable ones.

The Problem with Password Transmission

The most naive authentication approach—send username and password to the server—seems straightforward but introduces severe vulnerabilities that sophisticated protocols are designed to prevent.

Plaintext Password Risks:

1. Eavesdropping (Passive Interception): Any network observer between client and server can capture credentials:

Network tap or hub environment
Compromised router or switch
Malicious WiFi access point
ISP-level surveillance

2. Man-in-the-Middle (Active Interception): An attacker positioning themselves between parties can:

Capture credentials in real-time
Modify authentication responses
Hijack established sessions
Impersonate either party

3. Server-Side Exposure: If the server receives the plaintext password:

Compromised server logs may reveal passwords
Memory dumps expose credentials
Rogue server administrators can capture passwords
Password visible in application code paths

4. Replay Attacks: Even if encrypted in transit, captured authentication messages can be replayed:

Attacker records valid authentication exchange
Replays captured messages to gain access
No knowledge of actual password required

Authentication Transmission Vulnerabilities
Attack Type	Plaintext HTTP	HTTPS	Challenge-Response
Passive eavesdropping	Vulnerable	Protected	Protected
MITM with fake certificate	Vulnerable	Vulnerable*	Protected**
Replay attack	Vulnerable	Protected†	Protected
Rogue server	Vulnerable	Vulnerable*	Protected**
Server memory exposure	Vulnerable	Vulnerable	Protected

*If user accepts invalid certificate or certificate verification fails **If protocol includes mutual authentication †Within the TLS session, but password exposed to server

Why TLS Alone Isn't Sufficient:

TLS (HTTPS) protects password transmission from network eavesdroppers, but doesn't address all threats:

Password still travels to server: Even encrypted, the plaintext password is processed by the server
Certificate validation issues: Users may click through warnings; malicious CAs may issue fraudulent certificates
Server-side vulnerabilities: TLS protects the network, not the server's handling of credentials
Phishing remains effective: TLS doesn't prevent users from entering passwords on fraudulent sites

The Protocol Goal:

Ideal authentication protocols achieve zero-knowledge proof—the client proves knowledge of the password without ever revealing it. The server learns only "this client knows the password," not the password itself.

Legacy Protocol Dangers

Many legacy protocols transmit credentials in plaintext: Telnet, FTP, HTTP Basic Auth, SMTP/POP3/IMAP without TLS, older database protocols. These should never be used on untrusted networks. Modern deployments should require TLS for all credential-bearing connections.

Challenge-Response Authentication

Challenge-response protocols solve the password transmission problem by proving password knowledge without sending the password. The server challenges the client with a random value; the client responds with a value derived from both the challenge and the password.

Basic Challenge-Response Flow:

Client                                Server
   |                                    |
   |  1. «I am Alice»                   |
   |----------------------------------->|
   |                                    |
   |  2. «Challenge: 0x7F3A9B2C»        |
   |<-----------------------------------|
   |                                    |
   |  Compute: response = f(password, challenge)
   |                                    |
   |  3. «Response: 0xAE4D1F8B»         |
   |----------------------------------->|
   |                                    |
   |  Server computes expected response |
   |  using stored password/hash        |
   |  Compares with received response   |
   |                                    |
   |  4. «Access Granted» or «Denied»   |
   |<-----------------------------------|

Security Properties:

Password never transmitted: Only derived value crosses network
Replay resistant: Each challenge is unique; old responses don't work
Server verification possible: Server can compute expected response

The Response Function:

Typically HMAC (Hash-based Message Authentication Code):

response = HMAC(password, challenge)

Or hash-based:

response = hash(password || challenge)

challenge_response.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
"""
Challenge-Response Authentication Protocol Implementation
 
This demonstrates the fundamental pattern underlying protocols
like CRAM-MD5, MS-CHAPv2, SCRAM, and others.
"""
import hashlib
import hmac
import os
import secrets
from dataclasses import dataclass
from typing import Tuple, Optional
 
@dataclass
class AuthenticationResult:
    success: bool
    message: str
    session_id: Optional[str] = None
 
 
class ChallengeResponseServer:
    """
    Server-side challenge-response authentication.
    
    Demonstrates the core protocol without network transport.
    Production systems would add TLS, rate limiting, etc.
    """
    
    def __init__(self):
        # Simulated user database
        # In production: salted hashes, not plaintext
        self.users = {}
        self.pending_challenges = {}  # challenge -> username mapping
    
    def register_user(self, username: str, password: str):
        """
        Register user with password.
        
        We store hash(password) to avoid plaintext storage.
        For challenge-response to work, we need to compute
        the same response as the client.
        """
        # Store password hash (for response verification)
        password_hash = hashlib.sha256(password.encode()).digest()
        self.users[username] = password_hash
    
    def generate_challenge(self, username: str) -> Tuple[bool, bytes]:
        """
        Generate challenge for authentication attempt.
        
        Returns: (user_exists, challenge_bytes)
        """
        if username not in self.users:
            # Still return a challenge to prevent username enumeration
            fake_challenge = os.urandom(32)
            return False, fake_challenge
        
        # Generate cryptographically random challenge
        challenge = os.urandom(32)
        
        # Store challenge for later verification
        # In production: include timestamp for expiration
        self.pending_challenges[challenge] = username
        
        return True, challenge
    
    def verify_response(
        self,
        challenge: bytes,
        response: bytes
    ) -> AuthenticationResult:
        """
        Verify client's response to challenge.
        
        Returns authentication result.
        """
        # Look up the challenge
        if challenge not in self.pending_challenges:
            return AuthenticationResult(
                success=False,
                message="Invalid or expired challenge"
            )
        
        username = self.pending_challenges.pop(challenge)
        
        # Get user's password hash
        if username not in self.users:
            return AuthenticationResult(
                success=False,
                message="Authentication failed"
            )
        
        password_hash = self.users[username]
        
        # Compute expected response
        expected_response = hmac.new(
            password_hash,
            challenge,
            hashlib.sha256
        ).digest()
        
        # Constant-time comparison
        if hmac.compare_digest(response, expected_response):
            session_id = secrets.token_hex(16)
            return AuthenticationResult(
                success=True,
                message="Authentication successful",
                session_id=session_id
            )
        else:
            return AuthenticationResult(
                success=False,
                message="Authentication failed"
            )
 
 
class ChallengeResponseClient:
    """Client-side challenge-response authentication."""
    
    def __init__(self, username: str, password: str):
        self.username = username
        # Client computes same password hash as server
        self.password_hash = hashlib.sha256(password.encode()).digest()
    
    def compute_response(self, challenge: bytes) -> bytes:
        """
        Compute response to server's challenge.
        
        Response = HMAC(password_hash, challenge)
        
        The password itself never appears in the response.
        """
        return hmac.new(
            self.password_hash,
            challenge,
            hashlib.sha256
        ).digest()
 
 
def demonstrate_protocol():
    """Demonstrate complete challenge-response authentication."""
    
    print("=== Challenge-Response Authentication Demo ===
")
    
    # Setup
    server = ChallengeResponseServer()
    server.register_user("alice", "correct_password")
    
    # Successful authentication
    print("1. Alice authenticates with correct password:")
    client = ChallengeResponseClient("alice", "correct_password")
    
    _, challenge = server.generate_challenge("alice")
    print(f"   Server challenge: {challenge.hex()[:32]}...")
    
    response = client.compute_response(challenge)
    print(f"   Client response:  {response.hex()[:32]}...")
    
    result = server.verify_response(challenge, response)
    print(f"   Result: {result.message}")
    if result.session_id:
        print(f"   Session ID: {result.session_id}")
    print()
    
    # Failed authentication - wrong password
    print("2. Eve tries to authenticate as Alice with wrong password:")
    eve = ChallengeResponseClient("alice", "wrong_password")
    
    _, challenge = server.generate_challenge("alice")
    response = eve.compute_response(challenge)
    
    result = server.verify_response(challenge, response)
    print(f"   Result: {result.message}")
    print()
    
    # Replay attack attempt
    print("3. Eve replays Alice's previous response (replay attack):")
    alice = ChallengeResponseClient("alice", "correct_password")
    
    # Alice's legitimate authentication
    _, challenge1 = server.generate_challenge("alice")
    response1 = alice.compute_response(challenge1)
    result1 = server.verify_response(challenge1, response1)
    print(f"   Alice's original auth: {result1.message}")
    
    # Eve captures and replays
    # New challenge, but Eve tries old response
    _, challenge2 = server.generate_challenge("alice")
    print(f"   Eve replays old response to new challenge...")
    result2 = server.verify_response(challenge2, response1)
    print(f"   Replay result: {result2.message}")
    print()
    
    # Username enumeration protection
    print("4. Checking username enumeration protection:")
    exists, _ = server.generate_challenge("alice")
    print(f"   Challenge for 'alice' (exists): challenge returned")
    
    doesnt_exist, _ = server.generate_challenge("nonexistent")
    print(f"   Challenge for 'nonexistent': challenge still returned")
    print("   (Attacker cannot distinguish existing vs non-existing users)")
 
 
if __name__ == "__main__":
    demonstrate_protocol()

Common Challenge-Response Protocols:

CRAM-MD5:

Used in email (SMTP, IMAP, POP3)
Challenge: server-generated timestamp + random data
Response: MD5(password, challenge)
Weakness: MD5 is deprecated; vulnerable to offline dictionary attacks

MS-CHAP/MS-CHAPv2:

Microsoft implementation for PPP/VPN
CHAPv1 severely broken; CHAPv2 improved but still vulnerable
Requires password hash storage (not just verifier)

SCRAM (Salted Challenge Response Authentication Mechanism):

Modern, well-designed protocol
Supports salted password storage on server
Client and server both prove password knowledge
Channel binding for MITM protection
Used in MongoDB, PostgreSQL, XMPP

NTLM:

Microsoft Windows network authentication
Uses MD4-based hash (NT hash)
Vulnerable to pass-the-hash attacks
Being deprecated in favor of Kerberos

Mutual Authentication

Advanced challenge-response protocols include server authentication—the client verifies the server also knows the password. This prevents rogue server attacks where an attacker impersonates the legitimate server to harvest responses that could be used in offline attacks.

Kerberos Authentication

Kerberos is the cornerstone of enterprise network authentication, providing secure single sign-on (SSO) across Windows Active Directory environments and many Unix/Linux systems. Understanding Kerberos illuminates key concepts in distributed authentication.

The Kerberos Model:

Kerberos uses a trusted third party—the Key Distribution Center (KDC)—to broker authentication between clients and services. The core insight: if both parties trust the KDC and share secrets with it, they can authenticate to each other without sharing secrets directly.

Key Kerberos Components:

Principal: Any entity that can authenticate (users, services, hosts)
Realm: Administrative domain (e.g., CORP.EXAMPLE.COM)
KDC: Central authentication server containing:
- Authentication Server (AS): Issues initial tickets
- Ticket Granting Server (TGS): Issues service tickets
Ticket: Encrypted credential proving identity
- TGT (Ticket Granting Ticket): Used to request service tickets
- Service Ticket: Used to access specific services
Session Key: Temporary symmetric key for secured communication
Authenticator: Proves client possesses the session key (anti-replay)

Kerberos Authentication Flow:

┌──────────┐                  ┌──────────────────┐                  ┌──────────┐
│  Client  │                  │       KDC        │                  │  Service │
│  (User)  │                  │   (AS + TGS)     │                  │ (Server) │
└────┬─────┘                  └────────┬─────────┘                  └────┬─────┘
     │                                 │                                 │
     │ Step 1: AS_REQ                  │                                 │
     │ "I am alice@CORP.COM"           │                                 │
     │────────────────────────────────>│                                 │
     │                                 │                                 │
     │ Step 2: AS_REP                  │                                 │
     │ [TGT encrypted with client key] │                                 │
     │ [Session key for TGS]           │                                 │
     │<────────────────────────────────│                                 │
     │                                 │                                 │
     │ (Client decrypts with password) │                                 │
     │                                 │                                 │
     │ Step 3: TGS_REQ                 │                                 │
     │ [TGT] + [Authenticator]         │                                 │
     │ "I want to access fileserver"   │                                 │
     │────────────────────────────────>│                                 │
     │                                 │                                 │
     │ Step 4: TGS_REP                 │                                 │
     │ [Service ticket for fileserver] │                                 │
     │ [Session key for service]       │                                 │
     │<────────────────────────────────│                                 │
     │                                 │                                 │
     │ Step 5: AP_REQ                                                    │
     │ [Service ticket] + [Authenticator]                                │
     │──────────────────────────────────────────────────────────────────>│
     │                                                                   │
     │ (Service decrypts ticket with its key,                            │
     │  validates authenticator)                                         │
     │                                                                   │
     │ Step 6: AP_REP (optional, for mutual auth)                        │
     │<──────────────────────────────────────────────────────────────────│

kerberos_concepts.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
"""
Kerberos Concepts Demonstration
 
This implements core Kerberos concepts for educational purposes.
Production Kerberos uses complex ASN.1 encoding, multiple
encryption types, and extensive validation.
"""
import time
import secrets
import hashlib
from dataclasses import dataclass
from typing import Optional, Tuple
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
 
@dataclass
class KerberosTicket:
    """
    Represents a Kerberos ticket (TGT or service ticket).
    
    In real Kerberos, tickets are ASN.1 encoded and much more complex.
    """
    client_principal: str     # Who this ticket is for
    service_principal: str    # What service this ticket is for
    session_key: bytes        # Shared key between client and service
    issue_time: float         # When ticket was issued
    expiry_time: float        # When ticket expires
    flags: int                # Ticket flags (renewable, forwardable, etc.)
    
    def is_expired(self) -> bool:
        return time.time() > self.expiry_time
 
 
@dataclass 
class Authenticator:
    """
    Proves client possesses the session key.
    
    Includes timestamp for replay detection.
    """
    client_principal: str
    timestamp: float          # Client's current time
    checksum: Optional[bytes] = None
 
 
class KeyDistributionCenter:
    """
    Simplified Key Distribution Center (KDC).
    
    Combines Authentication Server (AS) and
    Ticket Granting Server (TGS) functionality.
    """
    
    def __init__(self, realm: str):
        self.realm = realm
        self.principals = {}     # principal -> key mapping
        self.tgs_key = secrets.token_bytes(32)  # TGS's master key
        
        # Register the TGS itself as a principal
        self.principals[f"krbtgt/{realm}"] = self.tgs_key
    
    def register_principal(self, name: str, password: str):
        """Register user or service with their key."""
        # Derive key from password (real Kerberos uses string2key)
        key = hashlib.pbkdf2_hmac(
            'sha256',
            password.encode(),
            self.realm.encode(),
            100000,
            dklen=32
        )
        self.principals[name] = key
    
    def _encrypt(self, key: bytes, data: bytes) -> bytes:
        """Encrypt data with key (simplified)."""
        nonce = secrets.token_bytes(12)
        aesgcm = AESGCM(key)
        ciphertext = aesgcm.encrypt(nonce, data, None)
        return nonce + ciphertext
    
    def _decrypt(self, key: bytes, data: bytes) -> bytes:
        """Decrypt data with key."""
        nonce = data[:12]
        ciphertext = data[12:]
        aesgcm = AESGCM(key)
        return aesgcm.decrypt(nonce, ciphertext, None)
    
    def _serialize_ticket(self, ticket: KerberosTicket) -> bytes:
        """Serialize ticket for encryption."""
        import json
        return json.dumps({
            'client': ticket.client_principal,
            'service': ticket.service_principal,
            'session_key': ticket.session_key.hex(),
            'issue': ticket.issue_time,
            'expiry': ticket.expiry_time,
            'flags': ticket.flags
        }).encode()
    
    def _deserialize_ticket(self, data: bytes) -> KerberosTicket:
        """Deserialize ticket from decrypted bytes."""
        import json
        d = json.loads(data)
        return KerberosTicket(
            client_principal=d['client'],
            service_principal=d['service'],
            session_key=bytes.fromhex(d['session_key']),
            issue_time=d['issue'],
            expiry_time=d['expiry'],
            flags=d['flags']
        )
    
    def as_exchange(self, client_principal: str) -> Tuple[bytes, bytes]:
        """
        Authentication Server Exchange (AS_REQ -> AS_REP)
        
        Returns: (encrypted_tgt, encrypted_session_info)
        
        The encrypted_tgt is encrypted with TGS key (client cannot read).
        The encrypted_session_info is encrypted with client key 
        (contains session key and metadata).
        """
        if client_principal not in self.principals:
            raise ValueError("Unknown principal")
        
        client_key = self.principals[client_principal]
        
        # Generate session key for client-TGS communication
        tgs_session_key = secrets.token_bytes(32)
        
        # Create TGT (encrypted with TGS key)
        tgt = KerberosTicket(
            client_principal=client_principal,
            service_principal=f"krbtgt/{self.realm}",
            session_key=tgs_session_key,
            issue_time=time.time(),
            expiry_time=time.time() + 36000,  # 10 hours
            flags=0
        )
        encrypted_tgt = self._encrypt(
            self.tgs_key, 
            self._serialize_ticket(tgt)
        )
        
        # Session info for client (encrypted with client key)
        import json
        session_info = json.dumps({
            'session_key': tgs_session_key.hex(),
            'tgs_principal': f"krbtgt/{self.realm}",
            'expiry': tgt.expiry_time
        }).encode()
        encrypted_session_info = self._encrypt(client_key, session_info)
        
        return encrypted_tgt, encrypted_session_info
    
    def tgs_exchange(
        self, 
        encrypted_tgt: bytes,
        encrypted_authenticator: bytes,
        service_principal: str
    ) -> Tuple[bytes, bytes]:
        """
        Ticket Granting Server Exchange (TGS_REQ -> TGS_REP)
        
        Client presents TGT plus authenticator, receives service ticket.
        
        Returns: (encrypted_service_ticket, encrypted_session_info)
        """
        # Decrypt TGT with TGS key
        tgt = self._deserialize_ticket(
            self._decrypt(self.tgs_key, encrypted_tgt)
        )
        
        if tgt.is_expired():
            raise ValueError("TGT expired")
        
        # Decrypt authenticator with session key from TGT
        import json
        auth_data = json.loads(
            self._decrypt(tgt.session_key, encrypted_authenticator)
        )
        
        # Verify authenticator
        if auth_data['client'] != tgt.client_principal:
            raise ValueError("Principal mismatch")
        
        # Check timestamp (allow 5 minute skew)
        time_diff = abs(time.time() - auth_data['timestamp'])
        if time_diff > 300:
            raise ValueError("Authenticator too old or clock skew")
        
        # Get service key
        if service_principal not in self.principals:
            raise ValueError("Unknown service")
        service_key = self.principals[service_principal]
        
        # Generate session key for client-service communication
        service_session_key = secrets.token_bytes(32)
        
        # Create service ticket (encrypted with service key)
        service_ticket = KerberosTicket(
            client_principal=tgt.client_principal,
            service_principal=service_principal,
            session_key=service_session_key,
            issue_time=time.time(),
            expiry_time=min(
                tgt.expiry_time,  # Cannot exceed TGT lifetime
                time.time() + 36000
            ),
            flags=0
        )
        encrypted_service_ticket = self._encrypt(
            service_key,
            self._serialize_ticket(service_ticket)
        )
        
        # Session info for client (encrypted with TGS session key)
        session_info = json.dumps({
            'session_key': service_session_key.hex(),
            'service_principal': service_principal,
            'expiry': service_ticket.expiry_time
        }).encode()
        encrypted_session_info = self._encrypt(
            tgt.session_key, 
            session_info
        )
        
        return encrypted_service_ticket, encrypted_session_info
 
 
def demonstrate_kerberos():
    """Demonstrate Kerberos authentication flow."""
    
    print("=== Kerberos Authentication Demo ===
")
    
    # Setup KDC
    kdc = KeyDistributionCenter("EXAMPLE.COM")
    kdc.register_principal("alice", "alices_password")
    kdc.register_principal("HTTP/webserver.example.com", "service_secret")
    
    print("1. Alice requests TGT from Authentication Server...")
    tgt, tgt_session_info = kdc.as_exchange("alice")
    print(f"   Received TGT ({len(tgt)} bytes)")
    print(f"   Received encrypted session info ({len(tgt_session_info)} bytes)")
    
    # Client decrypts session info with password-derived key
    client_key = hashlib.pbkdf2_hmac(
        'sha256', 
        "alices_password".encode(),
        "EXAMPLE.COM".encode(),
        100000,
        dklen=32
    )
    
    import json
    from cryptography.hazmat.primitives.ciphers.aead import AESGCM
    
    nonce = tgt_session_info[:12]
    aesgcm = AESGCM(client_key)
    session_data = json.loads(
        aesgcm.decrypt(nonce, tgt_session_info[12:], None)
    )
    tgs_session_key = bytes.fromhex(session_data['session_key'])
    print(f"   Decrypted TGS session key")
    print()
    
    print("2. Alice requests service ticket for webserver...")
    
    # Create authenticator
    authenticator = json.dumps({
        'client': 'alice',
        'timestamp': time.time()
    }).encode()
    
    nonce = secrets.token_bytes(12)
    aesgcm = AESGCM(tgs_session_key)
    encrypted_auth = nonce + aesgcm.encrypt(nonce, authenticator, None)
    
    service_ticket, service_session_info = kdc.tgs_exchange(
        tgt,
        encrypted_auth,
        "HTTP/webserver.example.com"
    )
    print(f"   Received service ticket ({len(service_ticket)} bytes)")
    print()
    
    print("3. Alice presents service ticket to webserver...")
    print("   (Service decrypts ticket with its key)")
    print("   (Service validates authenticator)")
    print("   Access granted!")
    print()
    
    print("Security properties demonstrated:")
    print("  ✓ Password never sent over network")
    print("  ✓ TGT cached - no password entry for subsequent services")
    print("  ✓ Each service gets unique session key")
    print("  ✓ Authenticator prevents replay attacks")
 
 
if __name__ == "__main__":
    demonstrate_kerberos()

Kerberos Security Properties:

Property	How Kerberos Achieves It
Password protection	Password used only to decrypt initial TGT; never sent over network
Single sign-on	TGT cached in memory; used to obtain service tickets without re-entering password
Mutual authentication	Optional AP_REP proves service identity to client
Replay protection	Authenticators include timestamps; services track recently used authenticators
Ticket lifetime limits	TGT and service tickets expire; limits damage from stolen tickets
Delegation	Forwardable tickets allow services to act on user's behalf

Kerberos Attacks:

Pass-the-Ticket: Stolen TGT used to request service tickets
Golden Ticket: Attacker with krbtgt hash can forge arbitrary TGTs
Silver Ticket: Attacker with service key can forge service tickets
Kerberoasting: Extract service tickets, crack service passwords offline
AS-REP Roasting: Attack accounts without pre-authentication

Active Directory Integration

In Windows Active Directory, Kerberos is the default authentication protocol. Domain controllers act as KDCs, user passwords derive Kerberos keys, and Group Policy controls ticket lifetimes. Understanding Kerberos is essential for securing Windows enterprise environments.

OAuth 2.0 and OpenID Connect

OAuth 2.0 and OpenID Connect (OIDC) define modern web authentication and authorization patterns. Understanding their distinction and proper usage is essential for secure web application development.

OAuth 2.0: Authorization, Not Authentication

OAuth 2.0 is an authorization framework—it determines what a client can do, not who the user is:

Designed to grant limited access to resources without sharing passwords
A user authorizes an application to access their data on another service
Example: "Allow this photo app to access my Google Photos" (not "prove who I am")

The OAuth 2.0 Problem Being Solved:

Before OAuth, granting third-party access required sharing passwords:

User gives password to third-party app
App has full unlimited access
No way to revoke access except changing password
Password potentially stored insecurely by third party

OAuth 2.0 Key Concepts:

Resource Owner: User who owns the data/resources
Client: Application requesting access
Authorization Server: Issues tokens after user consent
Resource Server: Holds protected resources (APIs)
Access Token: Credential to access resource server
Refresh Token: Credential to obtain new access tokens
Scope: Specific permissions granted (read, write, delete, etc.)

OAuth 2.0 Authorization Code Flow:

┌──────────┐          ┌──────────────┐          ┌────────────────┐          ┌──────────────┐
│  User    │          │   Client     │          │  Authorization │          │   Resource   │
│ Browser  │          │   App        │          │    Server      │          │    Server    │
└────┬─────┘          └──────┬───────┘          └───────┬────────┘          └──────┬───────┘
     │                       │                          │                          │
     │ 1. User clicks "Login with Google"               │                          │
     │<─────────────────────>│                          │                          │
     │                       │                          │                          │
     │ 2. Redirect to authorization server              │                          │
     │───────────────────────────────────────────────>  │                          │
     │                       │                          │                          │
     │ 3. User authenticates and grants consent         │                          │
     │<──────────────────────────────────────────────── │                          │
     │                       │                          │                          │
     │ 4. Redirect back with authorization code         │                          │
     │<─────────────────────────────────────────────────│                          │
     │                       │                          │                          │
     │───────────────────────>                          │                          │
     │                       │                          │                          │
     │                       │ 5. Exchange code for tokens (back channel)          │
     │                       │────────────────────────> │                          │
     │                       │                          │                          │
     │                       │ 6. Access token + refresh token                     │
     │                       │<──────────────────────── │                          │
     │                       │                          │                          │
     │                       │ 7. Access API with token                            │
     │                       │───────────────────────────────────────────────────> │
     │                       │                          │                          │
     │                       │ 8. Protected resource                               │
     │                       │<─────────────────────────────────────────────────── │

OAuth 2.0 Grant Types

•Authorization Code — Secure flow for web apps with backend; code exchanged for token via back-channel
•Authorization Code + PKCE — Secure flow for mobile/SPA apps; proof key prevents code interception
•Client Credentials — Machine-to-machine; no user involved; client authenticates directly
•Refresh Token — Exchange refresh token for new access token without user interaction
•Implicit (DEPRECATED) — Token returned directly in redirect; vulnerable to token leakage
•Resource Owner Password (DEPRECATED) — Client receives password directly; only for trusted first-party apps

OpenID Connect: Authentication Layer on OAuth 2.0

OIDC extends OAuth 2.0 with standardized identity layer:

ID Token: JWT containing authenticated user identity
UserInfo Endpoint: API to get user profile information
Standard Scopes: openid, profile, email
Discovery: Standardized metadata endpoint (.well-known/openid-configuration)

Critical Distinction:

Aspect	OAuth 2.0	OpenID Connect
Purpose	Authorization (what can you access)	Authentication (who are you)
Token	Access token (opaque)	ID token (JWT with claims)
User identity	Not standardized	Standardized in ID token
Use case	"Let this app post to my Twitter"	"Log me in with Google"

ID Token Structure:

{
  "iss": "https://accounts.google.com",
  "sub": "110169484474386276334",
  "aud": "your-client-id.apps.googleusercontent.com",
  "exp": 1716239022,
  "iat": 1716235422,
  "nonce": "abc123",
  "email": "user@gmail.com",
  "email_verified": true,
  "name": "John Doe"
}

The sub (subject) claim uniquely identifies the user at the identity provider. Applications should use this, not email, as the stable identifier.

OAuth 2.0 Security Considerations

Common OAuth implementation mistakes: using implicit flow (returns token in URL fragment), not validating state parameter (CSRF), accepting tokens from any issuer (confused deputy), storing tokens insecurely, and excessive scopes. Always use authorization code + PKCE for public clients.

SAML and Enterprise Federation

Security Assertion Markup Language (SAML) is the dominant protocol for enterprise single sign-on, particularly for web applications accessed via browser. While OIDC is increasingly preferred for new applications, SAML remains entrenched in enterprise environments.

SAML Core Concepts:

Identity Provider (IdP): Authenticates users and issues assertions (e.g., Okta, Azure AD, ADFS)
Service Provider (SP): Application that trusts assertions from IdP
Assertion: XML document containing authentication/authorization statements
Binding: How SAML messages are transported (HTTP Redirect, POST, Artifact)
Metadata: XML documents describing IdP/SP capabilities and certificates

SAML Web SSO Flow (SP-Initiated):

┌──────────┐          ┌──────────────┐          ┌────────────────┐
│  User    │          │   Service    │          │    Identity    │
│ Browser  │          │   Provider   │          │    Provider    │
└────┬─────┘          └──────┬───────┘          └───────┬────────┘
     │                       │                          │
     │ 1. Access protected resource                     │
     │──────────────────────>│                          │
     │                       │                          │
     │ 2. No session; redirect to IdP with AuthnRequest │
     │<──────────────────────│                          │
     │                       │                          │
     │ 3. AuthnRequest (in redirect or POST)            │
     │──────────────────────────────────────────────>   │
     │                       │                          │
     │ 4. User authenticates at IdP                     │
     │<─────────────────────────────────────────────────│
     │                       │                          │
     │ 5. POST assertion to SP's Assertion Consumer Service
     │      (signed XML containing identity claims)     │
     │<─────────────────────────────────────────────────│
     │───────────────────────>                          │
     │                       │                          │
     │ 6. SP validates assertion signature and claims   │
     │                       │                          │
     │ 7. Session established, access granted           │
     │<──────────────────────│                          │

SAML Advantages

•Mature, well-understood protocol
•Wide enterprise adoption and tooling
•Rich attribute passing for authorization
•Established security practices
•Supports complex enterprise trust relationships

SAML Limitations

•Complex XML-based format
•Browser-based only (no native mobile support)
•No standard API access pattern
•Requires pre-established trust relationships
•Verbose message format

SAML Security Considerations:

1. Signature Validation: SAML assertions are XML-signed. Critical validation requirements:

Verify signature exists and covers assertion
Verify signature uses acceptable algorithm (reject MD5/SHA1 in 2024+)
Verify signing certificate chains to trusted IdP
Beware of signature wrapping attacks (multiple signatures)

2. Audience Restriction: Assertion must specify intended audience (SP entity ID). Reject assertions not intended for your SP.

3. Replay Prevention:

Check NotBefore and NotOnOrAfter conditions
Track consumed assertion IDs to prevent replay
Ensure clock synchronization with IdP

4. InResponseTo Validation: For SP-initiated flows, verify assertion responds to your AuthnRequest.

SAML Vulnerabilities (Historical):

Signature Wrapping: Attacker inserts malicious content alongside valid signature
XML External Entity (XXE): Parser vulnerabilities processing untrusted XML
Comment Injection: Breaking signature verification with XML comments
Golden SAML: Attacker with IdP signing key can forge any assertion

SAML vs. OIDC Decision:

Factor	Choose SAML	Choose OIDC
Enterprise web apps	✓
API access needed		✓
Mobile/native apps		✓
Existing IdP uses SAML	✓
New application build		✓
Developer simplicity		✓

Federation Trust

Both SAML and OIDC enable federation—trusting identity assertions from external organizations. This allows employees of company A to access applications hosted by company B using their home organization credentials, without B ever seeing A's passwords.

Protocol Security Analysis

Authentication protocols can be subtle beasts—a single missing check can create exploitable vulnerabilities. Security engineers must evaluate protocols systematically against known attack classes.

Security Properties to Evaluate:

1. Credential Protection:

Is the password/secret ever transmitted?
Is it protected from server-side exposure?
Can the credential be extracted from stored protocol artifacts?

2. Replay Protection:

Are messages bound to specific sessions?
Do nonces/challenges prevent reusing captured messages?
Is there temporal validity (timestamps, expiration)?

3. Man-in-the-Middle Resistance:

Does protocol authenticate both parties?
Is channel binding employed?
Can session keys be influenced by attacker?

4. Forward Secrecy:

If long-term keys are compromised, are past sessions protected?
Are session keys derived using ephemeral values?

5. Denial of Service:

Can attackers trigger expensive operations without authentication?
Are there asymmetric costs (cheap to attack, expensive to defend)?

Protocol Security Comparison
Protocol	Credential Protection	Replay Prevention	MITM Resistance	Forward Secrecy
HTTP Basic Auth	None (plaintext)	None	None	No
HTTP Basic + TLS	Transport only	Via TLS	Certificate validation	If TLS configured
NTLM	Hash-based	Challenge-response	None built-in	No
NTLMv2	Hash-based	Challenge-response + timestamp	Improved	No
Kerberos	Encrypted TGT	Authenticator timestamps	Mutual auth optional	Session-key derived
SCRAM	Stored salted	Nonce-based	Mutual auth + channel binding	Per-session
OAuth 2.0 + PKCE	Redirects only	State + code verifier	HTTPS required	Token expiration
WebAuthn/FIDO2	Never transmitted	Challenge-response	Origin bound	Per-assertion

Common Protocol Vulnerabilities:

1. Downgrade Attacks: Attacker forces parties to use weaker authentication:

TLS downgrade to cipher suites with known weaknesses
NTLM negotiation forced when Kerberos preferred
OAuth implicit flow forced instead of authorization code

Defense: Strict protocol version enforcement, signed capability negotiation.

2. Token/Ticket Theft:

Kerberos tickets stolen from memory
OAuth access tokens extracted from browser storage
Session cookies hijacked

Defense: Token binding, short lifetimes, secure storage, theft detection.

3. Confused Deputy:

OAuth client tricked into using token from wrong issuer
SAML SP accepting assertion from wrong IdP
API accepting authentication intended for different service

Defense: Audience validation, issuer verification, binding tokens to specific clients.

4. Time-Based Attacks:

Clock skew exploited to extend ticket/token validity
Timestamp rollback to reuse expired credentials
Race conditions in session establishment

Defense: Synchronized clocks, conservative validity windows, idempotency tokens.

Formal Verification:

Critical protocols undergo formal security analysis:

ProVerif: Symbolic analysis of cryptographic protocols
Tamarin Prover: Formal verification with unbounded sessions
BAN Logic: Belief-based protocol analysis

These tools have found vulnerabilities in TLS, OAuth, SAML, and other widely-deployed protocols before exploitation in the wild.

Protocol vs. Implementation

A secure protocol specification doesn't guarantee secure implementations. Buffer overflows, incorrect validation, poor random number generation, and logic errors can all undermine theoretically secure protocols. Always use vetted libraries rather than implementing protocols from scratch.

Zero Trust Authentication

Traditional network security assumed that internal networks were trusted and external networks were not. Zero Trust Architecture (ZTA) rejects this model: never trust, always verify.

Zero Trust Principles Applied to Authentication:

Verify explicitly: Always authenticate and authorize based on all available data points
Use least privilege access: Just-In-Time and Just-Enough-Access principles
Assume breach: Minimize blast radius; verify end-to-end

Authentication in Zero Trust:

Traditional: Authenticate once at network perimeter, then access internal resources freely.

Zero Trust: Authenticate and authorize every access request based on:

User identity (Who are you?)
Device health (Is your device trusted and secure?)
Location (Where are you connecting from?)
Time (Is this a normal access time?)
Resource sensitivity (What are you trying to access?)
Behavioral patterns (Does this fit your typical behavior?)

Zero Trust Authentication Components

•Strong Identity Verification — MFA required for all access, phishing-resistant factors preferred
•Device Trust Assessment — Verify device compliance, security posture, management status before granting access
•Continuous Authentication — Session monitoring, re-authentication for sensitive operations, behavior analysis
•Dynamic Policy Enforcement — Access decisions made in real-time based on current context, not static rules
•Encrypted Communications — All traffic encrypted regardless of network; no trusted networks
•Microsegmentation — Each resource has its own access policy; no lateral movement through trust

Continuous Authentication:

Zero Trust extends authentication beyond the initial login:

Traditional Session:
  [Login] ─────────────────────────────────────────> [Logout]
         Full access for entire session duration

Zero Trust Session:
  [Login] ─[Check]─[Check]─[Step-up Auth]─[Check]──> [Logout]
          Periodic re-verification, stronger auth for sensitive ops

Implementation Patterns:

Session risk scoring: Accumulate signals; require re-auth when risk exceeds threshold
Step-up authentication: Require additional factors for sensitive operations (financial transfers, admin actions)
Behavioral biometrics: Continuously analyze typing patterns, mouse movements
Device attestation: Periodically verify device state (no new vulnerabilities, still managed)

Architecture Integration:

Component	Zero Trust Role
Identity Provider	Central authentication authority; MFA; risk assessment
Access Proxy	Policy enforcement point; authenticates every request
Device Trust	MDM/EDR integration; compliance verification
Policy Engine	Real-time access decisions; context evaluation
SIEM/UEBA	Behavioral analysis; anomaly detection; threat intelligence

BeyondCorp: Google's Zero Trust Implementation

Google's BeyondCorp pioneered enterprise Zero Trust after the Aurora attacks (2009). Google eliminated VPN requirements, instead controlling access based on user identity and device state. Access decisions are made per-request, with no distinction between corporate and external networks.

Summary and Key Takeaways

Authentication protocols bridge the gap between user credentials and network security. From simple challenge-response to sophisticated federated identity systems, these protocols enable secure access across distributed systems without exposing secrets.

Key Takeaways

•Password transmission creates fundamental vulnerabilities — Eavesdropping, MITM, server exposure, and replay attacks all threaten transmitted credentials.
•Challenge-response protocols protect credentials — By computing responses from challenges and secrets, passwords never traverse the network.
•Kerberos enables enterprise SSO — Ticket-based authentication allows users to access multiple services after single login; trusted third party (KDC) brokers trust.
•OAuth 2.0 is authorization, not authentication — Use OIDC (which adds ID tokens) for authentication; use OAuth for delegated API access.
•SAML dominates enterprise web SSO — XML-based assertions enable cross-organization federation; requires careful security implementation.
•Protocol security requires systematic analysis — Evaluate credential protection, replay resistance, MITM resistance, and forward secrecy.
•Zero Trust requires continuous authentication — Never assume trust based on network location; verify every access request contextually.

Looking Ahead:

Authentication establishes who the user is; the credential storage behind that authentication determines how resilient the system is to compromise. The next page explores Password Storage—the algorithms and architectures that protect credentials at rest.

Page Complete

You now understand the major authentication protocols from challenge-response to Kerberos to OAuth/OIDC to SAML. This knowledge enables you to select appropriate protocols, implement them securely, and analyze authentication architectures for vulnerabilities.