The six dumbest ideas in computer security (2005)

Meta: Summaries and recurring debates

• Some dislike short TL;DR comments, arguing they flatten nuance and encourage shallow title-only replies; others find them very useful for deciding whether to read or engage.
• People expect AI-powered inline summaries to become common anyway.
• This article resurfaces every few years; some see it as dated and “grumpy,” others as still largely on point.

“Hacking is cool” and offensive knowledge

• Strong pushback on the article’s claim that learning to hack is a “dumb idea” for defenders.
• Many argue you can’t design good mitigations without understanding real exploits and attacker thinking.
• Others distinguish between deep exploit understanding vs. shallow “script kiddie” tool use.
• Some stress that glamorizing criminal hacking is different from valuing technical subversion or pentesting.

Educating users and social engineering

• Article’s skepticism about user education is contested.
• Some say training has limited effect at scale; it’s better to prevent unsafe actions via design.
• Others argue ongoing user education is essential given that high‑impact attacks are often social engineering.
• Consensus: education can’t be the only defense, but it isn’t useless.

Default permit, enumerate badness, and secure-by-design

• Broad agreement that “default permit” and “enumerating badness” are flawed; default deny and “enumerate goodness” are ideal.
• SELinux/AppArmor are cited as existing “enumerate goodness” tools; some say they now work well out of the box, others still find them painful and error‑prone.
• Debate over “secure by design”: critics call it unrealistic given evolving systems; supporters say “find and patch” alone demonstrably fails and that better engineering is possible but under‑incentivized.

Penetrate and patch, disclosure, and pentesting

• Some see “penetrate and patch” as necessary and politically useful: proof of value for security teams.
• Others describe it as shallow, demoralizing work that rarely fixes root causes and encourages cargo‑cult defenses.
• Historical context: earlier skepticism of vulnerability research; commenters note that offensive research and disclosure are now central to security conferences and practice.

Usability vs. security and corporate IT friction

• Recurrent theme: tight security (default deny, locked‑down endpoints) often makes normal work painful, leading to workarounds that may be less secure.
• Some defend strict controls as necessary risk management; others criticize “security theater” cultures focused on checklists and blocking, not on enabling safe ways to get work done.
• Several stress that good security must be designed to be as invisible, low‑friction, and supportive of real workflows as possible.

Passwords, password policies, and passkeys

• Many call traditional password rules (complexity, rotation, prior‑password bans) “dumb” or outdated.
• Points raised: such rules encourage predictable patterns; people have O(1) memorable passwords but need O(n); writing passwords down or using managers is often safer.
• Modern guidance (NIST/NCSC) against forced rotation and strict composition is cited, but commenters say most organizations still use old checklists.
• Debate on password managers: critics worry about a single point of failure; defenders note 2FA, encryption, auto‑lock, and that reuse without managers is worse.
• Passkeys get cautious optimism from some and skepticism from others who expect user confusion.

Trusting the client and capability/security models

• “Trusting the client” is proposed as a better “dumb idea” than “hacking is cool.”
• Examples: mobile OS attestation, browser DRM, and banks relying on device integrity checks; seen by some as misguided security, by others as compliance‑driven or control‑motivated.
• A minority advocates capability‑based security and finer‑grained permission models, but notes they remain niche and UI‑hard.

Overall tone

• Mixture of respect for the article’s core ideas (default deny, enumerating goodness, skepticism of checkbox security) and criticism of its dated takes, especially around hacking culture, user education, and “just design it securely.”
• Strong emphasis across comments on context, tradeoffs, and the need to balance security, usability, and business realities.