DEV Community

Cover image for # Online vs. Offline Password Attacks: A Field Guide
auto_majicly
auto_majicly

Posted on

# Online vs. Offline Password Attacks: A Field Guide

Password attacks are one of the first things people learn in offensive security, and one of the most commonly muddled. The confusion usually comes down to a single distinction that determines which tool you reach for, how fast you move, and how much noise you make: is the attack online or offline? Getting this wrong wastes hours and, in a real engagement, can lock accounts and blow your cover. Here is the field guide I wish I had early on.

Online attacks: guessing against a live service

An online attack throws credentials at a running service — SSH, RDP, a web login, a database — and waits to see what sticks. Tools like Hydra, Ncrack, and Medusa live here. You use them when you do not yet have valid credentials and you are trying to find some against a service that is actually listening.

The defining traits of online attacks are their constraints. They are slow, because every guess is a full network round-trip. They are loud, generating authentication logs with every attempt. And they are fragile, because account lockout policies, rate limiting, and fail2ban-style tooling will stop you — or worse, lock out the very accounts you are testing. In practice this means being surgical: a short, high-probability wordlist against a high-value service beats blindly hammering everything. Telnet and other slow protocols are rarely worth the time.

Offline attacks: cracking captured hashes

An offline attack works against password hashes you have already obtained — from a dumped database, a captured /etc/shadow, a network capture, or a memory dump. Tools like John the Ripper and Hashcat own this space. Here there is no live service in the loop at all; you are running computation against data you already hold.

That changes everything. Offline attacks are fast, bounded only by your hardware — a GPU can try billions of candidates per second against a weak hashing scheme. They are silent, because the target sees nothing; there is no service to log your attempts. And they are unlimited, with no lockout to stop you. The catch is that you had to obtain the hashes first, and the difficulty scales enormously with the hashing algorithm: a fast, unsalted hash falls quickly, while a modern, deliberately slow scheme can resist cracking indefinitely.

The decision that trips people up

The mistake I see most often is reaching for an online brute-forcer when the situation calls for offline cracking, or vice versa. Three cases make it clear:

  • You have no credentials and a live service is exposed. This is online territory — Hydra, Ncrack, Medusa — used carefully and sparingly.
  • You found password hashes. These go straight to offline cracking with John or Hashcat. Do not point an online tool at anything.
  • You found actual plaintext credentials. You do not brute-force at all. You reuse them — credential stuffing and password spraying across other systems — because people recycle passwords everywhere, and one valid pair is often the key to many doors.

Knowing which of these three you are in tells you exactly which tool to open, before you waste a cycle.

The defender's mirror

Every property that makes these attacks work is something a defender can take away.

Against online attacks: enforce rate limiting and sensible lockout thresholds, monitor authentication logs for spikes, prefer key-based authentication over passwords where possible, and put multi-factor authentication in front of anything that matters. These measures turn a slow attack into an impractical one.

Against offline attacks: assume your hash store will eventually be exposed and design for that day. Use a modern, deliberately slow, salted hashing algorithm — the kind built to resist GPU cracking. Salting defeats precomputed tables; slowness defeats brute force. And enforce password length, because length is the single factor that scales cost fastest for the attacker.

The through-line is simple. Offensive and defensive password work are two views of the same mechanics. Understand which attack applies to which situation, and you will not only choose the right tool as a tester — you will know exactly where to spend a defender's budget.

Top comments (1)

Collapse
 
codemaster_121482 profile image
Seif Ahmed

Great explination! 👌💯👍