Password and cryptographic attacks, and the controls that end them

Objective 2.4 in this course covers malicious activity. The previous lesson took malware; this one takes the password and cryptographic attacks in CompTIA's scope note for it. As with the rest of 2.4, the verb is analysing indicators — what each attack looks like from the defender's side, and what closes it.

Why this matters

Stolen and guessed credentials are the most common way into an organisation that does not involve a software vulnerability at all. The exam knows this, and it asks about these attacks repeatedly — in Domain 2 as indicators, in Domain 4 as authentication controls, and in Domain 4 again as things you spot in a log.

The reason to learn them together is that each one is closed by a different control, and the exam's favourite question shape is to describe an attack and offer four plausible-sounding controls, only one of which actually addresses it.

The lesson

Spraying versus brute force, and which one your lockout policy stops

Both are guessing. The difference is which axis they iterate on, and it decides everything about detection.

Brute force takes one account and tries many passwords. Traditional lockout policy — five failures and the account locks — stops it dead, because the attacker exhausts the allowance on the first account and gets nowhere. In a log it looks like a burst of failures against a single username.

Password spraying takes one password — a common or seasonal one — and tries it against many accounts. Each account sees one or two failures, well under the lockout threshold, so lockout never triggers. In a log it looks like a low rate of single failures spread across hundreds of usernames, often from one source address, often at a steady interval.

That is the whole point of the technique: it is designed around the control most organisations have. Detecting it requires looking at the aggregate — failures per source, or per time window across all accounts — not per account. This is one of the clearest cases in the exam where the right answer is a monitoring change rather than a policy change.

A dictionary attack is brute force using a wordlist of likely passwords rather than every combination, and credential stuffing is reusing username/password pairs stolen from some other breached service. Stuffing shows up as a high proportion of successful logins from unusual locations, because the credentials are real — which is why it is not caught by anything counting failures.

Why a stolen hash is a credential, and what salting changes

If an attacker obtains the stored hashes, they have two routes and you should be able to tell them apart.

The first is offline cracking. Because the hashes are now on the attacker's hardware, there is no lockout, no rate limit and no alerting — they can try billions of candidates per second. This is why "we have a strong lockout policy" is no defence once the hash database is gone.

The second, and the one that surprises people, is that for some protocols the hash is itself sufficient. In a pass-the-hash attack the attacker authenticates using the hash directly, without ever learning the password. The credential was never the password; it was whatever the protocol accepts.

Salting — a unique random value per password, mixed in before hashing — changes exactly one thing: it defeats precomputation. Rainbow tables and lookup databases stop working, because a table would have to be built per salt. It does not slow down guessing an individual password, and it does not help at all if the password is weak.

What slows guessing is key stretching: bcrypt, scrypt, Argon2, PBKDF2 with a high iteration count. These are deliberately expensive, so an attacker's billions-per-second becomes thousands. Salting plus stretching is the answer; either alone is a partial one, and the exam does distinguish them.

The control that survives all of this is multifactor authentication, because a cracked password on its own no longer authenticates anyone.

Downgrade attacks, and the protocol version you forgot to disable

A downgrade attack forces two parties to negotiate a weaker protocol or cipher than both support, so the attacker can break what they then use.

The mechanism is simple: most secure protocols negotiate. The client offers what it can do, the server picks. An on-path attacker interferes with that negotiation — stripping the strong options, or failing the handshake so the client retries with older settings — until both ends settle on something breakable. Historic examples targeted SSL and early TLS; the same shape applies to email transport encryption and to wireless.

The indicator from the defender's side is connections succeeding at a protocol version or cipher suite you thought was unused, which is only visible if you are logging negotiated versions at all.

The control is not clever: remove the weak options entirely. A protocol version that is disabled cannot be negotiated down to. Set a minimum TLS version, remove deprecated cipher suites, and disable legacy authentication protocols rather than merely preferring the modern ones. The reason organisations do not is legacy applications — which returns you to the compensating control conversation from Domain 1.

Two relatives: SSL stripping, where an attacker keeps the victim on plain HTTP so there is nothing to downgrade, which HSTS addresses; and on-path attacks generally, which you meet in the next lesson.

Collision and birthday attacks stated at the level the exam asks

A collision is two different inputs producing the same hash. It matters because hashes are used to prove that data has not changed: if an attacker can produce a different document with the same digest, a signature over that digest now vouches for both.

A birthday attack is the technique that makes collisions cheaper than intuition suggests. The name comes from the birthday paradox — in a room of 23 people there is a better-than-even chance two share a birthday, even though the chance of anyone matching you is small. Applied to hashing: finding any pair that collides takes roughly the square root of the effort of finding a collision with one specific value. So a 128-bit hash gives about 64 bits of collision resistance, not 128.

What the exam wants from this:

• collisions break integrity guarantees, and therefore signatures;
• MD5 and SHA-1 have practical collision attacks and must not be used for signatures or integrity verification — they are the wrong answer whenever they appear as an option;
• the control is simply to use a hash with adequate output length from the SHA-2 or SHA-3 families;
• a birthday attack is about finding any collision, which is why hash outputs need to be twice as long as the security level you want.

You will not be asked to compute anything.

The control that answers each: length, MFA, lockout, modern algorithms

The mapping, which is what the scenario questions test:

Two general points worth carrying. Length beats complexity — current guidance favours long passphrases and banned-password lists over forced symbol substitution and frequent expiry, which push users toward predictable patterns. And MFA appears in four of those rows, which is why it is the single highest- value control in this area and why Domain 4 gives it a lesson of its own.

What to take into the exam

• Lockout stops brute force and does nothing against spraying; spraying is detected in aggregate, not per account.
• Salting defeats precomputed tables. Key stretching defeats fast guessing. You need both, and neither saves a weak password.
• Credential stuffing produces successful logins, so failure-counting misses it entirely.
• Downgrade attacks are closed by removing the weak option, not by preferring the strong one.
• MD5 and SHA-1 are the wrong answer for signatures and integrity.