Why does a Kerberos service ticket sealed with etype 23 rc4-hmac fall to offline guessing faster than one sealed with etype 18?

seniormust knowfreq 58%

answer

the ticket is sealed under one key
whose password is the target
cost per guess, and reuse
unsalted single pass versus iterated
string-to-key with salt and iteration count

basics

~20 s

Etype 23 derives the service principal's long-term key from an unsalted single-pass digest of its password, so one guess costs one digest and work is reusable. Etype 18 uses a salted, iterated string-to-key, making each guess far dearer and reuse impossible.

solid answer

~40 s

A service ticket's enc-part is sealed under the service principal's long-term key, so whoever holds the ticket can test candidate passwords offline: derive a key, attempt decryption, check whether the profile's integrity checksum verifies. The etype decides what one attempt costs. rc4-hmac (etype 23, RFC 4757) derives the long-term key with a single unsalted digest pass over the password, so an attempt is one hash and precomputed work is reusable against every principal with the same password in any realm. aes256-cts-hmac-sha1-96 (etype 18, RFC 3962) derives it with a salted, iterated string-to-key whose parameters the KDC publishes, so every attempt costs thousands of hash operations and nothing carries across principals. The limit is important: etype 18 raises cost per guess; only a long machine-generated key removes the target.

A service ticket's `enc-part` is sealed under the **service principal's long-term key**, so whoever holds the ticket can test candidate passwords offline: derive a key, attempt decryption, check whether the profile's integrity checksum verifies. The etype decides what one attempt costs. `rc4-hmac` (etype 23, RFC 4757) derives the long-term key with a single unsalted digest pass over the password, so an attempt is one hash and precomputed work is reusable against every principal with the same password in any realm. `aes256-cts-hmac-sha1-96` (etype 18, RFC 3962) derives it with a salted, iterated `string-to-key` whose parameters the KDC publishes, so every attempt costs thousands of hash operations and nothing carries across principals. The limit is important: etype 18 raises cost per guess; only a long machine-generated key removes the target.

code

pseudocode · 11 lines

pseudocode

// cost of ONE candidate password, per profile

function attempt(candidate, ticket_enc_part, etype, salt, s2kparams):
    if etype = 23:
        key = digest(candidate)                    // one pass, no salt
    else if etype = 18:
        key = string_to_key(candidate, salt, s2kparams)  // salted, iterated
    plaintext = decrypt(ticket_enc_part, key)
    if checksum_verifies(plaintext):
        return candidate
    return none

go deeper

for a junior

Recall that a service ticket is encrypted with the service account's own key, so anyone holding the ticket can try to guess that key without contacting the server again.

for a middle

Explain the guess loop — derive a key, decrypt, check the integrity checksum — and why an unsalted single-pass derivation makes each attempt vastly cheaper than an iterated one.

for a senior

Demonstrate that you price the exposure rather than label it: cost per guess, reuse across principals, which principal's key is actually at risk, and what a generated key changes.

for a principal

Argue where the estate's remaining password-derived service keys are, and whether repricing guesses or removing password-derived keys altogether is the investment worth making.

Why a ticket is an offline target at all

A Kerberos service ticket is sealed under the long-term key of the service principal it names. That is deliberate: the requester must be able to carry the ticket to the service without being able to read or alter it, and the service must be able to open it with a key it already holds, without calling back to the KDC. The consequence is that anyone who obtains the ticket holds a ciphertext encrypted under a key that may ultimately be derived from a human-chosen password — and they can attack it offline, with no further traffic to the KDC and nothing to rate-limit or log.

The test loop is short:

Guess a password.
Run the profile's string-to-key over it, with the salt the profile requires.
Attempt to decrypt the ticket's enc-part with the resulting key.
Accept the guess if the profile's integrity checksum verifies.

Every step is fixed by the profile except step 1. So the etype is the cost function.

Where the two profiles differ

	`rc4-hmac` (etype 23, RFC 4757)	`aes256-cts-hmac-sha1-96` (etype 18, RFC 3962)
