DEV Community: Maria Kinyanta

FIDO2 and WebAuthn: How Hardware Turns Authentication Into a Cryptographic Proof

Maria Kinyanta — Sat, 11 Jul 2026 20:38:24 +0000

For decades, authentication on the web has revolved around a shared secret — a password both sides agree to keep. FIDO2 changes the premise entirely. Instead of something you remember, it relies on something you possess: a private key, generated on your device, stored inside its hardware chip, and never transmitted anywhere.

The Problem With Shared Secrets

A password is only as secure as the least secure place it's stored. If the server is breached, the secret is exposed. If the user reuses it across services, a single leak cascades. If it travels over the wire — even encrypted — there is always a moment where it exists outside the device.

The FIDO2 standard, developed by the FIDO Alliance and formalized as WebAuthn by the W3C, was built to eliminate this category of risk. The core idea is that the server should never need to know your credential. It only needs mathematical proof that you hold the corresponding key.

A Key Pair, Not a Password

When you register with a FIDO2-protected service, your device generates an asymmetric key pair: a private key and a public key. The public key is sent to the server and safely stored in the database. The private key stays inside the device's secure hardware enclave (like Apple's Secure Enclave or a TPM chip). This dedicated chip is isolated from the operating system and inaccessible to software running on the device, including the browser.

This represents a fundamental architectural shift. The server holds something it can use to verify you, but not something it could use to impersonate you. There is no credential to steal from the server side — only a public key that is mathematically useless without its private counterpart.

Note: Because the private key is generated on-device and never transmitted, extracting it from the hardware enclave is not a software vulnerability. It would require physical access to the chip itself.

The Authentication Ceremony

Each time you authenticate, the process follows a strict cryptographic sequence:

The server sends a cryptographic challenge — a random, unique value scoped to that specific session.
Your browser passes this challenge to the hardware enclave via the WebAuthn API.
You perform a local gesture: a fingerprint scan, face recognition, or a PIN. This local authentication unlocks the enclave's access to the private key.
The private key signs the challenge. The resulting signature is sent back to the server.
The server verifies the signature using your stored public key. If the math checks out, the request is authorized.

The gesture itself — your fingerprint or your face — never leaves your device. What travels over the network is purely a signed cryptographic response, not biometric data.

Why Biometrics Stay Local

This is an aspect that often causes confusion: FIDO2 uses biometrics purely as a local access control mechanism for the hardware enclave, not as a credential sent over the internet. Face ID or Touch ID simply determines whether the enclave is allowed to sign the challenge. The biometric template itself is processed entirely by the secure chip.

From the server's perspective, it never sees a face, a fingerprint, or any representation of one. It only ever sees an assertion that the correct device, holding the correct private key, authorized the request.

A Standard Built Into the Web

WebAuthn is natively supported in all major browsers and operating systems today. It does not require a plugin, a third-party app, or any additional software. The API is built directly into the browser. This means developers can access it directly via JavaScript, and users interact with it through their device's native unlock prompts — the exact same gestures they use dozens of times a day.

Passkeys, which are the consumer-facing implementation of the FIDO2 standard, follow this exact same underlying protocol. They are designed to be portable and backed up through platform-specific cloud sync, allowing users to authenticate across multiple devices without ever exposing the underlying private key.

Privacy by Design

Because the server only holds a public key, and because each key pair is strictly scoped to a specific domain (the relying party ID), FIDO2 authentication produces no cross-site tracking surface. A key registered on one platform cannot be used on another. There is no shared identifier between services.

When implementing FIDO2 attestation, user identifiers can be fully anonymized before storage, and the attestation chain is verified server-side without retaining any sensitive data. The result is an authentication layer that is inherently GDPR-compliant not because of complex legal configurations, but because of the protocol's physical and mathematical constraints.

Exploring the Implementation

If you are building authentication systems or high-traffic applications, understanding and experimenting with WebAuthn is highly recommended. The shift from behavioral inference to cryptographic proof drastically reduces the attack surface for account takeovers and automated scripts.

To help developers understand the browser-side mechanics of WebAuthn, my team at EMKAY LABS has open-sourced the frontend SDK we use for hardware attestation. You can explore how the browser communicates with hardware-backed authenticators and experiment with incorporating these concepts into your own applications.

RealNode Client SDK (Open Source):
github.com/Emkay-Labs/realnode-client-sdk

Security is rarely about replacing one technology with another. It’s about layering defenses. Hardware-backed authentication offers a powerful tool to strengthen the most sensitive moments of a transaction by shifting trust away from fragile client-side environments and toward verifiable cryptography.

