15

In http://www.freebsd.org/doc/handbook/kerberos5.html section 15.7.8.3 “The KDC is a Single Point of Failure” you can read:

By design, the KDC must be as secure as the master password database is contained on it. The KDC should have absolutely no other services running on it and should be physically secured. The danger is high because Kerberos stores all passwords encrypted with the same key (the “master” key), which in turn is stored as a file on the KDC.

Doesn't that mean that this is an Achilles' heel of Kerberos since if the KDC is compromised, the attacker will know all users' plaintext passwords (as opposed to getting /etc/shadow of a Linux system which will only provide the attacker with the hashed and salted passwords)?

mgd
  • 555
  • 2
  • 5
  • 9

2 Answers2

11

The short answer is: no.

It knows a secret key that may be derived from the user password. The specification RFC 1510 says in the introduction of section 6:

It is desirable for the string to key function to be one-way, and for the mapping to be different in different realms. This is important because users who are registered in more than one realm will often use the same password in each, and it is desirable that an attacker compromising the Kerberos server in one realm not obtain or derive the user's key in another.

Note that there is no random salt unique for every account, just the realm name which is shared among all users of the same realm.

The updated version RFC 4120 allows other way to derive the key:

The user key might be stored on a smart-card, or otherwise obtained independently of a password.

Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
  • Thank you for the clarification. If the password database is stolen is it then possible to login using the stored user keys (e.g. by using a modified version of `kinit` that bypasses the generation of the key from the password and the realm)? – mgd Jun 09 '12 at 18:31
  • You mean the Kerberos database, which as Hendrik said contains keys derived from passwords, rather than the passwords themselves. The answer is yes, and you don't need a modified kinit; it can already read the keys from a given keytab file rather than prompting for a password. – Richard E. Silverman Jan 15 '15 at 01:13
9

The answer is both yes and no, depending on what you mean. In the basic Kerberos model, ordinarily each principal in a realm shares a secret with the Kerberos authentication servers (Key Distribution Centers, or KDCs). (I say “ordinarily” because principals which will act only as clients can avoid sharing a secret and instead use other methods to authenticate to the KDC, e.g. an RSA key pair via PKINIT, or one-time passwords, which avoids the password-guessing issue discussed here entirely.) For a software component like a web server, this is a set of randomly generated keys; there is a set rather than just one, to accommodate clients with support for various cryptographic ciphers. For a user, it is a set of keys derived from the user’s password. So the KDC holds all the secrets: if it is compromised, an attacker can impersonate any principal in the KDC’s realm.

However, the KDC does not actually have the user’s password, only a set of keys derived from the password. This distinction is not important as far as Kerberos itself is concerned: the keys are the actual Kerberos secret. However, people often reuse passwords for various systems; so, if a KDC is compromised, the attacker will not immediately have the user’s password with which to try to access their GMail account, for example (though he can now mount a dictionary attack to try to discover the password).

Doesn't that mean that this is an Achilles' heel of Kerberos since if the KDC is compromised, the attacker will know all users' plaintext passwords (as opposed to getting /etc/shadow of a Linux system which will only provide the attacker with the hashed and salted passwords)?

It is a property of Kerberos; I wouldn’t call it an “Achilles’ heel.” The Unix password-hash scheme allows it to do one thing: verify plaintext passwords, which must be handed to the server. Systems like Kerberos and PKI can do far more than that, and they have more secrets to protect, distributed in various ways determined by the respective technologies. PKI doesn’t have a single store with all user keys — but it does have the highly sensitive keys of certification authorities (CAs), which must be protected with just as much vigilance as the Kerberos principal database, since stealing a CA private key similarly allows an attacker to impersonate many principals in the system. It may be easier to protect a CA private key than the KDC database since the latter must be online for KDC operation, whereas the former need only be available for relatively infrequent signing operations (though that depends on the nature and use of the CA in question). On the other hand, Kerberos password-based authentication does not require a secondary store or extra equipment (such as a smartcard) to hold the user’s private key and trusted CA certificates, and its symmetric cryptography is much faster than the public-key operations of PKI. And so on… there are many comparisons and tradeoffs.

Richard E. Silverman
  • 651
  • 5
  • 7