Identity

Cybersecurity / 18 Sep 2026 / 6 min read

UNIX Socket Peer Credentials Bind Local IPC to Kernel-Observed Identity

A privileged local daemon accepts a request over an AF_UNIX socket and needs to decide whether the sender may perform an operation. Trusting a UID, PID, or account name encoded inside the request merely trusts data supplied by the client. Linux provides a different identity channel: the kernel can expose credentials associated with the peer or with an individual message. SO_PEERCRED and SCM_CREDENTIALS both carry a struct ucred, but they describe different moments in an IPC relationship. Treating them as interchangeable can turn a sound local authorization boundary into a stale-identity assumption.

Cybersecurity Linux

Cybersecurity / 18 Sep 2026 / 6 min read

pidfds Bind Process Operations to Stable Kernel References

A supervisor records PID 4127, performs unrelated work, then sends a signal to 4127. Between those steps, the original process can exit and the kernel can eventually assign the same numeric PID to another process. The integer still names a process, but not necessarily the process that the supervisor intended to affect. Linux PID file descriptors, commonly called pidfds, move that boundary from repeated numeric lookup to a file descriptor that refers to a particular task. That change is narrow but security-relevant: operations that accept a pidfd can stay bound to the task selected when the reference was acquired rather than resolving a reusable number again.

Cybersecurity Linux

Cybersecurity / 17 Sep 2026 / 7 min read

Unix Socket Peer Credentials Bind Identity to a Local Connection

Unix Socket Peer Credentials Bind Identity to a Local Connection A privileged local service often accepts requests from processes that share the same host but do not share the same authority. A pathname on a Unix domain socket can control who reaches the listener, yet a successful connection does not by itself tell the service which process is on the other end. Linux provides a second boundary: SO_PEERCRED lets a connected Unix socket expose peer credentials supplied by the kernel.

Cybersecurity Linux

Cybersecurity / 17 Sep 2026 / 10 min read

Mutual TLS Identity Can Disappear at a Terminating Proxy

Mutual TLS Identity Can Disappear at a Terminating Proxy A service can require a client certificate at its public endpoint, accept only certificates chained to an approved authority, and still deliver an unauthenticated request to the application behind it. The TLS check may be completely correct. The gap appears when a reverse proxy terminates that TLS connection and opens a different connection to the backend. Mutual TLS authenticates endpoints of a particular TLS connection. It does not automatically attach the authenticated client identity to HTTP requests after that connection ends, and it does not cause a second TLS connection to inherit the first connection’s peer. Once a proxy becomes the TLS server for the external client, the proxy is the component that possesses the verified client-certificate result. Any backend identity derived from that result crosses a new trust boundary.

Cybersecurity TLS

Cybersecurity / 16 Sep 2026 / 9 min read

Client Certificate Headers Move mTLS Identity Into the Proxy Trust Boundary

A service can require mutual TLS at its public edge and still have no TLS client certificate at the application server. The client proves possession of its private key to the TLS-terminating reverse proxy; the proxy then opens a separate connection to the origin. Unless certificate information is carried across that second hop, the origin cannot directly inspect the credential authenticated on the first connection. Forwarding the certificate in an HTTP field solves the transport problem but changes the security boundary. The origin is no longer consuming identity evidence directly from its own TLS handshake. It is consuming a statement made by an intermediary about a different handshake.

Cybersecurity TLS

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 / 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 / 13 Sep 2026 / 8 min read

JWT Verification Must Bind Algorithm, Key, and Issuer

JWT Verification Must Bind Algorithm, Key, and Issuer A signed token can be cryptographically valid and still be unacceptable to the service receiving it. The signature answers a narrow question: the token bytes match a signature produced with a particular cryptographic key under a particular algorithm. Authorization depends on a larger set of facts, including who controls that key, which issuer is trusted, which audience the token targets, and which algorithms the application intended to accept.

Cybersecurity Authentication

Cybersecurity / 09 Sep 2026 / 9 min read

Design User Identifiers to Resist Visual Spoofing

Two account identifiers can be different to software while looking almost identical to a person. That gap matters anywhere people use a displayed identifier to decide whom they are trusting: administrator consoles, collaboration tools, package registries, marketplaces, support systems, or internal approval workflows. If an application treats visual appearance as irrelevant, an attacker may be able to register an identifier that resembles a trusted account closely enough to mislead another user. The database still sees two distinct strings. The human may not.

Cybersecurity Secure Design