Few people realize that, for IT security, an authentication should deliver more than a verdict—pass or fail. The very terms we use—login, sign‑in, authentication, verification—frame the process as a decision that ends in a verdict. But a verdict alone doesn’t secure anything.
Endpoint reality: authentication must unlock
Consider your endpoint—the device (PC or phone) you use to work and access the internet and network resources. A secure design must address a few essentials:
- The device’s data must be protected (securely encrypted). An attacker can have the endpoint in their possession and try to read raw data on disk—or even in memory if the device is powered on.
- The encryption key must not be available before user login. Hiding the key “somewhere only R&D knows” is obscurity, not security.
- Therefore, for endpoints and “data at rest,” login/authentication must deliver a secret—a key—that the endpoint does not have before login.
For endpoints, we call this unlock. The key recovered at login is typically not the data‑encryption key itself; rather, it may unlock a key file, which unlocks key‑encrypting keys (KEKs), and so on—eventually reaching the disk‑sector encryption key. The important part is the transformation: no key, no use.
Online reality: authentication must enable
Unlocking doesn’t apply to online authentication because the server is fully operational at login time. In theory, a login could unlock user data on the server, but that’s uncommon. Also, the key that protects online data—the session or transaction—is typically (and correctly) new, not an existing key.
Here’s the problem: unlike data at rest, the notion that online authentication must yield a key is far less recognized. Most familiar online user authentication methods—push approvals, OTP codes, even FIDO—do not include a step that sets the cryptographic key for what follows. TLS does create keys, but TLS is not the user’s login; it happens beforehand and isn’t the user authentication we’re discussing.
When authentication stops at verdict, a gap opens: we decide who the user is, but we don’t make that decision produce the key that protects the ensuing exchange. Attackers exploit that gap, for example with adversary‑in‑the‑middle (AiTM) campaigns that relay the user’s sign‑in to the real site and then continue the exchange over the already‑established connection that sat outside the authentication step.¹
The fix is simple to state:
Online, the act of authentication must produce the cryptographic key that protects what comes next.
Not a verdict alone. A key—as the output of authentication.
A brief note on precedent
There is already a real‑world acknowledgment that authentication should yield a secret. Windows sign‑in/unlock with FIDO2 security keys relies on a FIDO extension (hmac‑secret) so that the authentication ceremony produces a secret usable by Windows logon—including cases where the machine isn’t online. Microsoft documents FIDO2 key sign‑in for Windows, exposes hmac‑secret in its WebAuthn platform APIs, and vendors describe hmac‑secret precisely as a way to obtain a secret for encrypt/decrypt operations.2, 3, 4
The takeaway is not the extension itself; it’s the principle it serves: authentication should yield the key.
The best solution is the simplest—just not simpler
- Simpler, but not enough: Doing authentication without setting the key is simpler—but insufficient. It leaves a gap between identity and protection, which adversaries exploit.¹
- Principle first: Making authentication yield the key is simpler than patches. It unifies “who you are” with “what protects the exchange” in one step.
- Not the (over‑)simplest: Building layers of hardening around a verdict‑only model isn’t the “simplest” in the Einstein sense—and it can still be bypassed by attackers who live between the user and the server.¹
One rule, two domains:
- Endpoint: authenticate → unlock (recover an existing key).
- Online: authenticate → enable (create the key for the exchange).
If a key didn’t come from authentication, it isn’t security—it’s ceremony.
References
- Microsoft Security Blog — adversary‑in‑the‑middle campaigns and impacts.
https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/ - Microsoft Learn — FIDO2 security key sign‑in to Windows (how Windows supports key sign‑in).
https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-security-key-windows - Microsoft Win32 WebAuthn API — HMAC‑Secret structures/constants (platform support).
https://learn.microsoft.com/en-us/windows/win32/api/webauthn/ns-webauthn-webauthn_hmac_secret_salt
https://learn.microsoft.com/en-us/windows/win32/webauthn/webauthn-constants - Yubico — FIDO2 hmac‑secret explanation (purpose and usage).
https://docs.yubico.com/yesdk/users-manual/application-fido2/hmac-secret.html
