12  Security Concepts & Challenges

Learning Objectives

After completing these challenges, you will be able to:

  • Analyze the security implications of token-based authentication, role-based access control, and account lockout policies
  • Design time-based access control and two-person rule implementations for IoT systems
  • Evaluate common security vulnerabilities such as timing attacks and their constant-time countermeasures
  • Implement defense-in-depth strategies combining authentication, authorization, and audit logging

Authentication and access control for IoT determine who or what is allowed to interact with your system and what they can do. Think of it like a building security system: first you check someone’s ID badge (authentication), then you determine which rooms they can enter (access control). For IoT, this means verifying that devices and users are genuine before granting them access.

“Challenge time!” Max the Microcontroller rubbed his circuits together. “These exercises test whether you REALLY understand security, not just memorize definitions. For example: if an employee gets fired at 10:30 AM but their access token is valid until 11:00 AM, what is the security gap?”

“Thirty minutes of unauthorized access!” Sammy the Sensor answered quickly. “That is why token expiration times are so important. Shorter tokens mean smaller security gaps, but more overhead from refreshing. It is a tradeoff!”

“Timing attacks are another brain teaser,” Lila the LED said. “If your password checker compares characters one by one and returns ‘wrong’ as soon as it finds a mismatch, an attacker can measure HOW LONG the check takes. If ‘aaa’ takes 1 millisecond but ‘paa’ takes 2 milliseconds, they know the first letter is ‘p’! The fix is constant-time comparison – always check ALL characters, regardless of when a mismatch occurs.”

“These challenges cover real concepts used in production systems,” Bella the Battery noted. “OAuth 2.0 tokens, Kubernetes RBAC, AWS IAM policies – the same principles apply whether you are working on a tiny ESP32 or a massive cloud system. Master these challenges and you will understand security at a deep level!”

12.1 Security Concepts Demonstrated

Concept Implementation Real-World Application
Token-Based Auth RFID card IDs matched against database Physical access cards, API keys, JWT tokens
Role-Based Access Control GUEST < USER < ADMIN hierarchy Corporate access levels, AWS IAM roles
Account Lockout 60s lockout after 3 failures, escalating Windows account lockout, banking apps
Disabled Accounts Active flag checked during authentication Employee offboarding, compromised accounts
Constant-Time Compare XOR comparison prevents timing attacks Secure password validation, crypto libraries
Audit Logging Complete event trail with timestamps SIEM systems, compliance logging
Separation of Concerns Authentication separate from Authorization OAuth 2.0 (AuthN) vs resource permissions (AuthZ)
Defense in Depth Multiple checks: valid card, active account, sufficient level Enterprise security architecture
Visual Security Feedback LEDs indicate system state Security cameras, alarm panels
Escalating Lockouts Longer lockouts for repeated failures Google account protection

12.2 Real-World Case Studies

Case Study: Target Corporation HVAC Contractor Breach (2013)

What happened: Attackers gained access to Target’s corporate network by stealing network credentials from Fazio Mechanical, a third-party HVAC contractor. Fazio had remote access to Target’s building management systems for monitoring energy consumption and HVAC performance across 1,797 stores. The attackers used Fazio’s access to pivot from the building automation network to Target’s point-of-sale systems.

Timeline and scope:

Date Event
Nov 15, 2013 Attackers phish Fazio Mechanical employee, steal VPN credentials
Nov 27 Malware installed on POS systems via lateral movement from HVAC network
Dec 2-15 40 million credit card numbers exfiltrated over 18 days
Dec 15 Target notified by Department of Justice; breach discovered
Dec 19 Public disclosure

Total impact: $292 million in breach-related costs. CEO and CIO resigned. 40 million payment cards and 70 million customer records compromised.

Access control failures that enabled the breach:

Failure What Should Have Existed IoT Relevance
Flat network HVAC and POS on same network segment IoT devices (BMS, cameras, sensors) must be on isolated VLANs – never on the same subnet as critical business systems
Excessive third-party access Fazio had 24/7 VPN access with broad network visibility Contractor access should be time-limited, MFA-protected, and restricted to specific device IPs only
No lateral movement detection HVAC credentials used to access POS servers triggered no alerts Behavioral analytics should flag when a building automation account accesses financial systems
Shared credentials Fazio used one set of credentials for all technicians Each technician should have individual accounts with role-based access and audit logging
No network microsegmentation Once inside, attackers moved freely Zero-trust architecture: every device-to-device connection requires authentication, regardless of network location

Design lesson for IoT systems: The Target breach is the canonical example of why IoT/OT network segmentation is non-negotiable. Every building management system, HVAC controller, smart lighting panel, and security camera must be isolated from business-critical networks. The cost of a VLAN configuration is negligible; the cost of a flat network is potentially hundreds of millions of dollars.

