Using WebAuthn as a Cryptographic Proof of Human Presence in Hostile Networks
Introduction: Authentication That Fails in Real Attacks
Most CI/CD systems rely on:
- TOTP codes
- Push notifications
- Long-lived API tokens
These mechanisms fail under modern phishing and malware proxy attacks.
- TOTP can be phished in real time
- Push approvals can be tricked into blind acceptance
- Tokens can be exfiltrated and replayed
These are not theoretical risks.
They are observed attack patterns.
This article explains why FIDO2 (WebAuthn) is categorically different — and why origin-bound hardware authentication is a necessary primitive for high-assurance CI/CD approval flows.
The Limits of TOTP and Push-Based MFA
TOTP and push-based MFA fail for structural reasons.
Key weaknesses:
- The user types a secret into a potentially spoofed interface
- The approval flow can be proxied or relayed by malware
- The second factor is not cryptographically bound to the origin
These mechanisms prioritize usability and compatibility.
They do not provide strong guarantees about where the authentication is happening.
They confirm:
“The user has a factor.”
They do not confirm:
“The user is interacting with the correct system.”
That distinction matters in adversarial environments.
What FIDO2 Actually Guarantees
FIDO2/WebAuthn introduces stronger properties:
- Origin binding: The hardware key signs the TLS origin
- Phishing resistance: The key refuses to sign for mismatched domains
- User presence verification: Physical interaction is required
- No shared secrets: Private keys never leave the device
This creates a cryptographic guarantee:
A human physically interacted with a hardware token
at a specific origin
at a specific moment
That is fundamentally different from traditional MFA.
Origin Binding and DNS Hijacking
Consider a DNS hijacking or phishing scenario.
With TOTP:
- User is redirected to attacker-controlled domain
- User enters credentials + TOTP code
- Attacker relays the code in real time
- Authentication succeeds
The system sees valid credentials.
The attack works.
With FIDO2:
- User is redirected to attacker-controlled domain
- Browser requests WebAuthn signature
- Hardware key checks origin
- Origin mismatch detected
- Key refuses to sign
Authentication fails cryptographically.
No user judgment required.
No warning needed.
The attack is structurally blocked.
This is not a UI improvement.
It is a protocol-level guarantee.
Hardware-Backed Keys vs Software Authenticators
Not all WebAuthn implementations are equal.
Software authenticators (e.g., OS-level passkeys):
- share trust with the host system
- may be influenced by host compromise
Hardware-backed keys:
- store private keys inside secure elements
- require physical presence
- resist extraction and tampering
This matters in hostile environments.
If the host is compromised, software-based authenticators may inherit that risk.
Hardware keys introduce a separate trust boundary.
That is the point.
Integrating FIDO2 into CI/CD Approval Flows
FIDO2 can be used as a primitive in CI/CD systems to:
- gate deployment approvals
- require per-action authentication
- bind approval to specific commit hashes
- prevent replay of authorization tokens
This changes the role of authentication.
From:
verifying identity
To:
verifying intent at the moment of action
Each deployment becomes a discrete, cryptographically verified event.
Not a continuation of a session.
From Authentication to Intent Verification
Traditional authentication answers:
Who is this?
FIDO2 enables systems to ask:
Did this human physically approve this specific action right now?
That is a stronger question.
And a more relevant one in CI/CD systems where:
- sessions are long-lived
- tokens are reused
- actions are high-impact
FIDO2 enables per-action authorization grounded in human presence.
Performance and Usability Trade-offs
Hardware-backed authentication introduces friction:
- physical interaction
- device handling
- initial setup overhead
But the performance cost is small:
- typically a few hundred milliseconds to a few seconds
The security benefit is large:
- elimination of phishing-based MFA bypass
- resistance to real-time relay attacks
- removal of shared secrets
This is an asymmetric trade-off:
Small usability cost
Large security gain
Threat Model Boundaries
FIDO2 is powerful, but not complete.
It does not solve:
- physical theft combined with PIN compromise
- coercion of the operator
- UI deception on a compromised host
- approval context manipulation on the same device
That is why FIDO2 should not be used in isolation.
It must be combined with:
- physical trust separation (e.g., isolated approval terminals)
- contextual verification
- governance controls
FIDO2 is necessary.
It is not sufficient on its own.
Conclusion: Hardware-Bound Intent Beats Software MFA
TOTP and push-based MFA are convenience mechanisms.
They improve security compared to passwords alone.
But they remain vulnerable to modern attack techniques.
FIDO2 changes the model.
It replaces:
- shared secrets
- user-entered codes
- UI-driven approval
With:
- hardware-backed cryptography
- origin-bound verification
- physical presence requirements
High-assurance CI/CD systems should treat origin-bound hardware authentication not as an optional upgrade…
…but as a foundational primitive.
Because in adversarial environments:
Identity is easy to simulate.
Physical, origin-bound intent is not.
