Scrolls
3 min read
On this page

Security vs Usability

The Fundamental Trade-Off

Perfect security is perfectly unusable. A system with no users, no network, and no inputs cannot be attacked — it also cannot do anything. Security engineering is about finding the right balance between protection and usability for your specific context.

This is not a binary choice. It is a spectrum, and your position on that spectrum should be determined by risk, not by fear or convenience.

Maximum security, minimum usability:
- 64-character random passwords rotated daily
- MFA required for every single action
- All data encrypted with keys that require 3 people to unlock
- No remote access, ever

Maximum usability, minimum security:
- No passwords
- No access controls
- All data public
- Every user is an admin

Neither extreme is acceptable. The art is finding where your application should sit between them.

Security Proportional to Risk

Not every application needs the same level of security. A personal todo list app does not need the same controls as an online banking platform. Applying banking-grade security to a todo app wastes engineering effort and frustrates users. Applying todo-app security to banking loses people's money.

Risk Assessment Framework

Risk = Likelihood x Impact

Likelihood factors:
- How attractive is the target? (financial data > blog posts)
- How exposed is the system? (public internet > internal tool)
- How many attackers are motivated? (banks > hobby projects)
- How easy is the vulnerability to exploit?

Impact factors:
- What data could be exposed? (PII, financial, health, public)
- What is the regulatory consequence? (GDPR fines, HIPAA violations)
- What is the reputational damage?
- What is the financial loss?
- Could people be physically harmed?

Calibrating Security to Context

Low risk — Personal blog, public documentation site:
- HTTPS (always, this is baseline)
- Strong password for admin account
- Keep software updated
- Regular backups

Medium risk — SaaS application, internal business tool:
- Everything above, plus:
- MFA for admin accounts
- Input validation and parameterized queries
- Rate limiting
- Dependency scanning
- Access logging

High risk — Banking, healthcare, government systems:
- Everything above, plus:
- MFA for all users
- Encryption at rest and in transit
- Hardware security modules for key management
- Penetration testing
- SOC monitoring
- Incident response team
- Compliance certification (PCI DSS, HIPAA, SOC 2)
- Regular third-party audits

When Security Controls Hurt Users

Security controls that frustrate users do not make you more secure. They make users find workarounds, which are almost always less secure than no control at all.

Password Complexity Requirements

The old way (NIST pre-2017):
- Minimum 8 characters
- Must include uppercase, lowercase, number, special character
- Must change every 90 days
- Cannot reuse last 12 passwords

What users actually do:
- Password1! (meets all requirements)
- Password2! (next rotation)
- Write passwords on sticky notes
- Use the same base password everywhere with minor variations

The current way (NIST SP 800-63B, 2017+):
- Minimum 8 characters, recommend 15+
- No complexity requirements
- No mandatory rotation (unless compromised)
- Check against known breached password lists
- Allow paste into password fields (enables password managers)

Result: Users pick longer, more memorable passwords.
Security improves because users stop working around the system.

CAPTCHAs

CAPTCHAs block bots but also block legitimate users:
- Visually impaired users cannot solve image CAPTCHAs
- Audio CAPTCHAs are often unintelligible
- Users abandon forms with difficult CAPTCHAs (up to 30% drop-off)
- Advanced bots solve most CAPTCHAs anyway (ML-based solving services)
- reCAPTCHA v3 scores behavior invisibly — better UX, similar protection

Alternatives to CAPTCHAs:
- Rate limiting by IP and account
- Honeypot fields (hidden form fields that bots fill in)
- Time-based analysis (bots submit forms instantly)
- Device fingerprinting
- Progressive challenges (only show CAPTCHA after suspicious behavior)

Multi-Factor Authentication Fatigue

Real example: 2022 Uber breach
- Attacker obtained an employee's password
- Spammed the employee with MFA push notifications
- Employee eventually approved one to stop the notifications
- Attacker gained full access to Uber's internal systems

The problem: MFA push notifications without context
The fix: Number-matching MFA (user must type a number shown on screen)
         or phishing-resistant MFA (WebAuthn/passkeys)

Lesson: Security controls that annoy users create fatigue,
and fatigued users make bad security decisions.

The Risk-Based Approach

Instead of applying security uniformly, assess each component independently.

Data Classification

Classification determines what level of protection data needs:

Public:
  Marketing content, open-source code, public API docs
  Protection: Integrity (prevent defacement)

Internal:
  Employee directory, internal wikis, Slack messages
  Protection: Authentication, basic access controls

Confidential:
  Customer PII, financial reports, source code
  Protection: Encryption, access logging, need-to-know basis

Restricted:
  Payment card data, health records, authentication credentials
  Protection: Encryption at rest and transit, strict access control,
              audit logging, regulatory compliance, minimal retention

Applying Security Budget

You have finite engineering resources. Spend them where the risk is highest.

Example: E-commerce platform security priorities

High priority (do first):
- Payment processing security (PCI DSS compliance)
- Authentication and session management
- SQL injection prevention on all endpoints
- Customer PII encryption

