Authentication

Cybersecurity / 21 Sep 2026 / 5 min read

WebAuthn RP ID Scopes Credential Use

WebAuthn RP ID Scopes Credential Use A WebAuthn credential is not a reusable key that any website can request from an authenticator. Registration and authentication are tied to a relying party identifier, or RP ID, while the browser also evaluates the calling origin. That pairing creates a domain boundary around public-key credentials. For a conventional deployment at https://login.example.com, an RP can use the host itself as the RP ID: origin: https://login.example.com RP ID: login.example.com It can also use a registrable domain suffix such as example.com when the deployment needs credentials to serve eligible subdomains:

Cybersecurity WebAuthn

Cybersecurity / 21 Sep 2026 / 6 min read

SSH Host Key Verification Binds Connections to Server Identity

SSH Host Key Verification Binds Connections to Server Identity SSH encrypts a connection, but encryption alone does not establish that the endpoint is the intended server. During key exchange, the server proves possession of a host private key. The client then has to decide whether the corresponding public identity is trusted for that host. That decision is the host-authentication boundary. If a client accepts an attacker’s host key without a valid trust basis, the resulting channel can still be encrypted while terminating at the wrong machine. Passwords, commands, forwarded agents, and session data can then cross a boundary the operator did not intend.

Cybersecurity SSH

Cybersecurity / 21 Sep 2026 / 6 min read

SSH Certificates Bind Identity to Principals and Constraints

SSH Certificates Bind Identity to Principals and Constraints A raw SSH public key answers a narrow question: does the connecting client possess the private key corresponding to this public key? Authorization still needs another mapping. A server commonly places accepted keys in authorized_keys, often with options that restrict what a particular key may do. OpenSSH certificates add a signed identity layer around a public key. A certificate can carry principals, a validity interval, critical options, extensions, a serial number, and a key identifier. A server configured to trust the signing CA can validate that certificate without storing the holder’s raw public key as a separate authorization entry.

Cybersecurity SSH

Cybersecurity / 21 Sep 2026 / 6 min read

Mutual TLS Authenticates Both Sides of a Connection

Mutual TLS Authenticates Both Sides of a Connection A conventional HTTPS connection authenticates the server with a certificate while the client usually proves its identity later through an application mechanism such as a session cookie, bearer token, or password. Mutual TLS, commonly shortened to mTLS, adds certificate-based client authentication to the TLS exchange. The result is a transport channel in which each peer can verify a certificate chain and proof of private-key possession from the other side. That changes the authentication boundary, but it does not turn a certificate into an authorization policy. A valid client identity can still be denied access to a resource.

Cybersecurity TLS

Cybersecurity / 20 Sep 2026 / 6 min read

Session ID Rotation Closes the Pre-Authentication Session Gap

Session ID Rotation Closes the Pre-Authentication Session Gap A web application can assign a session before a user signs in. That anonymous session may hold a CSRF token, locale, shopping state, or other temporary data. Authentication changes the authority attached to the session: the server now treats requests carrying that session as belonging to an identified account. If the application keeps the same session identifier across that transition, a value established before authentication can become the handle for an authenticated session. Session fixation attacks target that continuity. The defensive boundary is the authentication event itself: preserve only the state that should survive, issue a fresh unpredictable identifier, and retire the old identifier.

Cybersecurity Authentication

Cybersecurity / 20 Sep 2026 / 6 min read

Password Reset Links Need a Trusted Public Origin

Password Reset Links Need a Trusted Public Origin A password reset email often contains one of the most sensitive URLs an application creates. Possession of a valid reset token may be enough to establish a new credential for the associated account, so the destination embedded in that URL is part of the security boundary. A common implementation mistake is to construct the absolute reset URL from host information carried by the incoming HTTP request. Headers such as Host exist for request routing, and deployments behind proxies may also expose forwarded host or scheme metadata. Unless the application has explicitly established which intermediary is trusted and which values are valid, that request metadata is not a safe source of authority for a security-sensitive outbound link.

Cybersecurity Authentication

