Password strength and rate limiting

A password login is as strong as its weakest password times the number of tries allowed. Long random passwords, limiting tries (fail2ban reads the log and blocks an address), a second factor and, for SSH, keys only. A burst of failures from one address in the log is the sign to act on.

How weak passwords fall, step by step

In the weak password lab the fileServer (10.0.1.10) takes SSH password logins, and its admin account uses a common password. The attacker (10.0.1.11) sits on the same LAN.

1. The service is reachable. SSH on TCP 22 answers anyone who can reach it, and asks for a password.
2. Guesses are cheap. Each try is one SSH connection. People pick from a small set of passwords, so a short list of the most common ones (a dictionary) covers a large share of real accounts.
3. Nothing slows the guesser. Each refused try costs a second or so, and the server never blocks the address. A weak password is found within a few tries.
4. The login is ordinary. Once a guess works, the attacker is a normal user, with that account's rights.

That is online guessing: every try goes through the live service, so the service can count and limit tries. Offline cracking is worse: an attacker who steals the stored hashes (from /etc/shadow, a database dump) tests guesses on their own hardware, with no limit at all. Only the hash's cost and the password's length slow it down, which is why systems store salted, deliberately slow hashes (hashing and salting).

NIST SP 800-63B sets the modern rules. Require at least 8 characters (15 where a password is the only factor), allow at least 64, and accept spaces and any characters. Check new passwords against a blocklist of breached and common ones. Do not force composition rules (one digit, one symbol) or periodic changes; change a password when there is evidence it leaked. And rate-limit failed attempts at the service.

What it looks like on a Linux machine

A single wrong password is refused. sshpass exits 5 for a wrong password, and ssh prints:

$ sshpass -p hunter2 ssh admin@10.0.1.10 true
Permission denied, please try again.

The defender's view is the SSH log. sshd writes one line per failed try and one for the success, each with the source address and port:

$ grep -c 'Failed password' /var/log/netlab-sshd.log
6
$ grep -E 'Failed password|Accepted password' /var/log/netlab-sshd.log | tail -6
Failed password for admin from 10.0.1.11 port 44882 ssh2
Failed password for admin from 10.0.1.11 port 44890 ssh2
Failed password for admin from 10.0.1.11 port 44902 ssh2
Failed password for admin from 10.0.1.11 port 44906 ssh2
Failed password for admin from 10.0.1.11 port 44914 ssh2
Accepted password for admin from 10.0.1.11 port 44920 ssh2

A burst of failures from one address, then an Accepted, is the shape of a guessing attack. On systemd machines the same lines are in journalctl -u ssh, or /var/log/auth.log.

The fixes, on the server. Give the accounts long random passwords:

printf 'admin:<long-random>\nroot:<long-random>\n' | chpasswd

Or turn passwords off and require keys, in /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Then limit tries: MaxAuthTries 3 per connection, and fail2ban, which reads the same log and adds a firewall rule for an address after, say, 5 failures in 10 minutes.

What goes wrong, and how you see it

A guessable password on a reachable service. The log shows many Failed password lines from one address, then Accepted password from the same one. Change the password at once, check what the account did, and move to keys or a second factor (multi-factor authentication, shown in the two-factor SSH lab).

Lockout used as a weapon. Locking an account after a few failures lets anyone lock out a real user by guessing on purpose. Rate-limit by source address and slow down per account instead of a hard, permanent lock.

Slow, spread-out guessing. A botnet tries one password per account per hour from many addresses, under every per-address limit. You see Failed password for invalid user lines from many sources for many names. Keys only, or a bastion host that is the only machine exposed, removes the target.

Fast hashes after a leak. Unsalted MD5 or SHA-1 hashes fall to offline cracking at billions of guesses a second. Store yescrypt, bcrypt or Argon2 (/etc/shadow entries starting $y$ or $2b$), never fast hashes.

Questions people ask

How long should a password be? Length beats complexity. NIST asks for at least 8 characters, 15 when it is the only factor; a passphrase of four or more random words is long and easy to type. What matters most is that it is not on a list of common or breached passwords.

Should passwords expire every 90 days? No. NIST SP 800-63B says not to force periodic changes, because people then pick predictable variants. Change a password when there is a sign it leaked.

Is a strong password enough for SSH? It stops guessing, but not a stolen or reused password. Key-only login or a second factor closes that too, and a short log check shows whether anyone is trying.

See it on real machines