Why is a group-managed service account effectively immune to roasting while a human-set service password is cheap to crack?

## The attack reduces to one inequality Once an attacker holds the sealed material from a roasted account, cracking is a search: 1. guess a password, 2. derive the candidate key from it, 3. test the key against the blob, 4. repeat until one matches. So the whole question of 'is this account safe' collapses to a comparison between two numbers — the size of the space the true password lives in, and how much of that space the attacker can afford to search. ## Cost ≈ keyspace × per-guess cost - ***Keyspace*** is how many distinct passwords are plausible. - ***Per-guess cost*** is the compute to derive and test one candidate. A modern GPU tests enormous numbers of candidates per second because the derivation here is fast. Multiply keyspace by per-guess cost and you have the **total work**; compare it to the attacker's budget in GPU-hours. ## Why a human password is cheap People do not pick uniformly from all strings. A service password a human sets is typically 8–12 characters drawn from a small, predictable distribution — a word, a season, a year, a couple of substitutions — often set once at install and never changed. - Its *effective* **keyspace** (what an attacker actually has to search, guided by wordlists and rules) is tiny. - A single commodity GPU box can exhaust that in hours to a few days. - Length and a sprinkle of symbols raise the number a little, but not by the many orders of magnitude that would matter. ## Why a group-managed service account (gMSA) is immune A **gMSA** does not have a human-chosen password at all. The directory generates the password itself — roughly 120 characters of random data — and rotates it automatically. Computer accounts work the same way. There is no word, no pattern, no wordlist that helps; the attacker is forced to brute the full random keyspace, which is astronomically large. No feasible amount of compute searches it, so the account is roastable in the mechanical sense and safe in the economic one. This is the single most reliable defense: **remove the human-chosen password**, and the arithmetic ends the attack by construction. ## The sealing algorithm is a multiplier, not a wall The material can be sealed under different encryption types — an older, faster one (`RC4`) or a newer one (`AES`). - Switching to AES raises the per-guess cost by a roughly **constant factor**: each candidate takes a bit more compute to test, so the grind runs slower. - But a constant multiplier on a small keyspace is still a small number. If a weak password fell in a day under the fast algorithm, it falls in a few days under the slow one. AES buys time; it does not buy safety. This is why 'we forced AES' is a partial mitigation at best when the passwords behind the accounts are still human-chosen. ## Why there is no work factor to dial up Deliberately slow password storage uses a **key-derivation function** with a tunable *work factor* precisely so each guess is expensive. The key used to seal this material is derived by a fast function with no such knob — that is structural to how the directory works, not a setting the defender left low. So the defender cannot make guessing expensive from the algorithm side. The only lever left is the *entropy of the password itself*, which is exactly why machine-generated keys are the answer and a stronger-looking human password is not. ## The interview-ready summary - Cracking cost is keyspace times per-guess cost. - Humans supply a tiny keyspace; the machine supplies an enormous one. - The encryption type scales per-guess cost by a constant and never changes the verdict for a weak password. Therefore the fix is not a better algorithm or a longer human password — it is a **machine-generated key**.