Authentication & Access · Study deck
Authentication and Authorization
Picture a pump controller that proves its identity but is still denied an administrator command.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
Access control needs separate evidence for identity, permission, and recorded action.
- An identity claim needs a credential to prove the requester.A device serial, username, or certificate subject is a claim until the verifier checks the accompanying proof.
- A successful login still needs an authorization decision.The pump controller can prove its identity while the service denies an administrator command outside its permissions.
- Credential choices must fit device capability and individual revocation.A constrained private-network device can use a protected per-device key, while a capable fleet device can use certificates and secure hardware.
- Independent evidence is needed for different authentication failures.A shared secret, repeated nonce, or second knowledge question can weaken a different part of the access-control design.
Major section
Start With the Door Question
The access sequence begins with a claimed identity and ends with a decision about one request.
- The controller’s credential can support its claimed identity.The left side of the access diagram is the proof presented by a requester, before any permission is granted.
- The verifier checks proof before the service considers permission.A successful authentication result can move the request to authorization, while an unsupported identity must not receive access.
- Authorization limits the actions available to the proven controller.The final grant or denial is specific to the requested action, so a known pump controller can still be refused administrator access.
- Accounting preserves evidence of what happened after the decision.The review needs the request, proof result, policy decision, time, and recorded action to explain the complete access path.
Major section
A genuine badge and a limited room list
The building example separates badge validity from the rooms a person may enter.
- A genuine badge does not grant entry to every room.The building’s reader can authenticate the badge holder while a separate permission rule still prevents access to a particular door.
- The permission list determines which doors the holder may open.A proven identity should receive only the rooms needed for its legitimate work, rather than blanket building access.
- An entry log records how the badge was used.The accounting record can show which doors were used after the identity and permission decisions were made.
- Each control needs its own evidence.A room list cannot protect a building when the badge is never verified, and valid badges alone cannot restrict room access.
Major section
The access audit record
An audit record connects the request with proof, policy, time, and outcome.
- The identity claim names the requester whose credential needs verification.The pump controller’s request must be connected to the identity presented for this access attempt.
- The proof result records whether the expected identity was established.A correct credential can pass authentication, while wrong or expired credentials need a visible verification outcome.
- The policy decision states whether this particular action is permitted.A valid controller requesting an administrator command can pass the identity check and still receive an authorization denial.
- Time and recorded action make the completed request reviewable.The evidence needs to connect the request with its proof, permission decision, and actual outcome after the event.
Major section
Valid, wrong, expired, and excessive requests
A useful test includes denied requests as well as a successful login.
- A valid device can test the intended allowed path.The review needs an authenticated identity performing an action within its permissions, with the result retained in the audit record.
- A wrong credential must fail the identity check.The service cannot treat an unsupported claim as proven merely because the request reached its gateway.
- An expired credential must fail the validity check.The verifier needs to enforce the credential’s validity period instead of accepting proof that is no longer valid.
- A valid identity asking for excess access must be denied.The pump controller can authenticate successfully while its administrator request remains outside the permissions granted to that device.
Activity 1 · Predict
✎ A valid badge asks for too much
I want you to separate proof of identity from permission to act.
A controller proves its identity but requests an administrator command outside its permissions. On paper, predict the authentication result and authorization result. Then list the request, proof, policy, time, and action evidence the audit record should preserve.
3 minutes · Pen and paper · Answer: Activity 1
Major section
Least privilege after identity proof
Least privilege makes permission specific to the identity’s actual job.
- A new or unknown identity starts without protected-resource permissions.Least privilege means the service must establish the requester and its allowed work before granting access.
- A proven identity receives only the access its work requires.The building badge can be genuine without opening every door or allowing changes to all HVAC settings.
- Permission checks need a verified identity to be meaningful.If anyone can claim another person’s identity, a carefully written room list cannot enforce its intended boundary.
- A successful login needs evidence of allowed and denied actions.The review is incomplete until permission enforcement and the accounting record are visible alongside the authentication result.
Major section
Build the Access Plan
Credential selection combines device capability, ownership, and a workable retirement path.
- The diagram separates identities, roles, and permission bundles.Alice, Bob, and Carol are shown before the role layer, so the reader can distinguish a person from the authority assigned.
- Roles connect proven identities to reviewed permissions.Administrator, Engineer, and Operator are the middle layer through which the diagram manages access without sharing credentials.
- Permission bundles define the actions associated with each role.The displayed outcomes are full control, reading plus writing logs, and read-only access rather than one universal permission.
- Credential proof and role assignment remain separate decisions.Proving Alice’s identity cannot choose her role, while assigning a role cannot prove that the requester is Alice.
Major section
Credential checks and retirement
A credential method is only useful when its checks and lifecycle fit the deployment.
- A pre-shared key needs secure storage and a rotation plan.The chapter’s constrained private-network device needs a unique key so one compromised identity can be handled separately.
- Certificate access needs validation, revocation, and protected private-key storage.Chain checks and a working CRL or OCSP path are required alongside the secure element used by a capable fleet device.
- A token needs signature, expiry, and claim validation.Short-lived signed proof is only useful when the service validates each use and has a defined refresh path.
- Prototype API keys need narrow scope and a migration plan.The chapter limits this option to brownfield or prototype use, with per-device scope and encrypted transport as review evidence.
Major section
Independent MFA categories
MFA protects identity through different factor categories, not repeated knowledge questions.
- Passwords and security answers are both knowledge factors.A single phishing page can capture both, so asking two knowledge questions does not establish independent protection.
- A phone or hardware token can supply a possession factor.Something the user has is a different category from a password or PIN that the user knows.
- A biometric supplies an inherence factor with error and recovery limits.False acceptance and false rejection are relevant because a leaked biometric cannot simply be replaced like a password.
- Independent categories require an attacker to defeat different protections.Genuine MFA needs factors from different categories, rather than adding more secrets from the same knowledge category.
Major section
Human identity, delegation, and roles
OAuth 2.0 and OpenID Connect serve distinct parts of human access.
- OAuth 2.0 provides scoped delegation for an application.The framework grants limited authority through access tokens; user authentication is supplied by the separate OpenID Connect identity layer.
- OpenID Connect authenticates the human user.OIDC is built on OAuth 2.0, keeping the identity claim separate from the scopes that grant delegated access.
- RBAC can group reviewed permissions into assignable roles.Many users or devices can receive a common permission bundle without receiving identical credentials or individual one-off grants.
- Parallel roles may need overlapping capabilities instead of a ranking.A nurse and a pharmacist can need different permissions, so their roles cannot always be ordered as more or less privileged.
Major section
Revoking one device and renewing the fleet
Per-device credentials keep recovery from one compromise narrower than the whole fleet.
- A unique credential allows one compromised device to be revoked.The rest of the fleet can keep running because the retired identity is separate from other devices’ credentials.
- A shared product-line key can expose every device using that credential.Extracting the secret from one unit can enable impersonation across the product line without a narrow recovery option.
- Revocation needs a trigger, delivery channel, and audit trail.Those pieces must be planned before deployment so a compromised credential can actually be retired when the need arises.
- Automated enrolment and renewal reduce manual lifecycle work.The chapter gives EST and SCEP as examples that can reduce repeated steps and opportunities for human error.
Major section
Under the Hood: How Proofs Fail
Challenge-response tests secret possession while keeping the secret off the wire.
- The verifier sends a fresh random nonce for the current attempt.The challenge needs to be unique and unpredictable so a recorded response cannot serve as fresh proof later.
- The device uses its protected secret to compute a keyed response.A keyed MAC such as HMAC can combine the nonce with the secret without transmitting the secret itself.
- The verifier compares the returned response with its own expected value.Matching results can demonstrate possession of the secret while the secret stays off the wire.
- A repeated nonce can make a captured response valid again.Even a 256-bit key cannot prevent replay when the same device receives the same challenge.
Major section
Certificate chains and trust checks
Certificate validation must establish the binding between the expected identity and its public key.
- An X.509 certificate is an identity-to-key binding.The certificate authority’s signature is part of the proof, because a public key alone cannot establish whose key was presented.
- The verifier follows the chain to a trusted root.The review needs a valid chain rather than a certificate that the service can merely parse.
- Validation needs signature, name, validity, purpose, and revocation checks.An invalid condition must fail closed, while CRL or OCSP evidence supports retirement of credentials that should no longer be trusted.
- Reading a certificate’s structure does not establish trust.A parseable certificate can still have the wrong identity, invalid period, inappropriate purpose, or an unacceptable trust chain.
Major section
Repeated nonces and replay
Fresh challenges address replay; longer keys address a different attack.
- A captured response can be replayed against the same repeated nonce.The same device secret and challenge produce the same valid response, so the attacker need not compute a new proof.
- A longer secret cannot make a repeated challenge fresh.The 256-bit example can resist guessing while still accepting a previously captured response to the reused nonce.
- The verifier needs unique and unpredictable challenges.Freshness is the property that prevents an old response from serving as proof for a new authentication attempt.
- Authentication evidence must include the challenge sequence.A strong keyed MAC is insufficient when the review cannot establish that each relevant challenge is fresh.
Activity 2 · Predict
✎ Replay the repeated challenge
I want you to test the challenge rather than trust the key length.
Sketch a verifier and device using a 256-bit key. An attacker records a valid response, and the verifier later repeats the nonce. Predict whether replay can succeed, explain why, and write the required nonce properties.
3 minutes · Pen and paper · Answer: Activity 2
Major section
Secret custody and credential retirement
Secret custody and credential retirement limit the consequences of device compromise.
- A secret stored in ordinary flash may be recoverable.Someone holding the hardware can threaten key custody even when the device appears to authenticate correctly during a normal test.
- A secure element or TPM can retain a private key internally.The chapter’s stronger pattern generates the key on-chip and keeps the private value from leaving the protected hardware.
- Shared credentials can turn one extraction into product-line impersonation.A per-device identity limits which credential must be revoked when one physical unit is compromised.
- Rotation, renewal, and revocation must remain workable during operation.Long-lived devices need renewal before certificate expiry and a usable retirement path when a credential is compromised.
Major section
Biometric error and recovery
Biometric thresholds trade false acceptance against false rejection.
- FAR measures the chance that an impostor is accepted.The false acceptance rate is one side of biometric risk, rather than an equivalent number of password bits.
- FRR measures the chance that a legitimate user is rejected.The false rejection rate shows how an authentication threshold can obstruct real users as well as deter impostors.
- A tighter threshold can reduce false acceptance and increase false rejection.Lower impostor risk can therefore come with more rejected legitimate users, making the chosen threshold a tradeoff.
- A leaked biometric cannot simply be replaced.The chapter treats biometrics as one factor combined with another because recovery is different from changing a compromised password.
Deck summary
Key takeaways
A security review follows the whole access path beyond the successful login.
- Authentication proves identity, authorization limits action, and accounting records outcomes.The pump controller can be recognized yet denied administrator access, with the request and denial preserved for review.
- Credentials must fit capability and support individual revocation.A protected per-device key or certificate can let the team retire one compromised identity without disabling unrelated devices.
- MFA and replay resistance need different kinds of independence.MFA needs different factor categories, while challenge-response needs unique and unpredictable nonces instead of repeated challenges.
- Access control needs secure storage, validation, and a workable lifecycle.Certificate checks, protected keys, automated renewal, and revocation are necessary beyond the single demonstration that a device can log in.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A smart-building controller correctly verifies every user's certificate, but once verified, every user can unlock every door and reconfigure the HVAC. Which control is missing?
Show answer
Answer: A Authentication (certificate verification) is working, but the system does not restrict what each proven identity may do.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A gateway login requires a password plus the answer to a security question. The vendor markets this as multi-factor authentication. What is the correct assessment?
Show answer
Answer: A Both items are knowledge factors, so a single phishing page or breach can capture both.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A challenge-response scheme uses HMAC over a strong 256-bit per-device key, but the verifier reuses the same challenge nonce for every device every hour. Why is this insecure despite the long key?
Show answer
Answer: B Replay resistance depends on the nonce being unique and unpredictable.
Print reference
Answers
Answer key.
- A · Authentication (certificate verification) is working, but the system does not restrict what each proven identity may do.
- A · Both items are knowledge factors, so a single phishing page or breach can capture both.
- B · Replay resistance depends on the nonce being unique and unpredictable.
Print reference
Activity 1 answer
Model answer.
Predict: Authentication succeeds because the identity is proven. Authorization denies the administrator command because the permission is missing. The audit record preserves the request, successful proof, denial, time, and resulting recorded action.
Print reference
Activity 2 answer
Model answer.
Predict: Replay can succeed because the same nonce and device secret produce the same valid response. The attacker does not need to guess the 256-bit key. Challenges must be unique and unpredictable.