Security in System Design

Password policies are a masterclass in security theater. You've experienced it: a website demands your password contain at least one uppercase letter, one lowercase letter, one number, one special character, no spaces, and be exactly 8-16 characters. Feeling frustrated, you create P@ssword1—technically compliant, trivially crackable.

Meanwhile, researchers have long known that passphrase-based authentication—correct-horse-battery-staple—is both more secure and easier to remember. But the annoying policy persists, because someone equated 'complex-looking' with 'secure.'

This is the security vs. usability trap: implementing controls that feel secure but actually drive users toward insecure workarounds, while making their experience miserable.

The belief that security and usability are inherently opposed is a false dichotomy. In reality, poor security design often creates the conflict. Well-designed security can be nearly invisible—protecting users without burdening them.

This page explores how to design systems that are both secure and usable, avoiding the common pitfalls that make security annoying without making it effective.

Security and usability appear to conflict because security often introduces friction—additional steps, constraints, or complexity that slow users down. But this framing misunderstands the relationship.

The real dynamics:

1. Security creates friction when it adds steps, delays, or cognitive load
2. Users optimize for speed and will find workarounds for friction
3. Workarounds undermine security, often worse than having no control
4. Unusable security fails because users disable, bypass, or complain until it's removed

The key insight: Security that users circumvent provides zero protection while still creating organizational liability. Security must work with human behavior, not against it.

The compliance illusion:

Organizations often implement security controls to satisfy auditors or check compliance boxes, not because they actually improve security. The result is security theater—policies that look good on paper but fail in practice.

• Password expiration every 90 days: NIST no longer recommends this because it encourages weak passwords
• Security awareness training clicking: Users learn to click through training, not apply it
• Locked-down environments: Users frustrated by restrictions find shadow IT alternatives

The test of effective security: Would a user willingly choose to use this control? If not, why not—and can it be redesigned?

Decades of human-computer interaction research have established principles for designing security that users will actually use. These aren't just nice-to-haves—they determine whether your security controls will work in practice.

Principle in practice — password managers:

Consider why password managers succeed where password policies fail:

Password managers align incentives: the easiest thing (auto-fill) is also the most secure thing (unique, complex passwords for every site). This is usable security design.

A one-size-fits-all approach to security inevitably over-secures low-risk actions (adding unnecessary friction) or under-secures high-risk actions (leaving gaps). Adaptive security adjusts friction based on assessed risk.

The risk-based authentication continuum:

Low Risk                                                     High Risk
│                                                                    │
│  Reading public content  →  Modifying profile  →  Changing password  →  Wire transfer
│        │                         │                       │                    │
│   No auth required         Re-verify session        Require MFA         Step-up auth +
│                                                                        out-of-band confirm
└────────────────────────────────────────────────────────────────────────────────────────┘

The principle: Match security friction to action risk. High-risk actions warrant high friction; low-risk actions should flow without interruption.

Signals for risk assessment:

Adaptive security systems evaluate multiple signals to assess risk and adjust authentication accordingly:

• Location: Is this a familiar location or geography?
• Device: Is this a known, previously authenticated device?
• Behavior: Does this action match typical user patterns?
• Time: Is this a normal time for this user?
• Velocity: How many actions in what timeframe?
• Value: How sensitive or irreversible is the action?

Example risk calculation:

Action: Transfer $5000 to new recipient

Risk factors:
  ✓ Known device      (-1 risk)
  ✓ Familiar location (-1 risk)
  ✗ New recipient     (+2 risk)
  ✗ Large amount      (+2 risk)
  ✓ Normal hours      (-1 risk)
  
Net risk score: +1 (elevated)

Response: Require MFA + SMS confirmation

Authentication is where security meets users most directly. Poor authentication UX leads to workarounds that compromise security. Here's how to get it right:

Modern password practices:

NIST 800-63B (2020) updated password guidance based on research. Key recommendations:

Multi-factor authentication done right:

MFA significantly improves security but can destroy usability if poorly implemented:

Bad MFA UX:

• Requiring MFA for every single action
• No device recognition (reauth constantly on the same device)
• SMS only (slow, insecure, requires phone signal)
• Counting down codes adding time pressure
• No backup methods if primary fails

Good MFA UX:

• Remember trusted devices for period
• Push notifications (approve button, not code entry)
• Multiple methods (authenticator app, hardware key, SMS backup)
• Clear recovery path if MFA device is lost
• Risk-based triggering (only when risk elevated)

Passkeys — the future of authentication:

Passkeys (FIDO2/WebAuthn) combine the security of hardware tokens with the convenience of biometrics. Users authenticate with Face ID, Touch ID, or Windows Hello—no passwords to remember. Resistance to phishing. No server-side password storage to breach.

Just as you budget money, you should budget friction. Every friction-adding security control spends from a limited budget of user tolerance. Overspend, and users seek workarounds or abandon your product.

The friction budget concept:

• Users have a finite tolerance for friction in any session/day/week
• Each security control 'spends' from this budget
• When budget is exhausted, users game the system or leave
• High-value controls are worth spending on; low-value controls are not

Budgeting framework:

Reducing friction without reducing security:

Several techniques reduce friction while maintaining security:

1. Remember trusted devices: Don't require MFA if device is known and no risk signals present.