Cybersecurity / 20 Sep 2026 / 6 min read

JWT Audience Checks Keep Tokens Inside Their Intended Service Boundary

JWT Audience Checks Keep Tokens Inside Their Intended Service Boundary A valid JSON Web Token signature proves a narrow fact: the token bytes were signed with a key accepted by the verifier and were not modified afterward without invalidating that signature. That result does not establish that the token was issued for the service currently receiving it. This distinction matters in systems where one authority issues tokens for several APIs, or where multiple authorities use keys that an application can reach through configuration. A token can be cryptographically valid yet belong to a different security context. The iss and aud claims give the verifier inputs for enforcing that boundary.

Cybersecurity JWT

Cybersecurity / 19 Sep 2026 / 6 min read

WebAuthn Signature Counters Are Clone Signals, Not Identity Proofs

WebAuthn Signature Counters Are Clone Signals, Not Identity Proofs A relying party can verify a valid WebAuthn assertion and still receive a counter value that adds no useful evidence about credential cloning. The signature proves possession of the credential private key for the signed assertion. The signCount field has a narrower role: when an authenticator maintains a usable signature counter, changes in that value can give the relying party evidence that the same credential may be active in more than one place.

Cybersecurity WebAuthn

Cybersecurity / 19 Sep 2026 / 6 min read

WebAuthn Signature Counters Are a Clone Signal, Not a Session Guarantee

A WebAuthn assertion can carry a valid signature and still present an operational anomaly: its signature counter is not greater than the value stored after an earlier successful assertion. That condition is useful, but it is not equivalent to proof that a private key was copied, and it does not make the counter a replay-prevention mechanism. The signCount field sits inside authenticator data. A relying party receives that authenticator data as part of an assertion and verifies it together with the client data and signature. The counter can give the relying party evidence about authenticator state across successful ceremonies. Its security value depends on the authenticator’s counter behavior and on the relying party retaining the prior value correctly.

Cybersecurity WebAuthn

Cybersecurity / 19 Sep 2026 / 7 min read

SSH Host Key Continuity Is a Client Trust Boundary

SSH Host Key Continuity Is a Client Trust Boundary An SSH connection can negotiate strong encryption and still authenticate the wrong server. Encryption protects the transport after key exchange establishes its cryptographic context; it does not independently tell a client that the server key belongs to the intended host. That identity decision rests on host-key verification. For many interactive clients, the visible artifact is a known_hosts entry. The deeper security property is continuity: a client needs a trustworthy basis for accepting a host key now and for deciding whether a different key later represents legitimate rotation or an unexpected endpoint.

Cybersecurity SSH

Cybersecurity / 19 Sep 2026 / 6 min read

PASETO Public and Local Tokens Do Not Solve Session Revocation

A PASETO token can protect claims cryptographically without knowing whether the user has logged out. That boundary matters more than the usual JWT-versus-PASETO comparison: changing the token format does not create session revocation. PASETO gives each token an explicit version and purpose. With Version 4, v4.public signs a message with Ed25519, while v4.local encrypts and authenticates a message with symmetric cryptography. Those choices determine who can read a token and who can create or verify it. They do not determine whether a previously valid token should still be accepted after a session changes.

PASETO Authentication

Cybersecurity / 19 Sep 2026 / 6 min read

ESP32 MQTT over TLS: Transport Encryption and Broker Authentication Are Separate

An ESP32 that moves an MQTT connection from port 1883 to 8883 crosses more than a port boundary. The TCP stream is now expected to carry MQTT inside TLS. Data in transit is protected only when the TLS client also validates the broker certificate. MQTT username/password authentication is separate: credentials identify the client to the broker, while certificate validation identifies the broker to the ESP32. Calling this “MQTT with HTTPS” mixes two application protocols. MQTT does not become HTTP when TLS is added. MQTT can run over plain TCP or over a TLS-protected TCP connection.

ESP32 MQTT

Go / 19 Sep 2026 / 7 min read

Email OTP in Go: Single-Use Codes, Expiration, and Replay Protection