Case Study: Verkada Camera Breach (2021)

In March 2021, a hacker collective gained access to 150,000 live camera feeds from Verkada, a Silicon Valley security camera company. The breach exposed feeds from Tesla factories, Cloudflare offices, Halifax Health hospitals, and a county jail in Alabama. The attack vector was remarkably simple and illustrates multiple access control failures that the challenge exercises below are designed to prevent.

Attack sequence:

Step What Happened Which Challenge Exercise Addresses This
1. Credential discovery Attackers found a super-admin username and password exposed in an unprotected internal tool accessible via the public internet Challenge 1 (Time-Based Access): Internal tools should only be accessible during business hours from corporate IPs
2. Privilege escalation The super-admin account had root access to ALL 150,000 cameras across ALL customers – no tenant isolation RBAC principles: A single account should never have cross-tenant access. Role hierarchy must include customer boundaries
3. No MFA required The super-admin account used password-only authentication with no second factor Multi-factor concepts: Any account with fleet-wide access must require MFA
4. No detection Attackers browsed live feeds for 36+ hours before Verkada was notified by Bloomberg journalists, not by their own monitoring Audit logging: All super-admin actions should trigger real-time alerts, especially accessing cameras outside normal support workflows
5. No session limits Once authenticated, the session persisted indefinitely with no re-authentication challenge Challenge 3 (Temporary Access): Admin sessions should expire after short periods and require re-authentication

Quantifying the access control failures:

  • 150,000 cameras accessible from a single credential set
  • 36+ hours of undetected access
  • 0 MFA challenges presented during the entire attack
  • 0 anomaly alerts triggered despite accessing cameras across hundreds of customer accounts
  • Verkada’s stock-market valuation dropped from $1.6 billion to an undisclosed lower figure in subsequent funding rounds

What proper access control looks like (post-breach remediation):

Verkada implemented changes that map directly to the concepts in this chapter:

  1. Mandatory MFA for all internal accounts (hardware security keys for super-admins)
  2. Tenant-scoped access: Support staff can only access cameras for customers who have opened active support tickets, with automatic expiration after ticket closure
  3. Two-person rule for cross-tenant access (Challenge 2) – accessing cameras outside a support ticket requires approval from a second admin
  4. Real-time anomaly detection: Accessing more than 10 cameras in 5 minutes triggers an automatic session lock and security team notification
  5. 90-day credential rotation with no password reuse across the previous 12 cycles

Design lesson for IoT systems: Verkada’s cameras were technically sophisticated – end-to-end encrypted video, edge-based AI for person detection, tamper-proof hardware. But none of that mattered because the access control layer used a single shared super-admin password with no MFA, no session expiration, and no anomaly detection. Security is only as strong as its weakest access control link.

12.3 Challenge Exercises

Challenge 1: Add Time-Based Access Control

Modify the system so certain zones are only accessible during “business hours” (simulate with a time window). Requirements: - Server Room: Only accessible 9 AM - 5 PM - After hours, even admins need a special override code - Log all after-hours access attempts

Challenge 2: Implement Two-Person Rule

For high-security zones (Control Center), require two different admin cards within 30 seconds: 1. First admin presents card 2. System prompts “Waiting for second administrator…” 3. Second admin presents different card within time limit 4. Both must be admin level 5. If timeout or same card, deny access

Challenge 3: Add Temporary Access Passes

Implement visitor passes with expiration: - Create a new ACCESS_VISITOR level - Visitor cards expire after a set time (e.g., 8 hours from first use) - Track first-use timestamp per card - Automatically disable expired passes

Challenge 4: Implement Anti-Passback

Prevent “tailgating” by tracking entry/exit: - Users must exit a zone before re-entering - If card used for entry without previous exit, deny access - Track current zone for each user - Alert on anti-passback violations

Challenge 5: Add Emergency Override

Implement an emergency mode for fire/evacuation: - Special “EMERGENCY” command unlocks all doors - All access restrictions temporarily disabled - Heavily logged with alert - Auto-reverts after 10 minutes or manual reset - Requires special admin confirmation

12.4 Concept Relationships

How Challenge Exercise Concepts Connect
Challenge Type Builds On Enables Common Confusion
Time-based access Resource definitions Business hours restrictions, maintenance windows “Why not use session timeouts?” - Sessions expire credentials; time-based restricts resources by hour
Two-person rule Authentication + audit logging Separation of duties for critical operations “Can’t the first person just scan twice?” - Good implementations require different user IDs
Temporary access passes Token lifecycle Visitor management with auto-expiration “Why not just give them a regular account?” - Temporary passes auto-expire without admin intervention
Anti-passback Session tracking Tailgating prevention “Why track entry/exit?” - Prevents sharing cards by requiring exit before re-entry
Emergency override Privilege escalation Safety-critical access with heavy logging “Why allow overrides at all?” - Life-safety situations require bypassing normal security

