A look into authentication: Hashes

Welcome to the next part of our series on authentication. In our previous post, we covered passwords: the foundation of most authentication systems. Now, we’ll delve into a critical aspect of authentication security—hashing. This blog will explore how operating systems like Windows, Linux, and macOS use hashing to protect passwords, the weaknesses of earlier methods, and how modern systems have evolved to enhance security.

What are password hashes?

A password hash is a fixed-length string derived from a password using a cryptographic function. Unlike encryption, hashing is one-way: it cannot be reversed to reveal the original password. Instead, when a user logs in, their entered password is hashed and compared with the stored hash. If the hashes match, access is granted.

Hashing protects passwords from direct exposure. Even if a system’s password database is stolen, the attacker would only have the hashes, which are much harder (though not impossible) to crack.

To aid with security hashing sometimes uses salt (or pepper) to add a ‘random’ value to the password before hashing to make brute force attack more difficult and also to make the use of pre-computed hashes (known as rainbow tables) less effective. The difference between salt and pepper (aside from the taste) is that a salt stores the random value with the hash, and a pepper does not.

Windows hashing mechanisms: LAN Manager, NTLM, and NTLMv2

LAN Manager (LM)

One of the earliest hash types used by Windows, the LM hash, dates back to MS-DOS. Unfortunately, LM hashes were riddled with security flaws:

Case insensitivity: Passwords were converted to uppercase, reducing complexity.
Splitting: Passwords were split into two 7-character chunks, making brute-forcing faster.
No salting: Salts (random data added to passwords before hashing) were absent, making identical passwords produce identical hashes.

The LM hash is calculated by converting the password to uppercase, padding or truncating it to 14 characters, splitting it into two 7-character chunks, and encrypting each chunk using DES.

NTLM (NT LAN Manager)

Introduced to replace LM hashes, NTLM hashes significantly improved security:

Passwords could now be up to 127 characters.
The hash was generated by encoding the password in UTF-16, hashing it with the MD4 algorithm, and storing the result as the NT hash.

However, NTLM lacked salting, making it vulnerable to rainbow table attacks—a precomputed set of hashes for common passwords.

NTLMv2

NTLMv2 further enhanced security by incorporating a challenge-response mechanism and stronger cryptography:

When a client requests access, the server sends a challenge.
The client responds with an HMAC-MD5 hash of the NT hash, the challenge, and other session-specific data.

This approach adds randomness to each session, mitigating replay attacks and precomputed rainbow table attacks.

Kerberos and the evolution of windows authentication

Modern Windows systems use the Kerberos protocol, which relies heavily on hashing and encryption for secure authentication. Kerberos uses a ticketing system, where users prove their identity and receive cryptographically secure tickets to access resources.

hashing in Kerberos

Password hashing: Kerberos derives cryptographic keys by hashing the password using salts based on the format username@REALM.COM.
Ticket encryption: Ticket-granting tickets (TGTs) are encrypted using AES or (in older systems) RC4 or DES.

DES and RC4 weaknesses

DES: Vulnerable to brute-force attacks due to its short 56-bit key length.
RC4: While faster than DES, RC4 is flawed because it allows keys derived from NT hashes (unsalted) to authenticate users, exposing it to offline attacks.

Modern Kerberos implementations use AES encryption, providing robust protection against these attacks.

The Security Account Manager (SAM) database on Windows

Windows stores local account hashes in the SAM database. This database has evolved significantly:

Legacy protection

Earlier systems used SYSKEY, which encrypted the SAM database with DES-based encryption. However, SYSKEY was deprecated in Windows 10 due to its vulnerabilities.

Modern protection

Starting with Windows 10, the SAM is now protected using the same encryption mechanisms as Active Directory, including AES encryption and integration with the Data Protection API (DPAPI). Advanced features like Credential Guard and virtualisation-based security (VBS) isolate the SAM from the operating system, making it resistant to malware and offline attacks.

Hashing on Linux and macOS

Linux: /etc/shadow

Linux stores password hashes in the /etc/shadow file, a secured file only accessible by privileged users. Unlike Windows, Linux has used salting for decades:

Salts are random data appended to the password before hashing, ensuring that identical passwords produce different hashes.
Modern Linux systems use hashing algorithms like SHA-512, bcrypt, or PBKDF2, which are computationally expensive, slowing down brute-force attempts.

macOS

macOS stores password hashes in its Keychain and uses hashing mechanisms similar to Linux, with PBKDF2 as a common choice.

Modern defences: salting, stretching, and iteration

Salting

Salting adds random data to a password before hashing it, ensuring that even if two users have the same password, their hashes are unique.

Windows Kerberos: Salt = username@REALM.COM. However, this introduces challenges when a username changes, requiring Active Directory to temporarily store old salts in the SupplementalCredentials attribute.
Linux: Salts are randomly generated and stored alongside the hash in /etc/shadow.

Stretching and iteration

Modern systems use key stretching to make hashing computationally expensive:

bcrypt and PBKDF2: Both involve repeated hashing of the password and salt, making brute-forcing much slower.

Why modern hashing matters

Today’s security threats, including rainbow table and offline brute-force attacks, make robust hashing algorithms essential. Here’s why:

Salting thwarts rainbow tables.
Slow hashing functions like bcrypt or PBKDF2 deter attackers by making each attempt costly.
Encryption and isolation mechanisms (e.g., SAM protected by DPAPI and VBS) prevent attackers from easily accessing stored hashes.

Conclusion

The journey from LAN Manager to modern password hashing highlights an evolution driven by the need to address growing security threats. While legacy systems like LM and RC4 lacked the sophistication to resist modern attacks, today’s protocols (e.g., Kerberos with AES, bcrypt, and PBKDF2) incorporate advanced cryptographic protections.

In the next blog post on authentication we will expand to talk about credentials and how they are stored in various systems