Email OTP in Go: Single-Use Codes, Expiration, and Replay Protection An email OTP looks simple: generate six digits, send them, and compare what the user types. The security boundary is not the email API, though. It is the server-side challenge lifecycle. A correct implementation has to make the code unpredictable, expire it quickly, limit guesses, invalidate older challenges when appropriate, and guarantee that a successful code cannot be consumed twice. Those properties are different from TOTP, even though both mechanisms are commonly described as OTP.

Golang OTP

Cybersecurity / 16 Sep 2026 / 9 min read

WebAuthn RP IDs Bind Credentials to Domain Scope, Not a Single Origin

WebAuthn RP IDs Bind Credentials to Domain Scope, Not a Single Origin An authentication service at https://login.example.com can create a WebAuthn credential scoped to example.com rather than only to its own host. That choice permits eligible sibling origins under the same domain to request use of the credential, yet an assertion still carries the calling origin for server-side validation. WebAuthn deliberately separates these two identities. The split solves a practical architecture problem: one relying party can operate across multiple web origins without issuing an unrelated credential for every host. It also creates a security boundary that is easy to flatten incorrectly. The RP ID controls credential scope at the client and authenticator layers; the origin identifies the web context that initiated a ceremony. Treating either value as a substitute for the other can expand authentication authority beyond the intended deployment.

Cybersecurity WebAuthn

Cybersecurity / 15 Sep 2026 / 7 min read

WebAuthn Signature Counters Are Clone Signals, Not Authentication Proof

Two valid WebAuthn assertions for the same credential arrive close together. One carries a signature counter of 42 and the other carries 41. Both signatures verify. The relying party now has evidence that deserves attention, but it does not have cryptographic proof that the second assertion came from an attacker. That distinction is built into WebAuthn’s signature-counter model. The counter is auxiliary state intended to help detect cloned authenticators. It is not part of the primary decision that establishes possession of the credential private key, and some authenticators legitimately keep it at zero.

Cybersecurity WebAuthn

Cybersecurity / 15 Sep 2026 / 7 min read

WebAuthn Credentials Bind Authentication to Web Origins

WebAuthn Credentials Bind Authentication to Web Origins A convincing sign-in page can copy logos, typography, form layout, and even the timing of an authentication flow. Passwords offer little resistance to that imitation because the secret is portable: a person can type the same password into the legitimate site or into a hostile page that looks identical. WebAuthn changes the property that matters. Its public-key credentials are scoped to a relying party, and the browser contributes origin context to each ceremony. An attacker can reproduce the appearance of a sign-in page, but cannot simply move a WebAuthn assertion from an unrelated web origin into the legitimate relying party’s authentication flow.

Cybersecurity WebAuthn

Cybersecurity / 15 Sep 2026 / 7 min read

SSH Host Key Pinning Turns First Contact Into a Persistent Trust Decision

SSH Host Key Pinning Turns First Contact Into a Persistent Trust Decision An SSH client can negotiate strong encryption with the wrong server. The cryptographic channel may be intact while an active intermediary terminates one SSH connection and creates another, unless the client has a reliable basis for authenticating the server’s host key. OpenSSH addresses that boundary with host key verification. A client records or otherwise obtains trusted host key material and checks the key presented during later connections. This converts server identity from a property inferred from network routing into a cryptographic comparison anchored in local or externally authenticated state.

Cybersecurity SSH

Cybersecurity / 15 Sep 2026 / 8 min read

Mutual TLS Moves Service Identity Into the Handshake

A service accepts HTTPS only from a small set of internal workloads. Server-side TLS protects the channel and authenticates the server, but any client able to reach the listener can still start a connection. An API token can authenticate the caller after the TLS session exists, yet that design places client identity above the transport boundary and creates another bearer credential to distribute. Mutual TLS, commonly shortened to mTLS, changes that boundary. The server requests a client certificate during the TLS handshake, validates the presented certificate according to its configured trust policy, and requires cryptographic proof that the peer controls the corresponding private key. The resulting connection can carry an authenticated client identity before application data is accepted.