Medium priority (do next):
- Rate limiting on all public endpoints
- CSRF protection on state-changing operations
- Content Security Policy headers
- Dependency vulnerability scanning

Lower priority (do when able):
- Subresource integrity on third-party scripts
- Advanced bot detection
- Certificate pinning in mobile app
- Full request/response logging

Real-World Balancing Acts

Two-Factor Authentication Decisions

When to require MFA:
- Admin access to any system (always)
- Access to customer data or PII (always)
- Financial transactions above a threshold
- Changing account security settings
- Accessing from a new device or location

When MFA is optional or unnecessary:
- Reading public content
- Browsing a product catalog
- Low-value accounts with no sensitive data
- Internal tools with network-level access control already in place

Real example: Google's approach
- Required MFA for all employee accounts (2021)
- Result: Zero successful phishing attacks on employees
- Required MFA for high-risk user accounts (2024)
- Made security practically invisible with passkeys

Session Timeout Decisions

Banking application:
- Timeout after 5-15 minutes of inactivity
- Users expect this and accept the friction
- The risk of an exposed session justifies the interruption

Social media application:
- Sessions can last weeks or months
- Re-authenticate for sensitive actions (password change, new device)
- Long sessions are expected; short timeouts would drive users away

Internal development tool:
- Session lasts 8-12 hours (work day)
- Re-authenticate daily
- Balance between security and developer productivity

Error Message Decisions

Secure but unhelpful:
  "An error occurred."
  (User has no idea what went wrong. Support tickets increase.)

Helpful but insecure:
  "User admin@company.com not found in database users table.
   SQL query: SELECT * FROM users WHERE email = 'admin@company.com'"
  (Reveals database schema, confirms user enumeration.)

Balanced:
  "Invalid email or password."
  (Does not reveal whether the email exists. Clear enough for users.)

For login specifically:
  Bad:  "Password incorrect for user admin@company.com"
  Bad:  "No account found with that email"
  Good: "Invalid email or password"
  
  The first two allow user enumeration. The third does not.
  Some products intentionally allow enumeration for UX reasons
  (e.g., "Did you mean to log in with Google?") — this is a
  deliberate risk acceptance, not an oversight.

Security Theater

Security theater is security that looks impressive but provides little or no actual protection. It wastes resources and creates a false sense of safety.

Examples of security theater:
- Forcing password changes every 30 days (leads to weaker passwords)
- Airport-style security questions ("mother's maiden name" is public)
- IP allowlisting when attackers can use VPNs or compromised machines
- Checkbox compliance without genuine security practices
- Running vulnerability scans but never fixing the findings
- Requiring complex passwords but allowing "Forgot Password" via email

Real example: Equifax (2017)
- Had passed multiple security audits and compliance checks
- Failed to patch a known Apache Struts vulnerability for months
- 147 million records breached
- Compliance did not equal security

Inclusive Security

Security controls must be usable by all users, including those with disabilities.

Accessibility considerations:
- CAPTCHAs must have audio alternatives (and audio must be clear)
- MFA should support multiple methods (not just SMS or push)
- Color-coded security indicators need non-color alternatives
- Time-limited operations must allow extensions
- Screen readers must work with login forms and MFA prompts

WCAG 2.1 and security are not in conflict — they require
thoughtful design that serves both goals.

Common Pitfalls

  • Applying maximum security everywhere: Over-securing low-risk systems wastes engineering time that could protect high-risk systems. A personal wiki behind a VPN does not need MFA, encryption at rest, and a WAF.

  • Ignoring user behavior: If your security control is too annoying, users will bypass it. Shared passwords, propped-open secure doors, approved MFA prompts without looking — users optimize for convenience. Design with human behavior in mind.

  • Security as a blocker: When security teams only say "no" without offering alternatives, engineering teams learn to avoid asking. Security should be an enabler: "Here is how to do that safely."

  • Cargo cult security: Implementing security controls because "best practice" without understanding why they exist or whether they apply to your context. Rotate passwords because NIST said so — but NIST changed that guidance in 2017.

  • Neglecting the baseline: Some security measures are non-negotiable regardless of risk level. HTTPS, parameterized queries, and keeping software updated cost almost nothing and prevent the most common attacks.

  • Measuring security by control count: Having 200 security controls does not mean you are more secure than having 20. What matters is whether the right controls are in place for your specific threats.

Key Takeaways

  • Security and usability are a trade-off, not a binary choice. Your position on the spectrum should be driven by risk assessment, not assumptions.
  • Risk equals likelihood times impact. Calibrate your security controls to match — banking-grade security for banking, proportional security for lower-risk systems.
  • Security controls that frustrate users create workarounds. Workarounds are almost always less secure than no control at all.
  • Spend your security budget where the risk is highest. Not every system needs the same level of protection.
  • Security theater creates a false sense of safety. Compliance does not equal security. Focus on controls that actually reduce risk.
  • The baseline is non-negotiable: HTTPS, parameterized queries, updated dependencies, and proper authentication. Everything above that is proportional to risk.