2. Session extension on activity: Keep users logged in while actively using the application.

3. Progressive authentication: Start with low friction; escalate only for high-risk actions.

4. Batch security decisions: Ask for permissions/consents together rather than interrupting repeatedly.

5. Async verification: Allow action to proceed, verify in background, roll back if invalid.

6. Passkeys/biometrics: Strong authentication with minimal user effort.

The key trade-off question: For this control, is the security benefit worth the friction cost? If users will work around it, the security benefit may be zero—all cost, no gain.

When security controls block users—whether correctly or incorrectly—the recovery experience determines whether users remain engaged or seek workarounds.

Security errors happen to legitimate users:

• Forgotten passwords
• Lost MFA devices
• Suspicious login location (traveling)
• Temporary account lockout from failed attempts
• Session expiration during long form completion

Each of these is a moment of truth. Handle it well, and security protects without alienating. Handle it poorly, and users learn to circumvent security.

Example: Account lockout recovery flow

Bad flow:

'Your account has been locked.'
[No explanation, no next steps]

Good flow:

'Your account is temporarily locked'

This happened because we noticed multiple unsuccessful login
attempts. This lock protects your account from unauthorized access.

Your options:
1. Wait 30 minutes and try again
2. Reset your password via email [Reset Password]
3. Call support at 1-800-XXX-XXXX for immediate unlock

Need to log in urgently? Use your backup codes: [Use Backup Code]

The good flow explains, provides options, and respects that the lockout might affect a legitimate user.

Not all friction is bad. Sometimes friction is the appropriate response to risk, and user convenience must yield to security. The key is knowing when friction is justified versus when it's just poor design.

Friction is justified when:

1. Actions are irreversible. Wire transfers, account deletion, data export—high-impact actions warrant confirmation.

2. User is making security decisions. Granting permissions, sharing data, choosing security settings—users should be deliberate.

3. Damage potential is catastrophic. Medical records, financial access, administrative privileges—the stakes justify the friction.

4. Regulatory requirements mandate it. Some industries require specific controls regardless of UX impact.

5. Adversary is actively attacking. During credential stuffing attacks, increased friction (CAPTCHA) is appropriate.

Making justified friction feel fair:

Even when friction is necessary, presentation matters:

• Explain the why: 'We require additional verification for transfers over $1000 to protect your funds.'
• Show the benefit: 'This security step has prevented $X million in fraud this year.'
• Minimize unnecessary repetition: Don't re-verify for similar actions in quick succession.
• Provide control where possible: 'You can opt out of this verification for amounts under $500.'
• Make it feel protective, not punitive: Security should feel like a shield, not a barrier.

The principle: Users accept friction they understand and agree with. Unexplained friction feels arbitrary. Explained friction feels protective.

How you communicate security matters as much as what you implement. Good security communication builds trust and helps users make informed decisions. Poor communication creates confusion and undermines security.

Principles of security communication:

Effective security notification examples:

Login from new device:

New sign-in to your account

We noticed a sign-in to your account from:
  • Device: Chrome on Windows
  • Location: New York, United States
  • Time: Today at 3:45 PM EST

Was this you?
  [Yes, this was me]  [No, secure my account]

If you don't recognize this activity, click 'Secure my account'
to change your password and review recent access.

Permission request:

Allow Acme App to access your contacts?

This lets Acme App:
  ✓ See your contact names and email addresses
  ✓ Suggest friends who also use Acme

Acme will NOT:
  ✗ Send messages to your contacts
  ✗ Share your contacts with third parties

You can revoke this access anytime in Settings.

  [Allow]  [Deny]

Both examples are clear, specific, and actionable. They help users make informed decisions.

Security UX differs significantly between consumer (B2C) and enterprise (B2B) contexts. Different users, different stakes, different tolerance for friction.

B2C (Consumer) characteristics:

• Users are self-directed and may leave if frustrated
• Security must be nearly invisible to retain engagement
• Users have limited security literacy
• Account value varies widely (some accounts matter little)
• Price sensitivity makes friction a competitive disadvantage

B2B (Enterprise) characteristics:

• Users are mandated to use the system (can't easily leave)
• Security is expected and evaluated during procurement
• Users may be trained and security-aware
• Account compromise has organizational impact
• Enterprises pay for security; friction is more acceptable

Enterprise security configuration:

B2B products often need to support customer-specific security requirements:

• SSO/SAML integration: Customers want their identity provider
• Custom session policies: Some customers require 15-minute timeouts
• IP allowlisting: Restrict access to corporate networks
• Audit log export: Customers need logs for their SIEM
• Data residency: Some customers require data in specific regions
• Role customization: Enterprise orgs have complex permission needs

These add complexity but are often table-stakes for enterprise sales. Design your security to be configurable for B2B while defaulting sensibly for smaller customers.

We've explored the tension between security and usability and how to navigate it effectively. Let's consolidate the key takeaways:

Module complete:

You've completed Module 1: Security in System Design. You now understand:

• Why security must be a first-class requirement
• How to implement defense in depth
• How to systematically identify threats through threat modeling
• How to balance security with usability

These foundational concepts prepare you for the detailed security patterns in the following modules: Authentication, Authorization, OAuth2/OIDC, JWT, and API Security.