Key Insight: Challenge exercises demonstrate how to extend basic RBAC with context-aware rules (time, location, dual authorization) and special cases (emergencies, visitors) that real-world systems encounter.

12.5 Reference Material

The effectiveness of account lockout is measured by the time \(T_{\text{attack}}\) required to test \(N\) credentials versus the lockout duration \(T_{\text{lockout}}\) after \(n\) failed attempts.

\[T_{\text{attack}} = N \times \left(\frac{1}{r} + \frac{T_{\text{lockout}}}{n}\right)\]

where \(r\) is the attempt rate (attempts/second) and \(n\) is the lockout threshold.

Working through an example:

Given: IoT access control system with: - 4-digit PIN space: \(N = 10^4 = 10,000\) possible PINs - Lockout threshold: \(n = 3\) failed attempts - Lockout duration: \(T_{\text{lockout}} = 60\) seconds - Attacker attempt rate (network limited): \(r = 10\) attempts/second

Step 1: Calculate time to test all PINs WITHOUT lockout

\[T_{\text{no lockout}} = \frac{N}{r} = \frac{10,000}{10} = 1,000 \text{ seconds} \approx 16.7 \text{ minutes}\]

Step 2: Calculate time to test all PINs WITH lockout (3 attempts, then 60s wait)

Number of lockout cycles needed:

\[\text{Cycles} = \frac{N}{n} = \frac{10,000}{3} \approx 3,333 \text{ cycles}\]

Total time including lockouts:

\[T_{\text{with lockout}} = \frac{N}{r} + \text{Cycles} \times T_{\text{lockout}} = 1,000 + 3,333 \times 60 = 201,000 \text{ seconds} \approx 55.8 \text{ hours}\]

Step 3: Calculate security improvement factor

\[\text{Improvement} = \frac{T_{\text{with lockout}}}{T_{\text{no lockout}}} = \frac{201,000}{1,000} = 201\times\]

Result: A 3-attempt lockout with 60-second penalty increases brute force attack time from 17 minutes to 56 hours – a 201x improvement, making the attack impractical for most scenarios.

In practice: Brute force attacks against IoT device PINs or passwords can be defeated with minimal lockout durations. However, lockout durations must balance security (longer is better) with usability (legitimate users who mistype need reasonable retry windows). For high-security systems, escalating lockouts (60s after 3 failures, 300s after 6 failures, 3600s after 9 failures) provide strong protection while allowing legitimate users to recover from mistakes.

A data center implements time-based access restrictions for contractors. Contractors can access server racks only during business hours (6 AM - 8 PM) with an emergency override requiring supervisor approval.

Time-Based Policy:

struct TimePolicy {
    uint8_t allowedStartHour;  // 6 (6 AM)
    uint8_t allowedEndHour;    // 20 (8 PM)
    bool requiresOverride;     // false during hours, true outside
};

bool checkTimePolicy(TimePolicy policy, uint32_t currentHour) {
    bool withinHours = (currentHour >= policy.allowedStartHour &&
                        currentHour < policy.allowedEndHour);

    if (withinHours) return true;  // Access granted during hours

    // Outside hours - check for override
    if (policy.requiresOverride) {
        return requestEmergencyOverride();  // Requires supervisor RFID
    }

    return false;  // Denied
}

Audit Trail Sample:

09:15:30 | CONTRACTOR_001 | SERVER_ROOM_A | GRANTED   | Within hours
19:45:22 | CONTRACTOR_002 | SERVER_ROOM_B | GRANTED   | Within hours
20:10:15 | CONTRACTOR_001 | SERVER_ROOM_A | OVERRIDE  | Supervisor: ADMIN_005
23:30:00 | CONTRACTOR_003 | SERVER_ROOM_C | DENIED    | Outside hours, no override

Production Benefit: Reduced after-hours incidents by 67% (32 incidents/year to 11/year) and contractor overtime costs by 23% by eliminating unnecessary after-hours work.

Lockout Policy Security Benefit User Impact Best For
3 failures, 60s lockout Slows brute force attacks Minimal (legitimate users retry) General IoT access (badge readers)
5 failures, 5min lockout, escalating Defeats automated attacks Moderate frustration Corporate networks, moderate security
3 failures, permanent lock + admin unlock Strongest protection High (support burden) Financial systems, admin accounts
10 failures, CAPTCHA Defeats bots, allows retries Low (familiar UX) Web-facing IoT dashboards
Rate limiting (1 attempt/2s) Prevents rapid testing None for humans, blocks bots API authentication endpoints