Cybersecurity TLS

Cybersecurity / 15 Sep 2026 / 8 min read

JWKS Rotation Makes Cache Lifetime Part of Token Verification

A service receives a valid JWT seconds after its issuer rotates signing keys. The token carries a new kid, but the verifier still has the previous JWK Set in cache. Signature verification cannot even begin with the correct public key until the verifier obtains a set containing that identifier. This is a routine rollover condition, not a cryptographic break. Yet it exposes an important boundary in distributed token validation: a verifier that obtains public keys remotely depends on cache behavior and key publication timing alongside the signature algorithm itself.

Cybersecurity JWT

Cybersecurity / 14 Sep 2026 / 9 min read

WebAuthn Makes the Site Part of the Authentication Proof

A phishing page can reproduce a login screen with near-perfect visual fidelity. It can copy logos, spacing, prompts, and even the sequence of an identity provider’s screens. With a password, visual imitation can be enough: the secret typed into the counterfeit page is still a valid secret at the real service. WebAuthn changes that exchange by making site identity part of the cryptographic operation. An authenticator does not merely produce a reusable answer after a person approves a prompt. It signs data associated with the relying party and with a browser-mediated ceremony. A credential registered for one relying party is not a general credential that another site can present unchanged.

Cybersecurity WebAuthn

Cybersecurity / 14 Sep 2026 / 7 min read

WebAuthn Binds Credentials to a Web Origin

A convincing imitation of a login page can reproduce almost every visible detail of the original site. It can copy the logo, typography, form layout, error messages, and even the sequence of prompts. Password authentication gives that imitation a useful target: a secret that a person can type into the wrong origin and an attacker can relay or reuse elsewhere. WebAuthn changes that property. Its credentials are public-key pairs scoped to a relying party, and authentication produces a signed assertion tied to data supplied by the site and context supplied by the browser. The credential is not a reusable string exposed to the page. That difference moves a large part of phishing resistance from visual recognition into protocol enforcement.

Cybersecurity Web Security

Cybersecurity / 14 Sep 2026 / 6 min read

Rotate Session Identifiers Across Authentication Boundaries

Rotate Session Identifiers Across Authentication Boundaries A login endpoint can validate credentials perfectly and still hand an attacker an authenticated session. The failure appears when the application keeps the same session identifier before and after authentication, allowing an identifier established under anonymous conditions to survive a major increase in authority. That pattern is session fixation. It differs from session theft in an important respect: the attacker does not need to extract a secret identifier from an authenticated browser. Instead, the attacker arranges for a known identifier to become associated with a victim’s authenticated state. Once the victim signs in, possession of that already-known identifier may be enough to access the resulting session.

Cybersecurity Session Security

Cybersecurity / 14 Sep 2026 / 7 min read

PKCE Binds an OAuth Code to the Client That Started the Flow

An OAuth authorization code can pass through a browser, an operating-system URL dispatcher, a custom application scheme, or an application link before it reaches the client that requested it. That route is convenient, but it also means possession of the returned code is not always strong evidence that the intended client received it. Proof Key for Code Exchange, usually called PKCE, changes the value of an intercepted code. Before starting the authorization request, the client creates a high-entropy secret called the code verifier. The authorization server receives a derived code challenge with the request and later requires the original verifier when the code is exchanged for tokens. A party that captures only the authorization code lacks the second value needed to complete the exchange.

Cybersecurity OAuth

Tech / 14 Sep 2026 / 6 min read

Passkeys Bind Sign-In Credentials to Site Domains

Passwords are portable by design. A person can type the same secret into a legitimate service, a lookalike page, or an unrelated application. That flexibility is convenient, but it also gives phishing pages a chance to collect credentials that can later be replayed against the real service. Passkeys change the shape of sign-in. Instead of sending a reusable secret to a server, a device proves possession of a private key. The matching public key is stored by the service, while the private key remains under control of the user’s authenticator or credential provider.

Tech Passkeys