If we were to implement sesame instead of kerberos, what would it uses instead of tickets?

The Kerberos authentication protocol has plenty of benefits but offers little defense against pass-the-hash attacks

Several readers responded to my previous post on pass-the-hash attacks, asking if Kerberos authentication versus LANManager, NTLM, or NTLMv2 was an effective defense. It's a good question, one that I considered as I was writing last week's post. Reader Christopher Hallenbeck made some especially good arguments for it, and I've reconsidered my original stance on discussing the subject.

Invented at MIT, Kerberos is an open authentication protocol used on a variety of computer systems. Kerberos systems pass cryptographic key-protected authentication "tickets" between participating services. The password hashes are neither sent nor stored, so they can't be captured and reused as easily.

Kerberos is the default authentication protocol implemented in Windows 2000. More recent operating systems use Kerberos to connect to Windows 2000 and to later network Kerberos-protected resources and services. In most of today's Windows networks, Kerberos authentication is widespread. Kerberos has the potential to reduce pass-the-hash risk, but not nearly as much as one would initially think.

For one, pass-the-hash attacks only work against interactive -- right at the computer -- logons. In Windows, password hashes are not sent or stored on the remote server or hosting process in Windows over network connections (with the notable exception of RDP connections), whether using NTLM/NTLMv2 or Kerberos. The attacker can only capture password hashes that are stored on the local computer in the SAM or Active Directory database or from users logged on interactively. The idea that the attacker will gain elevated access to a server computer and capture the passwords of every user connected over the network isn't realistic. In most cases, Kerberos doesn't offer a lot of protection over NTLM/NTLMv2.

Second, when a user logs on interactively to a computer that uses Kerberos, his or her NT password hash is stored in the computer's memory and is available to be stolen. This is because all Windows computers must support at least one other authentication protocol, such as LanManager, NTLM, or NTLMv2. Prior to Windows Server 2008, the NT hash was used in what is called the pre-auth part of Kerberos, although AES is utilized in W2K8 and later OS versions.

Notably, starting with Windows 7 and Windows Server 2008 R2, authentication protocols other than Kerberos can be turned off via a feature called Restrict NTLM. However, it is difficult to implement in most normal operational environments.

In most networks, the older authentication protocols run all the time. For instance, many applications and services don't understand Kerberos or accept their authentication tickets. Some applications, such as Microsoft SharePoint, understand Kerberos but come enabled with NTLM by default for compatibility purposes. Many proxy and load balancers don't allow Kerberos to function but will readily pass NTLM. By default, network servers referenced by IP address instead of DNS or NetBIOS name won't use Kerberos. Older or underconfigured Samba installs won't use Kerberos, and so on.

It's the extremely rare Windows network that doesn't have a lot of NTLM authentication running all the time. In most cases, the NT hash is stored on the originating computer even if only Kerberos is being used.

It's also important to remember that highly privileged access is required to obtain the hashes in the first place. If the attacker has the necessary access to look at NT hashes, he or she can also get to the Kerberos TGT (ticket-granting ticket) and essentially "pass the TGT" instead.

You have some protection -- I know of no publically available tools for exploiting Kerberos. It would be difficult for an attacker to create such tools, but a hacker could simply use a memory scanner or disassembly such as IdaPro to do the dirty deed. (Note: The NT hash is stored and retrievable from the Kerberos TGT, as well, except on the latest Windows OS versions.)

Authenticator capturing and reuse is a problem for all symmetric-based authentication systems, including most Kerberos implementations. In Unix, Linux, and BSD, Kerberos can be used asymmetrically, but it isn't in the majority of cases. You can also use other asymmetric authentication processes, such as Sesame, smart cards, crypto key fobs, and biometrics, but each system has its own challenges and weaknesses -- which is a topic unto itself. For example, many smart-card scenarios use password hashes behind the scenes, and many biometric devices require passwords to work. Computer security is a tougher than it looks.

Some readers touted Kerberos' anti-replay mechanisms. While Kerberos does have some limited anti-replay features, pass-the-hash attacks are not replay attacks. Pass-the-hash attacks take the ultimate authentication secret, the password hash, and use it in new sessions.

SANS has two PDFs available on the topic: Pass-the-has attacks: Tools and Mitigation and Why Crack When You Can Pass the Hash? Despite some technical errors, they contain enough tested information that any reader interested in more analysis should peruse them. The latter paper is especially enlightening.

Additionally, there's an excellent paper on Kerberos hacking, including some of the TGT exploits [PDF] I briefly referenced earlier, available at blackhat.com.

Kerberos may be able to reduce pass-the-hash risk in some specific scenarios, but it doesn't significantly reduce risk in most environments. Still, there are at least a half-dozen better reasons (performance, other security protections, mutual authentication) Kerberos should be used instead of the older authentication protocols. Realistically, however, once the attacker has the elevated access needed to mount pass-the-hash attacks, such assaults are  one of a thousand new risks.

An security columnist since 2005, Roger Grimes holds more than 40 computer certifications and has authored ten books on computer security.

Copyright © 2010 IDG Communications, Inc.