The Myth of Client-Side Security: Why Modern Applications Should Trust Cryptography, Not JavaScript

Maria Kinyanta — Sun, 05 Jul 2026 11:19:47 +0000

In cybersecurity, there's a principle that every engineer eventually learns—often the hard way:

Never trust the client.

Any JavaScript running in a user's browser executes inside an environment fully controlled by that user. Whether it's a CAPTCHA, a tracking script, or a behavioral analysis engine, the browser remains an untrusted execution environment.

A determined attacker can inspect, modify, or replace client-side code, intercept network requests, manipulate runtime variables, and in some cases influence or simulate responses before they reach your backend.

This is precisely why many client-side anti-bot mechanisms eventually become targets for reverse engineering and automated bypasses.

The Illusion of Client-Side Protection

Modern anti-bot solutions often rely heavily on JavaScript executed inside the browser.

Professional attackers, however, use sophisticated headless browsers and automation frameworks capable of:

Intercepting and modifying fetch() and XHR requests
Patching JavaScript functions at runtime
Altering browser variables before they are transmitted
Simulating successful client-side validation
Blocking or rewriting telemetry requests

If your security model ultimately depends on JavaScript reporting that “everything is fine”, then your trust anchor still resides inside an environment controlled by the attacker.

Obfuscation may slow reverse engineering, but it does not establish trust.

A Different Philosophy: Cryptographic Server-Side Validation

At RealNode, we built our architecture around a simple assumption:

The browser is an orchestration layer—not a trust anchor.

The client SDK has only a limited role:

initiating a WebAuthn authentication request
communicating with the device’s hardware-backed authenticator
forwarding the cryptographic response to our infrastructure

The SDK never decides whether a request is legitimate.

That decision belongs exclusively to the server.

The Validation Pipeline

1. Hardware-Backed Authentication

The browser initiates a standard WebAuthn authentication ceremony.

The user's authenticator—such as Apple's Secure Enclave, Windows Hello backed by TPM, or a FIDO2 security key—uses its private key to sign a server-generated challenge.

The private key never leaves the authenticator.

This produces a cryptographic assertion proving possession of the registered key, without exposing any sensitive material.

2. Server-Side Cryptographic Verification

The signed assertion is transmitted to RealNode's edge infrastructure.

Our backend validates:

the signature
the challenge freshness
the registered public key
replay protection
protocol integrity

Only cryptographic evidence is evaluated.

Client-side JavaScript cannot directly influence or alter the outcome of this verification process.

3. Authorization

If all cryptographic checks succeed, the backend issues a signed authorization session.

Otherwise, the request is rejected before reaching sensitive application resources.

The final decision is therefore based on verifiable cryptographic evidence, rather than client-side assertions.

Conceptual Verification Flow

async function verifyAuthentication(clientResponse) {
    const isValid = await cryptoEngine.verify(
        clientResponse.signature,
        clientResponse.challenge,
        publicKey
    );

    if (!isValid) {
        throw new SecurityException("Signature verification failed.");
    }

    return generateServerSignedSession();
}

Although simplified, this illustrates an important architectural principle:

the browser transports evidence—the server establishes trust.

Why Cryptography Changes the Threat Model

Reverse engineering a JavaScript SDK may reveal implementation details, but it does not allow an attacker to generate a valid cryptographic signature without access to the private key securely stored inside the authenticator.

This shifts the security model away from trusting browser behavior and toward verifying mathematical proof.

Instead of asking:

"Did the browser tell us this user is legitimate?"

we now ask:

"Can this request present valid cryptographic evidence?"

That distinction fundamentally changes the attack surface.

Client-Side Validation vs Cryptographic Validation

Client-Side Validation	Cryptographic Server Validation
Browser executes security logic	Browser only transports evidence
JavaScript is part of trust model	JavaScript is never trusted
Easily inspected and modified	Cryptographic proof is verified server-side
Often relies on heuristics	Relies on public-key cryptography
Behavioral assertions	Mathematical verification

Final Thoughts

Client-side code will always remain observable and, to varying degrees, modifiable.

Rather than attempting to make JavaScript impossible to reverse engineer, a more robust approach is to ensure that security decisions are based on evidence that cannot be forged simply by manipulating the browser.

For us, that evidence is cryptographic.

What do you think?

Do you believe client-side obfuscation still provides meaningful protection against modern automated attacks, or should more security-critical decisions be anchored in server-side cryptographic verification?

I'd love to hear your perspective in the comments.

