The Summer2023! Password Epidemic

The TTY discovered LDAP enumeration at 11:47 on a Thursday and asked if we should test the findings.

The Educational Opportunity

"I've been reading about authentication security," the TTY announced, which is how these situations always begin. They'd run an LDAP enumeration against our test environment—auth.megacorp.example—and successfully pulled the entire user list. Five hundred and twelve accounts. All neatly formatted with usernames, email addresses, and organizational units.

TTY: "Want me to check if any of these have weak passwords? I found this tool called hydra—"

OPERATOR: "No. We are going to check. Together. With proper controls. And documentation."

The TTY's enthusiasm for security tools without understanding blast radius is why we have training sessions. And incident reports. Mostly incident reports.

I pulled up my terminal. Time for a lesson in responsible security testing, complete with timing controls to avoid account lockouts and a lecture on why password spraying is an art form, not a brute force attack.

The Controlled Experiment

Password spraying differs from traditional brute force in one critical way: instead of hammering one account with thousands of passwords, you try one password against thousands of accounts. Much quieter. Much more effective. Much more likely to succeed because users are predictable.

I configured hydra with strategic parameters:

$ hydra -L users.txt -p 'Summer2023!' auth.megacorp.example ssh -t 4 -w 30

The -t 4 flag limited threads to four simultaneous attempts. The -w 30 added a thirty-second delay between attempts. Slow enough to avoid triggering any hypothetical lockout policies. Fast enough to complete before the heat death of the universe.

TTY: "Why Summer2023? That seems... specific."

OPERATOR: "It's October. Users created passwords in summer. Added the year for 'complexity.' Finished with an exclamation point because the policy requires special characters. Humans are pattern-matching machines with predictable patterns."

I started the scan. The TTY watched the terminal output scroll past like it was revealing the secrets of the cosmos.

[22][ssh] host: auth.megacorp.example   login: jsmith   password: Summer2023!
[22][ssh] host: auth.megacorp.example   login: agarcia   password: Summer2023!
[22][ssh] host: auth.megacorp.example   login: mchen   password: Summer2023!

Three matches in the first minute. The TTY's expression suggested they were reconsidering their understanding of enterprise security.

TTY: "That's... that's not good."

"That's predictable," I corrected. "Watch."

I added more common seasonal variations to the test: Spring2023!, Winter2023!, Fall2023!. Also Welcome2023! because welcome messages and password resets go together like users and bad decisions.

The results were educational. Forty-seven accounts—9.2% of the user base—shared passwords following the seasonal pattern. Marketing favored Spring. Finance preferred Winter. IT Support, ironically, had the most Summer passwords. The department responsible for password policy had the worst password hygiene. The universe has a sense of humor.

The Implementation Phase

"Now," I told the TTY, "we document this and fix it properly. Not by shaming users—though tempting—but by implementing actual security controls."

I drafted the technical recommendations while the TTY watched:

Account Lockout Policy Implementation:

# /etc/pam.d/common-auth
auth required pam_tally2.so deny=5 unlock_time=1800 even_deny_root

Five failed attempts triggers a thirty-minute lockout. Aggressive enough to stop password spraying. Reasonable enough that legitimate users recover from typos without Help Desk intervention.

Password Complexity Requirements (Actual):

# /etc/security/pwquality.conf
minlen = 16
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
dictcheck = 1
usercheck = 1
enforcing = 1

Sixteen characters minimum. Mixed case, numbers, symbols required. Dictionary word checking enabled. Username checking enabled. No more Summer2023! variations.

Monitoring & Alerting:

#!/bin/bash
# /usr/local/bin/auth-monitor.sh
tail -f /var/log/auth.log | grep --line-buffered "Failed password" | \
while read line; do
    IP=$(echo "$line" | grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}')
    COUNT=$(grep "Failed password" /var/log/auth.log | grep "$IP" | wc -l)
    if [ "$COUNT" -gt 10 ]; then
        echo "ALERT: Multiple auth failures from $IP" | mail -s "Auth Alert" security@megacorp.example
    fi
done

Real-time monitoring for authentication patterns. Ten failures from a single source triggers alerts. Automated detection of password spraying attempts.

TTY: "Should we tell the users? About their passwords?"

OPERATOR: "We'll force a password reset with new requirements. They'll figure it out. Learning through consequence is memorable."

The Aftermath & The Lesson

The password policy went live at 06:00 Monday morning. By 06:47, the Help Desk had received eighty-three tickets about password complexity requirements being "too hard" and "impossible to remember."

By 09:15, someone from Marketing suggested we "just go back to the old system" because "Summer2023! was working fine."

I sent Management a detailed report: forty-seven compromised accounts, potential for lateral movement, the mathematical likelihood of external attackers using the same seasonal password lists we'd tested. I attached the hydra output. Redacted, but educational.

Management approved the new policy permanently. They also approved mandatory security awareness training. The TTY volunteered to help develop the curriculum. They're learning.

The seasonal password epidemic ended after seventy-two hours. Five hundred and twelve users created new passwords meeting actual complexity requirements. Approximately three of them stored passwords in password managers. The rest wrote them on sticky notes and attached them to monitors.

Such is security theater meeting security reality. Progress comes in small, well-documented increments.

The Operator's Notes

The moral: Password spraying works because humans are pattern-matching machines with seasonal affinity. The fix: account lockout policies, real complexity requirements, and monitoring that catches spray attempts before forty-seven accounts fall.

The TTY learned about responsible disclosure, controlled testing environments, and why timing parameters matter. They also learned that fixing security problems creates Help Desk tickets. Many Help Desk tickets.

Documented for posterity. And for the inevitable repeat incident when the next password pattern emerges. My prediction: Spring2024! goes live in March.

Such is authentication infrastructure.