string-to-key input	password only	password, salt, string-to-key parameters
iterations	one pass	an iteration count, default 4096
salt	none	the principal's salt, published in `pa-etype-info2`
work reusable across principals	yes	no
cost of one guess	one digest	thousands of hash operations

Two separate things are happening, and candidates usually name only the first:

Cost per guess. An unsalted single-pass derivation makes one attempt as cheap as one hash. An iterated derivation multiplies that by the iteration count, which is a three-to-four order of magnitude difference before any hardware is considered.
Reuse. Because etype 23's derivation takes no salt, the same password produces the same long-term key for any principal in any realm. Work spent once applies everywhere, and tables can be precomputed before a single ticket is captured. A salt destroys that: work spent against one principal is worthless against the next, even with the identical password.

Which key, and therefore whose password

Be precise about the key, because three different ones are in play and they have three different blast radii:

The ticket-granting ticket is sealed under the realm's krbtgt key — one key for the whole realm.
The session key delivered beside it is encrypted under the client's long-term key.
A service ticket is sealed under that one service principal's long-term key.

So the offline target in a captured service ticket is exactly one service principal's password, and the damage is bounded by what that principal can do. It is also why the etype that matters is the one the service principal has a key for, not the one the client supports: the KDC seals the ticket with a key the service can open.

What changing the etype does and does not do

Moving a service principal from etype 23 to etype 18 does three things: it raises the per-guess cost by the iteration count, it introduces a salt so precomputation cannot be reused, and it removes a profile whose encryption and checksum constructions are themselves obsolete. It does not make a weak password safe — a short dictionary word survives an iterated derivation, only more slowly — and it does not stop the ticket being requested or captured in the first place. The only change that removes the target rather than repricing it is a long, machine-generated key that no string-to-key over a human password could ever produce.

Note also what does not change: the client still cannot read the ticket under either etype, because the client does not hold the service principal's key. The etype is about the economics of guessing that key, not about who may open the ticket.

Reading it in practice

In a depot whose stock-control services were registered years apart, the etype tells you which service accounts are cheap targets and which are not, independently of any attack you have observed. Two facts settle it: which etypes each service principal holds a key for, and whether that key came from a typed password or was generated. A principal holding only an rc4-hmac key and a password a person chose is the whole finding; one holding an etype 18 key derived from a long random string is not, even though both are sealed the same way on the wire.

Version note. Etype 23 is deprecated, not removed, and remains present in mixed estates precisely because one party without an AES key keeps it alive for everyone on that path.

