15  Credential Security

15.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Understand Password Attacks: Identify brute force, dictionary, rainbow table, and credential stuffing attack methods
  • Implement Secure Password Storage: Use bcrypt/Argon2 with per-user salts to protect credentials
  • Deploy Multi-Factor Authentication: Combine knowledge, possession, and biometric factors for IoT
  • Eliminate Default Credentials: Implement unique per-device credential generation
  • Apply Risk Assessment: Use STRIDE threat modeling and risk formulas for security prioritization

What is Authentication Security? Authentication verifies identity—proving you are who you claim to be. In IoT, this applies to users accessing dashboards, devices connecting to brokers, and services communicating with each other. Poor authentication (like default passwords) is the #1 cause of IoT compromises.

Why does it matter? The 2016 Mirai botnet used just 62 default username/password combinations to compromise over 600,000 IoT devices. These devices then launched the largest DDoS attack in history, taking down Twitter, Netflix, and major websites for hours.

Key terms: | Term | Definition | |——|————| | Brute Force Attack | Systematically trying all possible passwords until finding the correct one | | Dictionary Attack | Trying common passwords from wordlists (password123, qwerty, admin) | | Rainbow Table | Pre-computed hash-to-password mappings for instant password reversal | | Salt | Random data added to password before hashing to prevent rainbow table attacks | | MFA | Multi-Factor Authentication—requiring multiple proof types (password + phone code) |

“The Mirai botnet tried just 62 passwords and compromised over 600,000 devices,” Max the Microcontroller said grimly. “Default passwords are the number one IoT security failure. Let us learn how to do it RIGHT.”

Sammy the Sensor explained the attacks. “Brute force means trying EVERY possible combination – a, b, c… aa, ab, ac… For a 4-character password, that is millions of attempts. Dictionary attacks are smarter – they try common passwords first: ‘password’, ‘123456’, ‘admin’. Rainbow tables are pre-computed databases that reverse hash values instantly. All three are dangerous!”

“The defense is proper password storage,” Lila the LED said. “NEVER store passwords as plain text or simple hashes! Use bcrypt or Argon2, which add a random ‘salt’ to each password before hashing. The salt means that even if two people have the same password, their stored hashes are completely different. And these algorithms are intentionally SLOW – they might take 250 milliseconds to verify one password, which barely slows down a real user but makes brute force attempts take millennia.”

“Multi-factor authentication is the ultimate protection,” Bella the Battery concluded. “Even if someone steals your password (something you know), they still need your phone (something you have) to get the time-based code. And for IoT devices, every device should have a UNIQUE credential generated during manufacturing. No more shipping millions of devices all with the same ‘admin/admin’ login!”

15.2 Prerequisites

Before diving into this chapter, you should be familiar with:

How It Works: Password Attack Methods and Defenses

Understanding how attacks work reveals why specific defenses matter:

Attack 1: Brute Force (Try Every Possible Password)

  • Method: Systematically try all combinations: “a”, “b”, “c”, …, “aa”, “ab”, “ac”…
  • Speed: GPUs can test 100 billion MD5 hashes per second
  • Example: 8-character mixed-case password with symbols (95^8 possibilities) cracked in about 8 days at 10 billion guesses/sec
  • Defense: Slow hashing (bcrypt cost 12 = ~250ms per attempt) makes the same password take 53 million years

Attack 2: Dictionary (Try Common Passwords)

  • Method: Test wordlists of common passwords: “password123”, “qwerty”, “admin”, “12345678”
  • Speed: rockyou.txt has 14 million real-world passwords, tested in minutes
  • Example: 32% of users choose passwords from top 10,000 most common (instant crack)
  • Defense: Password complexity requirements + breach database checking (Have I Been Pwned API)

Attack 3: Rainbow Tables (Pre-Computed Hash Lookups)

  • Method: Pre-compute hashes for all likely passwords, store in giant lookup table
  • Speed: Hash lookup is nearly instant (no brute force needed)
  • Example: 16 GB rainbow table cracks 99% of 8-char passwords in under 1 second
  • Defense: Salting (random per-user salt makes rainbow tables useless)