Beyond CAPTCHAs: Exploring Hardware Attestation for High-Demand Ticket Sales

Maria Kinyanta — Tue, 23 Jun 2026 20:24:48 +0000

Managing high-demand ticket sales is a tough job. When a popular event goes live, thousands of people connect at exactly the same moment.

In recent years, the nature of this traffic has changed. Automated scripts—often called scalper bots—have become remarkably fast and sophisticated. They can simulate real browsers, navigate virtual queues within milliseconds, and purchase large numbers of tickets before genuine fans even have time to complete the checkout process.

This creates a significant challenge for ticketing platforms, event organizers, and ultimately the fans themselves.

The Impact on Ticketing Platforms

When automated traffic floods a platform during a major ticket release, several practical problems emerge:

Friction for fans: Genuine buyers often encounter a "Sold Out" message on their very first attempt.
Secondary markets: Tickets rapidly reappear on resale platforms at significantly inflated prices.
Infrastructure stress: During major launches, automated traffic can represent a substantial portion of requests reaching critical application endpoints.
Loss of control: Event organizers lose the ability to ensure tickets reach their intended audience rather than automated purchasing networks.

Traditional Solutions Have Strengths—and Limits

Modern ticketing platforms already employ multiple security mechanisms, each serving an important role within a layered defense strategy.

Web Application Firewalls (WAFs) and IP Filtering

WAFs are highly effective at filtering malicious traffic and mitigating large-scale attacks.

However, sophisticated bot operators increasingly rely on rotating residential proxies, allowing automated traffic to resemble legitimate users connecting from home networks.

CAPTCHAs

CAPTCHAs remain an effective defense against many unsophisticated automated scripts.

However, advances in computer vision, automation frameworks, and modern AI models have significantly improved the ability of software to solve visual challenges. Additionally, CAPTCHAs may introduce friction for legitimate users during time-sensitive checkout experiences.

The point is not that these technologies have become obsolete.

Quite the opposite.

They remain valuable components of a modern security architecture. The challenge is determining what additional verification can be introduced when traffic spikes become particularly aggressive.

Looking Beyond Browser Behavior

One interesting direction is to move away from relying exclusively on browser behavior and instead leverage cryptographic capabilities already present on modern devices.

Most smartphones and computers now include hardware-backed authenticators, such as Apple's Secure Enclave, Windows Hello backed by TPM, or dedicated FIDO2 security keys.

Using standards such as WebAuthn and FIDO2, these authenticators can generate cryptographic assertions proving possession of a previously registered private key without exposing it.

Because these cryptographic operations are performed by the authenticator itself, simply modifying browser-side JavaScript or automating a headless browser is not sufficient to generate a valid cryptographic assertion.

This is the architectural principle behind the system we’ve been exploring in RealNode.

Rather than replacing existing security mechanisms, hardware-backed verification can serve as an additional validation layer during the most critical step of the purchasing process—confirming that the request is backed by a legitimate authenticator before completing a transaction.

Comparing the Approaches

Method	Against Automated Scripts	Impact on Legitimate Users	Scalability
Network & IP Filtering	Effective against many attacks, although residential proxy networks may reduce effectiveness.	Transparent and fast.	High
CAPTCHAs	Effective against many automated scripts, although increasingly challenged by modern automation and AI techniques.	Can introduce friction during time-sensitive checkouts.	High
Hardware-Backed Authentication	Requires valid cryptographic proof produced by a registered authenticator rather than browser-side assertions alone.	Leverages native device authentication and typically completes in well under a second.	Medium–High

Sharing the Code

If you're building or maintaining high-traffic applications, exploring WebAuthn is a worthwhile exercise.

To encourage experimentation, we've open-sourced the frontend SDK used in our implementation. Developers can review the integration, understand how the browser communicates with hardware-backed authenticators, and experiment with incorporating similar concepts into their own applications.

RealNode Client SDK (open source)

If you're interested, feel free to explore the project, open issues, contribute, or simply share your feedback.

Final Thoughts

Security is rarely about replacing one technology with another.

The most resilient systems combine multiple layers of protection, each addressing different classes of attacks.

Hardware-backed authentication is unlikely to replace WAFs, rate limiting, or CAPTCHAs entirely. Instead, it offers another tool that can strengthen the most security-sensitive moments of a transaction by shifting trust away from browser-side behavior and toward cryptographic verification.

I'd love to hear how your team approaches this problem.

How do you currently balance user experience and security during high-demand traffic spikes? Have you experimented with WebAuthn or hardware-backed authentication beyond traditional login flows?