## Why a ticket is an offline target at all A Kerberos **service ticket** is sealed under the **long-term key of the service principal it names**. That is deliberate: the requester must be able to carry the ticket to the service without being able to read or alter it, and the service must be able to open it with a key it already holds, without calling back to the KDC. The consequence is that anyone who obtains the ticket holds a ciphertext encrypted under a key that may ultimately be derived from a human-chosen password — and they can attack it **offline**, with no further traffic to the KDC and nothing to rate-limit or log. The test loop is short: 1. Guess a password. 2. Run the profile's `string-to-key` over it, with the salt the profile requires. 3. Attempt to decrypt the ticket's `enc-part` with the resulting key. 4. Accept the guess if the profile's integrity checksum verifies. Every step is fixed by the profile except step 1. So the **etype is the cost function**. ## Where the two profiles differ | | `rc4-hmac` (etype 23, RFC 4757) | `aes256-cts-hmac-sha1-96` (etype 18, RFC 3962) | |---|---|---| | string-to-key input | password only | password, salt, string-to-key parameters | | iterations | one pass | an iteration count, default 4096 | | salt | none | the principal's salt, published in `pa-etype-info2` | | work reusable across principals | yes | no | | cost of one guess | one digest | thousands of hash operations | Two separate things are happening, and candidates usually name only the first: - **Cost per guess.** An unsalted single-pass derivation makes one attempt as cheap as one hash. An iterated derivation multiplies that by the iteration count, which is a three-to-four order of magnitude difference before any hardware is considered. - **Reuse.** Because etype 23's derivation takes no salt, the same password produces the same long-term key for **any** principal in **any** realm. Work spent once applies everywhere, and tables can be precomputed before a single ticket is captured. A salt destroys that: work spent against one principal is worthless against the next, even with the identical password. ## Which key, and therefore whose password Be precise about the key, because three different ones are in play and they have three different blast radii: - The **ticket-granting ticket** is sealed under the realm's `krbtgt` key — one key for the whole realm. - The **session key** delivered beside it is encrypted under the **client's** long-term key. - A **service ticket** is sealed under **that one service principal's** long-term key. So the offline target in a captured service ticket is exactly one service principal's password, and the damage is bounded by what that principal can do. It is also why the etype that matters is the one the *service principal* has a key for, not the one the client supports: the KDC seals the ticket with a key the service can open. ## What changing the etype does and does not do Moving a service principal from etype 23 to etype 18 does three things: it raises the per-guess cost by the iteration count, it introduces a salt so precomputation cannot be reused, and it removes a profile whose encryption and checksum constructions are themselves obsolete. It does **not** make a weak password safe — a short dictionary word survives an iterated derivation, only more slowly — and it does **not** stop the ticket being requested or captured in the first place. The only change that removes the target rather than repricing it is a **long, machine-generated key** that no `string-to-key` over a human password could ever produce. Note also what does not change: the client still cannot read the ticket under either etype, because the client does not hold the service principal's key. The etype is about the economics of guessing that key, not about who may open the ticket. ## Reading it in practice In a depot whose stock-control services were registered years apart, the etype tells you which service accounts are cheap targets and which are not, independently of any attack you have observed. Two facts settle it: which etypes each service principal holds a key for, and whether that key came from a typed password or was generated. A principal holding only an `rc4-hmac` key and a password a person chose is the whole finding; one holding an etype 18 key derived from a long random string is not, even though both are sealed the same way on the wire. **Version note.** Etype 23 is deprecated, not removed, and remains present in mixed estates precisely because one party without an AES key keeps it alive for everyone on that path.

Which key would an offline attempt against a captured ticket-granting ticket target instead?
The realm's `krbtgt` key, because every ticket-granting ticket in the realm is sealed under it. That is a different blast radius entirely: a service ticket exposes one service principal, while the `krbtgt` key underwrites every ticket-granting ticket the realm has issued, which is why it is normally a long generated key rather than one derived from a typed password.
If the salt is published to any client that asks, how does it help?
A salt is not a secret and is not meant to be one. Its job is to make the derivation unique per principal, so that work done against one principal's password cannot be reused against another with the same password, and so that tables cannot be precomputed before a specific target is chosen. It raises total cost, not the cost of a single guess.
A service principal now holds an etype 18 key. Does that end the exposure?
No. It reprices the guessing: every attempt now costs an iterated, salted derivation instead of one digest, and precomputation no longer carries across principals. A short human-chosen password still falls, only more slowly. The exposure ends when the principal's key is long and machine-generated, because no password guess can reach it.

saying these in an interview costs you the question

Says AES tickets cannot be attacked offline at all
Claims the client can read a service ticket it was handed
Thinks the client's etype decides how the ticket is sealed
Believes the salt must be kept secret to work
Names speed only and misses the reuse of unsalted work
Treats the krbtgt key and a service key as one target

Why does a Kerberos service ticket sealed with etype 23 rc4-hmac fall to offline guessing faster than one sealed with etype 18?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Why a ticket is an offline target at all

Where the two profiles differ

Which key, and therefore whose password

What changing the etype does and does not do

Reading it in practice

▾common follow-ups3 questions

▾red flags6 flags

Why a ticket is an offline target at all

Where the two profiles differ

Which key, and therefore whose password

What changing the etype does and does not do

Reading it in practice

answer

go deeper