Escalating Lockout Example:

  • Attempt 1-3: Immediate retry allowed
  • Attempt 4-6: 60-second lockout
  • Attempt 7-9: 5-minute lockout
  • Attempt 10+: 30-minute lockout + security alert

Factors to Consider:

  • False positive cost: Bank ATM wrong PIN = 24hr card lock (high security). Office badge = 60s (usability)
  • Attack surface: Internet-facing = stricter. Local network = more lenient
  • Reset mechanism: Self-service (email code) vs helpdesk vs automatic time-based
Common Mistake: Not Resetting Failed Attempt Counter After Successful Login

What practitioners do wrong: They increment a failed login counter on each failed attempt but never reset it on successful login, or reset it only after lockout expires.

Why it fails: If a user enters the wrong password 2 times, then successfully logs in, then mistypes the password once more later, they get locked out (2 + 1 = 3 failures). This penalizes users for past mistakes even after proving their identity.

Correct approach:

void handleLoginAttempt(User* user, const char* password) {
    if (verifyPassword(user, password)) {
        // SUCCESS - reset counter immediately
        user->failedAttempts = 0;
        user->lockoutUntil = 0;
        grantAccess(user);
    } else {
        // FAILURE - increment counter
        user->failedAttempts++;
        if (user->failedAttempts >= MAX_FAILED_ATTEMPTS) {
            user->lockoutUntil = millis() + LOCKOUT_DURATION;
            user->failedAttempts = 0;  // Reset after lockout applied
        }
    }
}

Additional Best Practice: Also reset the counter after a time window (e.g., failed attempts expire after 30 minutes even without successful login). This prevents permanent lockout if the user stops trying.

Real-world consequence: A 2016 banking app implementation never reset failed PIN counters. Users who occasionally mistyped their PIN accumulated failures over weeks, eventually getting locked out despite never exceeding 3 failures in a single session. Customer support costs increased 40% handling lockout resets. Fix: reset counter on success OR after 24 hours of no attempts.

12.6 Knowledge Check

12.7 See Also

Within This Module:

Related Security Topics:

Real-World Examples:

  • Two-person rules in banking (SOX compliance) and nuclear facilities (NERC CIP)
  • Time-based access in data centers and SCADA systems
  • Anti-passback in subway systems and secure facilities

Common Pitfalls

Testing only that authorized users can access their resources leaves the authorization boundary untested. For every positive test, write a corresponding negative test verifying that an unauthorized user is rejected, specifically including edge cases (expired tokens, wrong roles, cross-user access attempts).

Many developers test vertical escalation (user trying admin endpoints) but forget horizontal escalation (user A accessing user B’s devices by guessing device IDs). Always verify that resource ownership is validated server-side, not just permission level.

Security challenges that seem contrived (“an attacker would never do this”) often represent real attack patterns. Every challenge scenario should be treated as a realistic attack vector until you can demonstrate why your specific implementation is immune to it.

If a security challenge reveals an unauthorized API access, fixing it by hiding the button in the frontend is not a security fix — the API endpoint remains vulnerable. Always fix the authorization enforcement at the API layer, not in the client application.

12.8 What’s Next

After completing these challenge exercises, continue to:

Key Concepts

  • Privilege Escalation Attempt: A test that verifies a low-privilege user cannot access high-privilege resources by manipulating tokens, roles, or API endpoints
  • Horizontal Privilege Escalation: Accessing another user’s resources at the same privilege level by manipulating user IDs in API requests (e.g., GET /devices/999 when authenticated as user with device 123)
  • Token Forgery Test: Verifying that a manually crafted JWT with modified claims is rejected because the signature is invalid
  • Race Condition: A security test that sends concurrent requests to detect time-of-check-time-of-use (TOCTOU) vulnerabilities in permission enforcement
  • Enumeration Attack: Attempting to discover valid usernames, device IDs, or resource IDs by observing different error responses for valid vs. invalid values
  • Insecure Direct Object Reference (IDOR): A vulnerability where changing a resource ID in a URL allows access to another user’s resources; prevented by server-side authorization checks
  • Security Regression Test: A test specifically written to prevent a previously discovered vulnerability from reappearing after code changes
In 60 Seconds

Security challenge exercises stress-test your access control implementation by attempting privilege escalation, token forgery, role confusion, and timing attacks — the same techniques real attackers use — revealing gaps in your implementation that functional tests miss.

Or return to the Authentication and Access Control Overview.