Case Studies ~7 min read

Password Hall of Shame: Real Weak Passwords in Real Systems

This isn't about mocking ordinary people who reused a password. It's about systems, organizations, and administrators who had the resources and responsibility to do better — and didn't. Four cases where catastrophically weak credentials got past everyone who should have caught them, and what each one teaches.

Case 1 The McDonald's Hiring Chatbot and the World's Most Meme Password
The credential
123456
What happened

Researchers discovered that the backend of a McDonald's AI-powered hiring chatbot was accessible using an admin login with the password 123456. The backend exposed access to a large amount of job applicant data, including personal information submitted by people who thought they were applying for a job.

Why it's instructive

123456 has topped every "most common passwords" list for over a decade. It's the first thing any attacker tries. And yet it was protecting a production system handling real applicant data for one of the largest employers in the world. The most famous weak password in the world still works — because default credentials get deployed and never changed.

What it teaches: Default credentials must be changed before any system goes live. No exceptions. Enforce minimum password complexity at the system level, not via policy alone. And wherever possible, add MFA so that a guessed password alone isn't sufficient.
Case 2 The Water Treatment Plant and the Shared Password
The credential
shared among staff
What happened

In the 2021 Oldsmar incident, someone remotely accessed a Florida water treatment plant's control systems and briefly changed chemical levels to dangerous concentrations. Investigations revealed the facility was using remote access software with a password shared among multiple employees, on a network with limited segmentation. An operator caught the change in time and reversed it.

Why it's instructive

A shared password means no accountability and no revocation. When a shared credential is compromised — whether by a former employee, a breach on another system, or direct attack — you can't rotate it quietly. Everyone using it has to be notified, and any of them could have been the leak. In critical infrastructure, "shared password" is a class of failure, not just a weak password.

What it teaches: Every person who needs access gets their own account. Shared logins make audit trails meaningless and revocation painful. MFA on remote access to any sensitive system is non-negotiable. Segmented network access limits the blast radius when any account is compromised.
Case 3 Colorado's Voting System Passwords and the Hidden Spreadsheet Tab
The credential
in a hidden tab
What happened

Colorado's Secretary of State office accidentally published a spreadsheet to a public website that contained hidden tabs with still-active passwords for some of the state's voting systems. The spreadsheet was intended for public release, but the hidden tabs were not scrubbed before publication. The passwords were discovered by a member of the public who knew to look for hidden sheets.

Why it's instructive

"Hidden tab" is not access control. Spreadsheets are deceptively porous — hidden columns, hidden sheets, and embedded metadata all survive exports that look clean on the surface. This is particularly acute because spreadsheets are often used as informal credential stores in organizations that haven't moved to proper secrets management. The file looked fine. It wasn't.

What it teaches: Treat spreadsheets and documents like code: review them before publishing. Strip hidden sheets, hidden columns, and embedded metadata. Never store active credentials in a document that could be shared. If a document was a credential store at any point in its history, assume those credentials are compromised before any external release.
Case 4 The Password That Passes Every Complexity Check and Cracks in Seconds
The credential
P@ssw0rd1!
What happened

Breach data consistently shows that when organizations enforce complexity requirements (uppercase, lowercase, number, symbol), users respond by applying predictable transformations to simple words: Password becomes P@ssw0rd, then P@ssw0rd1, then P@ssw0rd1!. The password passes every filter. It cracks in seconds because every cracking tool includes these exact transformations in its ruleset.

This isn't a single incident — it's a pattern observed across hundreds of millions of cracked credentials. It's what happens when complexity rules meet human psychology at scale.

Why it's instructive

Complexity requirements were designed to force randomness. Instead, they forced legibility — short, memorable words with just enough symbols appended to satisfy a filter. The password looks strong. The strength meter might even turn green. But attackers precompute these transformations. A word with substitutions is barely harder to crack than the original word.

What it teaches: NIST now explicitly recommends against mandatory complexity rules for exactly this reason. Length beats complexity every time. Block known-weak passwords at the system level using a blocklist. Encourage passphrases and random generation. A 20-character random password that looks "simple" is infinitely stronger than P@ssw0rd1!.

The pattern across all four cases

These incidents look different on the surface but share a structure. In every case, someone had a responsibility to enforce better credential hygiene and didn't. The tools existed. The guidance existed. The failure was organizational: unchecked defaults, shared accounts, unsanitized documents, and rules designed to satisfy a checkbox rather than produce real security.

The embarrassing thing isn't that the passwords were weak. It's that no layer of defense caught them before they mattered.

The fix is the same every time: unique accounts, strong random passwords or passphrases, MFA on anything sensitive, and no shared credentials. It's not complicated. It just has to actually happen.

Back to pwasecurity.org Generate a strong password