Stop Calling Users the Weakest Link

It is late at night and your phone buzzes: “Are you trying to sign in? Approve / Deny.” You tap Deny. It buzzes again. And again, for an hour. Then a message arrives from someone who says they are from your company’s IT team: approve one, and the alerts will stop.

Would you tap Approve? A lot of tired people would. And when they do, the headline usually calls it “human error.”

The issue: blaming the person who clicked

In cybersecurity, people are often called “the weakest link.” When an attack succeeds because someone clicked a link, shared a code or approved a login, the investigation tends to stop at that person. The fix that follows is usually more rules and more training for users.

Is that blame fair, and does it make us safer? I argue it often does neither, because many “user mistakes” are predictable results of system design.

Why it matters: the Uber breach of 2022

The opening scene is not imaginary. In September 2022, Uber disclosed that an attacker had likely bought a contractor’s work password on the dark web, after malware infected the contractor’s personal device [3]. The account was also protected by multi-factor authentication (MFA): each login sent an “approve” notification to the contractor’s phone.

The attacker kept trying to log in, flooding the phone with notifications. Then, posing as Uber IT on WhatsApp, he told the contractor that accepting one request was the only way to stop them [3][4]. The contractor accepted, and the attacker reached Uber’s internal systems. Security teams now call this technique MFA fatigue, or push bombing.

It is easy to say the contractor should have known better. But this pattern is old. In a 1999 study, researchers Anne Adams and Angela Sasse found that people who broke password rules were often reacting to how the security mechanisms were built, for example creating linked passwords like tom1, tom2, tom3 to cope with too many rules [1]. Their conclusion, more than 25 years ago, was in the title of their paper: Users Are Not the Enemy.

Anyone who has been asked to “just forward the OTP code” has seen the same trick aimed at ordinary people.

The deeper problem: a design choice, not just a bad click

Look at what the system asked of the contractor. A single “Approve” button, with no context, repeated without limit, at whatever hour the attacker chose. That design turns security into a test of willpower that the attacker can retake as many times as he likes.

Better designs already existed. In October 2022, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) urged organizations to adopt phishing-resistant MFA, such as security keys. Where that is not yet possible, CISA recommended number matching: the user must type a number shown on the login screen into the app [2]. A tired person in bed cannot type a number they never saw.

So is this a technology problem or a human problem? In my view, it is a human problem created by a technology choice. People will always get tired; design decides whether that becomes a breach.

Get Rei’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The law and professional ethics point the same way. Indonesia’s Personal Data Protection Law (UU No. 27 Tahun 2022, Article 35) places the duty to protect and ensure the security of personal data on the data controller, meaning the organization, not the individual employee [5]. The ACM Code of Ethics asks computing professionals to design systems that are “robustly and usably secure” (principle 2.9) [6]. Security that only works for perfectly alert users is not usably secure.

My judgment: change the question from “who clicked?” to “why could one click do this?”

Users are not blameless. But blame should follow power, and the people who choose and configure systems have far more power than the person holding the phone. Three changes follow:

1. Design out single-tap failures (responsibility: security and IT teams). No important account should fall to one careless moment. That means phishing-resistant MFA where possible, number matching where not, and limits on how many prompts can be sent [2].
2. 2. Treat repeated mistakes as bug reports (responsibility: organizations). If many employees fall for the same trick, the system is producing that error. Reporting should also be blame-free, so strange prompts get reported, not hidden.
3. 3. Give users a few clear duties, not dozens of vague ones (responsibility: users). “Never approve a login you did not start, and report it” is a rule people can actually follow. Adams and Sasse showed that rules which clash with real work get bypassed [1].
4. This is reasonable because it gives each fix to the party best able to make it, which is where Indonesian law already places the duty [5]. Training should support good design, not replace it.
5. A question for you
6. If a security system only works when a tired person makes a perfect decision at midnight, is the person failing the system, or is the system failing the person?
7. References
8. 1. Adams, A., & Sasse, M. A. (1999). Users are not the enemy. Communications of the ACM, 42(12), 40 – 46. doi.org/10.1145/322796.322806 (open copy: UCL Discovery)
9. 2. CISA. (2022, October). Implementing Number Matching in MFA Applications (fact sheet). cisa.gov
10. 3. InfoQ. (2022, September). Multi-Factor Authentication Fatigue Key Factor in Uber Breach. infoq.com
11. 4. KPMG India. (2022, September 27). Cyber Threat Notification: Lessons to learn from the Uber security breach. kpmg.com
12. 5. Republic of Indonesia. (2022). Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi, Article 35. jdih.kemenkeu.go.id
13. 6. ACM. (2018). ACM Code of Ethics and Professional Conduct, principle 2.9. acm.org