Attack 4: Credential Stuffing (Reused Password Exploitation)

  • Method: Use username/password pairs leaked from other breaches (Collection #1: 773 million credentials)
  • Speed: Automated bots test stolen credentials across thousands of sites
  • Example: 0.1% success rate on 1 million attempts = 1,000 compromised accounts
  • Defense: MFA (even if password is stolen, attacker needs second factor)

Combined Defense Strategy:

Password Storage: Argon2id (memory-hard, ~100ms per hash)
+ Random Salt: 16 bytes per user (defeats rainbow tables)
+ Account Lockout: 3 attempts then 1 minute lockout (defeats brute force)
+ Breach Checking: Reject passwords from Have I Been Pwned (defeats dictionary)
+ MFA Required: TOTP/hardware token (defeats credential stuffing)
= Comprehensive protection against all four attack vectors

Real-World Impact: The Target breach (2013) used stolen HVAC vendor credentials (reused across systems). With MFA, the stolen password alone would have been useless.

15.3 Password Security

15.3.1 Common Password Attacks

Flowchart showing four password attack methods: brute force trying all combinations, dictionary attacks using common wordlists, rainbow table lookups of pre-computed hashes, and credential stuffing from leaked databases, each paired with its primary defense strategy
Figure 15.1: Password attack methods including brute force, dictionary, rainbow table, and credential stuffing with corresponding defenses

This view visualizes the relationship between password complexity and time-to-crack:

Bar chart comparing password strength levels from weak 4-digit PINs cracked in microseconds to strong 12-character mixed passwords requiring millions of years to brute force at 10 billion guesses per second

Password strength comparison showing weak, moderate, and strong passwords with estimated crack times at different attack speeds

Password Policy Recommendations:

  • IoT Device Admin: Minimum 12 characters, random generation required
  • API Keys: Minimum 32 characters, cryptographically random
  • User Passwords: Minimum 12 characters, passphrase recommended
  • Never: Use dictionary words, personal info, or common patterns

This view compares different authentication factors by security strength and usability for IoT contexts:

Comparison table of authentication factors: knowledge factors like passwords and PINs, possession factors like hardware tokens and smartphones, and biometric factors like fingerprints, evaluated on security strength, user convenience, and suitability for IoT deployments

Authentication factor comparison matrix showing knowledge, possession, and biometric factors rated by security strength and usability

IoT Authentication Recommendations:

  • Device-to-Cloud: X.509 certificates stored in secure element
  • User-to-Device: OAuth 2.0 with smartphone MFA
  • Device-to-Device: Pre-shared keys or mutual TLS
  • Continuous Auth: Behavioral analysis detecting anomalous patterns

15.3.2 Default IoT Credentials (Never Use!)

Top 5 default credentials compromising IoT devices:

  1. support/support
  2. admin/admin
  3. admin/0000
  4. user/user
  5. root/12345

Mirai Botnet: Used 62 default username/password combinations to compromise over 600,000 IoT devices.

15.3.3 Multi-Factor Authentication

Diagram showing multi-factor authentication flow combining three factor types: something you know like a password, something you have like a hardware token or smartphone, and something you are like a fingerprint, with each factor adding an independent layer of security
Figure 15.2: Multi-factor authentication combining knowledge, possession, and biometric factors for layered identity verification

NIST Authentication Cornerstones:

  1. Something you know (password)
  2. Something you have (ID badge, cryptographic key)
  3. Something you are (biometrics)

15.4 Worked Example: Password Entropy Calculation

Understanding password entropy helps engineers set meaningful credential policies rather than arbitrary rules.

Entropy formula: \(H = L \times \log_2(N)\) where \(N\) = character set size, \(L\) = password length

Scenario: Compare credential approaches for an IoT fleet management dashboard accessed by 200 field technicians.

Credential Policy Character Set (N) Length (L) Entropy (bits) Time to Brute Force (10B guesses/sec)
4-digit PIN 10 4 13.3 1 microsecond
8-char lowercase 26 8 37.6 21 seconds
8-char mixed + symbols 95 8 52.6 7.7 days
4-word passphrase (diceware) 7,776 4 words 51.7 4.2 days
12-char mixed + symbols 95 12 78.8 1.7 million years
X.509 certificate (RSA 2048) N/A N/A ~112 Computationally infeasible

Decision for IoT fleet dashboard:

  • Reject 4-digit PIN (cracked in microseconds by any attacker)
  • Reject 8-char lowercase (a GPU cracks it in under a minute)
  • Reject 8-char mixed or 4-word passphrase without additional defenses (cracked in days by a determined attacker)
  • Accept 12-char mixed + symbols as minimum for human-facing login (combined with MFA and account lockout)
  • Recommend X.509 certificates for device-to-cloud authentication (no human memorization needed)

Real-world perspective: The 2019 Ring doorbell breach affected 3,672 accounts. Attackers did not crack passwords—they used credential stuffing (trying username/password pairs leaked from other breaches). This means even a strong password policy fails if users reuse passwords. For IoT systems with human-facing authentication, MFA is non-negotiable.

15.5 Risk Assessment and Mitigation

15.5.1 Risk Components

Risk calculation diagram illustrating the multiplicative relationship between three risk components: asset value measuring business impact, vulnerability severity measuring exploitability, and threat likelihood measuring attacker capability and motivation, producing a composite risk score for prioritization
Figure 15.3: Risk assessment framework showing how asset value, vulnerability severity, and threat likelihood combine to determine overall risk score

Risk Formula: \(\text{Risk} = \text{Asset Value} \times \text{Vulnerability} \times \text{Threat Likelihood}\)

15.5.2 STRIDE Threat Model

Security risk model diagram illustrating relationship between vulnerabilities (system weaknesses), threats (potential attackers and attack vectors), and risk (likelihood and impact), showing how asset value, vulnerability severity, and threat probability combine to determine overall security risk
Figure 15.4: Vulnerability, risk, and threat relationships in security risk assessment

Spoofing - Impersonating user/device Tampering - Modifying data/code Repudiation - Denying actions Information Disclosure - Data leaks Denial of Service - Service disruption Escalation of Privilege - Unauthorized access elevation

15.5.3 Mitigation Strategies

Risk mitigation frameworks assess vulnerabilities using CVSS scoring, map threats to STRIDE categories, and recommend component-specific and severity-based mitigations. Production systems should integrate with vulnerability management platforms and incident response procedures.

15.6 Knowledge Check

## Worked Example: Credential Security Audit of a Smart Factory

Scenario: A tier-2 automotive parts manufacturer operates a smart factory with 500 IoT devices across 3 production lines. The plant runs 24/7 with 200 workers across 3 shifts. A security audit reveals multiple credential-related vulnerabilities. Assess the risk and design a remediation plan.

Step 1: Current Credential Inventory

Device Category Count Authentication Method Storage Risk
PLCs (Siemens S7) 24 Default password (admin/admin) Plaintext in config Critical
Environmental sensors 200 Shared API key (1 key for all) Hardcoded in firmware Critical
IP cameras 80 Default (admin/12345) Plaintext in NVR High
MQTT devices 150 Anonymous (no auth) N/A Critical
Operator tablets 40 4-digit PIN (shared per shift) OS keychain High
Admin accounts 6 Password (8-char minimum) MD5 hash, no salt High

Step 2: Attack Simulation Results

Testing the admin password hashes using hashcat with the rockyou.txt wordlist:

Account Hash (MD5, unsalted) Crack Time Password Found
admin1 5f4dcc3b5aa765d61d… 0.003 seconds “password”
admin2 e10adc3949ba59abbe… 0.001 seconds “123456”
admin3 25d55ad283aa400af4… 0.008 seconds “12345678”
admin4 d8578edf8458ce06fb… 0.002 seconds “qwerty”
admin5 0d107d09f5bbe40cad… 0.005 seconds “letmein”
admin6 (not cracked) >24 hours 16+ char passphrase

Result: 5 of 6 admin accounts cracked in under 1 second. Only the passphrase-based account survived. With salted bcrypt (cost factor 12), each attempt takes ~250ms instead of nanoseconds—making the rockyou.txt attack take years instead of seconds.

Step 3: Shared Credential Blast Radius

The 200 environmental sensors share one API key: sk_live_a8f3b2c1d4e5f6...

If one sensor is physically compromised (extracted via UART):

  • Immediate impact: Attacker has valid credentials for ALL 200 sensors
  • Attack capability: Inject false temperature/humidity readings on any production line
  • Business impact: Falsified environmental data could cause defective parts, triggering automotive recall (average cost: $500 per vehicle, with 50,000 vehicles per production run = $25 million)
  • Detection difficulty: Injected readings appear legitimate because the API key is valid

With per-device credentials: compromising one sensor affects only that sensor’s data stream, and the anomaly is detectable by cross-referencing with adjacent sensors.

Step 4: Remediation Plan

Phase Action Devices Cost Timeline
Phase 1 (Emergency) Change all default passwords 104 PLCs + cameras $2,000 (labor) 1 week
Phase 2 (Quick win) Enable MQTT authentication 150 MQTT devices $5,000 (config + testing) 2 weeks
Phase 3 (Medium-term) Migrate admin hashes to bcrypt 6 accounts $3,000 (dev + testing) 2 weeks
Phase 4 (Medium-term) Per-device API key provisioning 200 sensors $15,000 (provisioning server) 6 weeks
Phase 5 (Long-term) MFA for operator tablets 40 tablets $8,000 (hardware tokens) 4 weeks
Phase 6 (Long-term) Certificate-based device auth All 500 devices $45,000 (PKI infrastructure) 3 months

Step 5: ROI Calculation

Metric Before After
Time to crack admin accounts Under 1 second Years (bcrypt)
Devices sharing credentials 200 (one key) 0 (per-device)
Default password devices 104 (21%) 0 (0%)
Unauthenticated connections 150 MQTT 0
Blast radius of one compromised device 200 sensors 1 sensor

Total remediation cost: $78,000 over 6 months. Compare to a single automotive recall from falsified sensor data: $25 million. The security investment represents 0.3% of the potential loss from a single incident.

Concept Relationships
Concept Related To Relationship Type
Password Hashing One-Way Functions, Cryptography Applies - Bcrypt/Argon2 use intentionally slow algorithms to resist brute force
Salting Rainbow Table Defense Prevents - Unique salt per password defeats pre-computed hash lookups
MFA (Multi-Factor) Defense-in-Depth Combines - Multiple proof types (know + have + are) resist single-factor compromise
Default Credentials Attack Surface Eliminates - Unique per-device credentials prevent mass exploitation (Mirai botnet)
STRIDE Threat Model Risk Analysis Identifies - Spoofing threats mitigated by strong authentication
Account Lockout Brute Force Mitigation Slows - Escalating timeouts make automated attacks impractical
See Also

Foundation Concepts:

Related Security Topics:

Practical Applications:

Build a password entropy calculator to understand why length beats complexity.

Exercise Steps:

  1. Define character sets: lowercase (26), uppercase (26), digits (10), symbols (33)
  2. Calculate entropy: H = L * log2(N) where N = character set size, L = length
  3. Estimate crack time: time = N^L / (guesses_per_second)
  4. Compare policies: 8-char complex vs 12-char mixed vs 4-word passphrase

Starter Code (Python):

import math

def calculate_entropy(password):
    char_sets = []
    if any(c.islower() for c in password): char_sets.append(26)
    if any(c.isupper() for c in password): char_sets.append(26)
    if any(c.isdigit() for c in password): char_sets.append(10)
    if any(not c.isalnum() for c in password): char_sets.append(33)

    charset_size = sum(char_sets)
    length = len(password)
    entropy = length * math.log2(charset_size)
    return entropy, charset_size

# Test
passwords = [
    "password",           # 8-char lowercase only
    "P@ssw0rd",           # 8-char with complexity
    "correct horse battery staple"  # 28-char passphrase
]

for pwd in passwords:
    bits, charset = calculate_entropy(pwd)
    combinations = charset ** len(pwd)
    seconds = combinations / (10**10)  # 10 billion guesses/sec (GPU)
    years = seconds / (365.25 * 24 * 3600)
    print(f"{pwd}: {bits:.1f} bits (charset={charset}), "
          f"{years:.1e} years to crack")

What to Observe:

  • “password” (8 lowercase chars, charset=26): ~37.6 bits, cracked in seconds
  • “P@ssw0rd” (8 mixed chars, charset=95): ~52.6 bits, cracked in days
  • “correct horse battery staple” (28 chars with spaces, charset=59): ~164 bits, effectively uncrackable

Note: This charset-based calculation gives a worst-case estimate. Real-world attacks use dictionary and pattern-based approaches that can crack “password” and “P@ssw0rd” almost instantly regardless of theoretical entropy.

Extension: Add bcrypt simulation (slow each guess to 0.25 seconds instead of nanoseconds) and compare the crack times.

A cryptographic hash function \(H: \{0,1\}^* \rightarrow \{0,1\}^n\) is collision-resistant if finding two distinct inputs \(x_1 \neq x_2\) such that \(H(x_1) = H(x_2)\) requires \(\Omega(2^{n/2})\) operations (birthday bound).

Birthday Attack Complexity:

\[\text{Attempts} \approx \sqrt{\frac{\pi \cdot 2^n}{2}} = 1.25 \times 2^{n/2}\]

Working through an example:

Given: Password database stores SHA-256 hashes (256-bit output). Attacker attempts birthday attack to find collision.

Step 1: Birthday bound for SHA-256 \[n = 256 \text{ bits}\]

\[\text{Attempts} = 1.25 \times 2^{128} = 4.25 \times 10^{38} \text{ hash operations}\]

Step 2: Attack cost at 10 billion hashes/second \[\text{Time} = \frac{4.25 \times 10^{38}}{10^{10} \times 86400 \times 365.25} = 1.35 \times 10^{21} \text{ years}\]

Comparison: MD5 (128-bit) vs SHA-256 (256-bit)

MD5 birthday bound: \[\text{Attempts}_{MD5} = 2^{64} = 1.84 \times 10^{19}\]

With GPU cluster (\(10^{12}\) hashes/sec): \[\text{Time}_{MD5} = \frac{1.84 \times 10^{19}}{10^{12}} = 1.84 \times 10^7 \text{ seconds} \approx 213 \text{ days}\]

Result: SHA-256 collision requires \(10^{21}\) years (infeasible). MD5 collision feasible in about 213 days with a GPU cluster—which is why MD5 is deprecated for security.

In practice: Password databases must resist preimage attacks where an attacker finds input \(x\) such that \(H(x)\) matches a stored hash (\(2^n\) complexity), as well as collision attacks where an attacker finds two inputs with the same hash (\(2^{n/2}\) complexity). SHA-256’s 128-bit collision resistance exceeds foreseeable computing power. MD5’s 64-bit resistance was broken in 2004—avoid MD5 for any security application.

15.7 Summary

This chapter covered authentication and credential security:

Password Security:

  • Attack methods: Brute force, dictionary, rainbow tables, credential stuffing
  • Defense: Salted hashing (bcrypt/Argon2), account lockout, breach database checking
  • Length beats complexity: 12+ character mixed passwords or passphrases with MFA

Default Credentials:

  • #1 cause of IoT compromise (Mirai botnet used 62 default credentials on 600,000+ devices)
  • Mitigation: Unique per-device credentials, forced password change on first boot

Multi-Factor Authentication:

  • Three factors: Know (password), Have (token), Are (biometric)
  • IoT recommendation: Device certificates + API tokens + behavioral analysis

Risk Assessment:

  • Risk = Vulnerability x Threat x Asset Value
  • STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege
  • Prioritize by risk score, not just vulnerability severity

Common Pitfalls

Factory-default credentials (admin/admin, password/password) are publicly known and scanned for by botnets within minutes of a device going online. Never ship IoT devices with default credentials — force credential change on first login or generate unique random credentials at manufacturing.

Rotating credentials annually meets compliance requirements but doesn’t protect against keys that were compromised 11 months ago. Implement automated anomaly detection on API usage patterns and trigger immediate rotation when compromise is suspected, not just on schedule.

Credentials embedded in mobile apps or JavaScript code can be extracted by decompiling the app or reading browser storage. Use OAuth 2.0 with PKCE for user-delegated access from mobile apps; never embed long-lived API keys in client-side code.

During a security incident, rapid credential rotation requires knowing every place a credential is used. Maintain a credential inventory mapping each credential to the services that use it, the person responsible, the rotation procedure, and the emergency contact. Undocumented credentials slow incident response by hours.

15.8 What’s Next

If you want to… Read this
Learn about secure boot and OTA updates Firmware Security and Updates
Understand software vulnerabilities Software Vulnerabilities
Secure IoT protocol communications IoT Protocol Security
Learn cryptographic fundamentals Encryption Principles
Apply zero trust to credential management Zero Trust Security

Key Concepts

  • Credential Lifecycle: The complete sequence of states a credential passes through: generation → provisioning → active use → rotation → revocation → destruction
  • Hardware Security Module (HSM): A dedicated hardware device that stores cryptographic keys and performs operations in a physically secure, tamper-evident boundary
  • Certificate Pinning: Configuring a device or application to accept only specific certificates or public keys, rather than trusting any certificate signed by a valid CA; prevents CA-level compromise from enabling MITM
  • Key Derivation: Using a master secret combined with device-specific data (serial number, MAC address) to derive unique per-device keys without storing each key individually
  • Secrets Manager: A cloud service (AWS Secrets Manager, HashiCorp Vault) that stores, rotates, and audits access to API keys, database passwords, and certificates
  • Dead Reckoning Key Management: Pre-generating a fixed sequence of keys from a master secret so that key rotation can occur without connectivity; used for constrained IoT devices
  • Credential Stuffing: An attack that uses credentials leaked from other breaches to authenticate to unrelated services; defended against with unique per-service credentials and MFA
In 60 Seconds

Credential security for IoT covers the complete lifecycle from secure provisioning (unique credentials per device, stored in hardware secure elements) through secure transmission (TLS with certificate pinning) to secure storage (encrypted key vaults) and revocation — addressing every point where credentials could be exposed to an attacker.