If the adversary is 'just a kid with one laptop', are your roastable service accounts safe?

**Why the question is framed to mislead.** 'Just a kid with one laptop' invites you to reason about the *actor* — his skill, his hardware — and conclude that a small actor is a small threat. For roasting, that reasoning is wrong twice over, and a principal-level answer names both errors before offering a defensible statement of safety. **Error one: compute is rentable, so actor size is the wrong axis.** Roasting's cost lives in the offline crack, and cracking compute is a commodity. A single laptop is irrelevant to what a determined but unfunded person can bring, because a rack of cloud GPUs rents for a weekend at the price of a night out. There is no lockout and no rate limit to slow the grind, so the only thing standing between the attacker and a human-chosen password is its keyspace — and a weekend of rented GPUs clears a far larger keyspace than 'one laptop' suggests. The correct axis is not *how big is the attacker* but *how much of this password's keyspace can be searched for a plausible budget*. **Error two: safety is a per-account property, not a per-adversary one.** Because it comes down to keyspace versus budget, 'are we safe' has no single answer for the estate — it has one answer per account. The account with a random machine-generated key is safe against any budget; the account with an eight-character human password is unsafe against a hobbyist's weekend. So the honest defense enumerates accounts, not adversaries: which passwords have enough entropy to survive a realistic rented-compute budget, and which do not. **Blast radius is the second half of the risk.** Crackability is only half the picture; the other half is what a cracked password *reaches*. The characteristic bad outcome is a service password that doubles as the **local administrator credential on the app servers it runs** — one crack, and the attacker owns that tier; if the password is shared across services, he owns all of them. So an account cannot be called 'safe' on password strength alone if a single crack of it would cascade. Risk = crack-probability × reach, and reach is frequently the term that makes a mediocre password unacceptable. **Why 'we're fully patched' is no answer.** Roasting is not a software flaw. There is no CVE and no patch, because roastability is a *design property* of an account that carries an SPN or pre-auth-off together with a human-chosen password. Currency on updates changes nothing. Naming this explicitly is part of the principal answer, because leadership frequently reaches for 'are we patched' as a proxy for 'are we safe,' and here the two are unrelated. **The only structural fix, and its organisational cost.** The one move that ends the attack by construction is to **remove the human-chosen password** — convert the account to a machine-generated key (a group-managed service account) or, where the SPN is not actually needed, remove it. That is a control that takes away the thing the attack depends on, not a monitoring or a mitigation. But it does not come free at estate scale: a legacy estate may run hundreds of service accounts across apps of every vintage, and a fraction of vendor products simply cannot use a machine-generated key. So the strategy is a prioritised migration, not a flag day: 1. **Rank by blast radius.** Order the human-passworded service accounts by what a single crack would reach — local-admin reuse, privileged group membership, access to sensitive data. 2. **Convert the top of the list first** to machine-generated keys; these are the accounts where crackability meets consequence. 3. **Bound the residue.** For the handful of vendor apps that cannot accept a machine-generated key, treat them as tracked residual risk: constrain what those accounts can touch, remove reuse so a crack cannot cascade, and record the acceptance with an owner. **The defensible closing statement.** 'Safe' is not a property of the adversary's laptop. It is a property of each account: the machine-keyed ones are safe by construction; the human-passworded ones are safe only until someone spends a weekend of rented compute, and the ones whose crack would reach the app tier are not safe at all. The organisation's real decision is the migration order and what residual legacy risk it will own — that is the principal call, and it survives whether the adversary turns out to be a bored student or a funded crew.