Authentication & Access · Study deck
Authentication Methods for IoT
Choose an IoT authentication method by the risk, device, and strength of the factor it can support.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: Fast hashes can permit billions of guesses per second on some GPU setups; a deliberately costly password-hashing function reduces that rate, depending on its parameters and the attacker's hardware.
- Explain: A verifier may allow a narrow adjacent-step window for clock skew, but it must reject reuse of a code already accepted within that window; expiry alone does not prevent replay.
- Explain: The device must hold three things: the CA certificate it trusts, its own device certificate, and its private key — which belongs in a secure element so it cannot be extracted.
Major section
Start With Who Is Signing In
Reusing one login pattern for both can turn one stolen secret into a fleet-wide failure.
- Multi-factor authentication means requiring independent kinds of proof from a person.
- An API means a named software entry point used by another program.
- A gateway is the device or service that joins two system paths.
Major section
Start With Who Is Signing In (continued)
TLS means protected transport that checks the service identity and can also check the client.
- A connected device is not yet a trusted device.
- This runway does not make one method best for every actor.
- The engineering question is which proof fits that actor and threat.
- Passwords are the simplest and the most attacked.
Major section
Start With Who Is Signing In (continued)
Certificates with mutual TLS are the gold standard for unattended devices, giving each unit a unique cryptographic identity.
- Tokens such as JWT carry the result of a prior authentication so an API does not re-check a password on every call.
- The Core IdeaCertificates for devices Unattended devices cannot type passwords or codes.
- A reviewer needs to know it is a salted, deliberately slow hash, not a single fast digest.
Major section
Build the Method Around Risk
Selecting an authentication method is a risk decision, not just a technical one.
- A low-severity flaw on an internet-facing controller can outrank a high-severity flaw on an isolated bench device.
- The output is a method matched to the asset's real exposure.
- Higher; needs a CA, issuance, and revocation.
Major section
Build the Method Around Risk (continued)
Immune; there is no reusable shared secret.
- Constrained devices need room for a key in secure hardware.
- The header names the signing method, the payload carries readable claims, and the signature detects alteration.
- Critically, a JWT payload is not encrypted: it is base64url-encoded and fully readable, with the signature providing tamper-evidence, not confidentiality.
Major section
Under the Hood: What Each Method Proves
An optional pepper — a secret kept separately from the database — adds defense if the hash store alone is stolen.
- The deeper layer explains how each method actually authenticates and why each fails in a specific way.
- The result is a mutually authenticated, encrypted channel.
- An encrypted JWT (JWE) instead has five parts.
Major section
Under the Hood: What Each Method Proves (continued)
A salt is a unique random value per user that is mixed into the hash, so identical passwords produce different stored hashes and precomputed rainbow tables become ineffective.
- Fast hashes can permit billions of guesses per second on some GPU setups; a deliberately costly password-hashing function reduces that rate, depending on its parameters and the attacker's hardware.
- OWASP's Password Storage Cheat Sheet and RFC 9106 favor Argon2id, a memory-hard function; bcrypt, scrypt, and PBKDF2 with appropriate cost settings are alternatives.
- A server can verify a signed token without storing session state — the convenience of statelessness.
Major section
Under the Hood: What Each Method Proves (continued)
The client truly holds its certificate's private key.
- The client then presents its device certificate and proves it holds the matching private key by signing a value in the handshake (the CertificateVerify step).
- The verifier must decide the algorithm, not the token.
- Accepting a presented cert without the signature enables forgery.
Major section
Under the Hood: What Each Method Proves (continued)
Both sides share a secret; a common profile derives a counter from Unix time in 30-second steps and truncates HMAC-SHA1 to six digits.
- The device must hold three things: the CA certificate it trusts, its own device certificate, and its private key — which belongs in a secure element so it cannot be extracted.
- JWT Structure and Algorithm PitfallsA compact signed JWT (JWS) has three base64url parts joined by dots: a protected header, a payload of claims, and a signature or MAC over the first two parts.
- The token is authentic and still valid.
Major section
Under the Hood: What Each Method Proves (continued)
A password alone offers no defense against an attacker who already holds a valid pair.
- Second, pin the expected algorithm to prevent algorithm-confusion attacks, where an attacker takes an RS256 (public-key) configuration and submits an HS256 token signed with the public key treated as an HMAC secret.
- A verifier may allow a narrow adjacent-step window for clock skew, but it must reject reuse of a code already accepted within that window; expiry alone does not prevent replay.
- A trustworthy review names the method, its evidence, and the specific way it would break.
Deck summary
Key takeaways
Reusing one login pattern for both can turn one stolen secret into a fleet-wide failure.
- TLS means protected transport that checks the service identity and can also check the client.
- Certificates with mutual TLS are the gold standard for unattended devices, giving each unit a unique cryptographic identity.
- Selecting an authentication method is a risk decision, not just a technical one.
- Immune; there is no reusable shared secret.
Retrieval practice
Recall check 1 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q1You must authenticate ten thousand headless field sensors to a cloud service, with no human present at any device. Which method fits best?
Show answer
Answer: A Certificates give each device its own identity and support mutual TLS and per-device revocation, which suits large unattended fleets.
Retrieval practice
Recall check 2 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q2A developer proposes embedding each device’s long-lived API secret inside the payload of a signed, non-encrypted JWT so the backend can read it on every request. Why is this unsafe?
Show answer
Answer: C In this signed, non-encrypted JWT, the payload is base64url-encoded and readable to anyone who gets the token.
Retrieval practice
Recall check 3 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q3Leaked password pairs are being tried against an operator console. Which defense set addresses credential stuffing?
Show answer
Answer: A Slowing attempts and requiring another factor make reused passwords less useful.
Retrieval practice
Recall check 4 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q4During a mutual-TLS handshake, what specifically proves that the client legitimately owns the certificate it presented?
Show answer
Answer: C Certificates are public, so presenting one proves nothing.
Print reference
Answers
Answer key.
- A · Certificates give each device its own identity and support mutual TLS and per-device revocation, which suits large unattended fleets.
- C · In this signed, non-encrypted JWT, the payload is base64url-encoded and readable to anyone who gets the token.
- A · Slowing attempts and requiring another factor make reused passwords less useful.
- C · Certificates are public, so presenting one proves nothing.