doc/html/_sources/admin/dictionary.rst.txt

   1 .. _dictionary:
   2
   3 Addressing dictionary attack risks
   4 ==================================
   5
   6 Kerberos initial authentication is normally secured using the client
   7 principal's long-term key, which for users is generally derived from a
   8 password.  Using a pasword-derived long-term key carries the risk of a
   9 dictionary attack, where an attacker tries a sequence of possible
  10 passwords, possibly requiring much less effort than would be required
  11 to try all possible values of the key.  Even if :ref:`password policy
  12 objects <policies>` are used to force users not to pick trivial
  13 passwords, dictionary attacks can sometimes be successful against a
  14 significant fraction of the users in a realm.  Dictionary attacks are
  15 not a concern for principals using random keys.
  16
  17 A dictionary attack may be online or offline.  An online dictionary
  18 attack is performed by trying each password in a separate request to
  19 the KDC, and is therefore visible to the KDC and also limited in speed
  20 by the KDC's processing power and the network capacity between the
  21 client and the KDC.  Online dictionary attacks can be mitigated using
  22 :ref:`account lockout <lockout>`.  This measure is not totally
  23 satisfactory, as it makes it easy for an attacker to deny access to a
  24 client principal.
  25
  26 An offline dictionary attack is performed by obtaining a ciphertext
  27 generated using the password-derived key, and trying each password
  28 against the ciphertext.  This category of attack is invisible to the
  29 KDC and can be performed much faster than an online attack.  The
  30 attack will generally take much longer with more recent encryption
  31 types (particularly the ones based on AES), because those encryption
  32 types use a much more expensive string-to-key function.  However, the
  33 best defense is to deny the attacker access to a useful ciphertext.
  34 The required defensive measures depend on the attacker's level of
  35 network access.
  36
  37 An off-path attacker has no access to packets sent between legitimate
  38 users and the KDC.  An off-path attacker could gain access to an
  39 attackable ciphertext either by making an AS request for a client
  40 principal which does not have the **+requires_preauth** flag, or by
  41 making a TGS request (after authenticating as a different user) for a
  42 server principal which does not have the **-allow_svr** flag.  To
  43 address off-path attackers, a KDC administrator should set those flags
  44 on principals with password-derived keys::
  45
  46     kadmin: add_principal +requires_preauth -allow_svr princname
  47
  48 An attacker with passive network access (one who can monitor packets
  49 sent between legitimate users and the KDC, but cannot change them or
  50 insert their own packets) can gain access to an attackable ciphertext
  51 by observing an authentication by a user using the most common form of
  52 preauthentication, encrypted timestamp.  Any of the following methods
  53 can prevent dictionary attacks by attackers with passive network
  54 access:
  55
  56 * Enabling :ref:`SPAKE preauthentication <spake>` (added in release
  57   1.17) on the KDC, and ensuring that all clients are able to support
  58   it.
  59
  60 * Using an :ref:`HTTPS proxy <https>` for communication with the KDC,
  61   if the attacker cannot monitor communication between the proxy
  62   server and the KDC.
  63
  64 * Using FAST, protecting the initial authentication with either a
  65   random key (such as a host key) or with :ref:`anonymous PKINIT
  66   <anonymous_pkinit>`.
  67
  68 An attacker with active network access (one who can inject or modify
  69 packets sent between legitimate users and the KDC) can try to fool the
  70 client software into sending an attackable ciphertext using an
  71 encryption type and salt string of the attacker's choosing.  Any of the
  72 following methods can prevent dictionary attacks by active attackers:
  73
  74 * Enabling SPAKE preauthentication and setting the
  75   **disable_encrypted_timestamp** variable to ``true`` in the
  76   :ref:`realms` subsection of the client configuration.
  77
  78 * Using an HTTPS proxy as described above, configured in the client's
  79   krb5.conf realm configuration.  If :ref:`KDC discovery
  80   <kdc_discovery>` is used to locate a proxy server, an active
  81   attacker may be able to use DNS spoofing to cause the client to use
  82   a different HTTPS server or to not use HTTPS.
  83
  84 * Using FAST as described above.
  85
  86 If :ref:`PKINIT <pkinit>` or :ref:`OTP <otp_preauth>` are used for
  87 initial authentication, the principal's long-term keys are not used
  88 and dictionary attacks are usually not a concern.