Protecting credentials and messages

Ava's password proves useful at sign-in because the service treats it as evidence of control. Once she signs in, a session cookie may let her keep using the application. A token may let an application call an API. Each value matters because another system is prepared to accept it.

Protecting identity means following that evidence through its lifetime: how it travels, where it is stored, who can read it, and when it stops working. Protecting the password while exposing the session cookie would leave another route into the same account.

Some evidence is weak before it is ever used. Billions of passwords from past breaches circulate in published lists, and attackers try those email and password pairs at other services, counting on people who reused them. This is credential stuffing. A password that appears in those lists offers little protection however long it is, so a careful service compares a new password against known breached passwords and refuses a match.

When Ava sends her password, HTTPS protects the connection using TLS. The browser checks the server's certificate for the hostname and the applicable trust requirements, and the protocol establishes the protected connection.

Keys explain how that check works. The certificate contains the server's public key, and the certificate authority signs the certificate, binding that public key to the hostnames it names. The browser verifies the authority's signature with a public key it already trusts. Together, the authorities, their certificates and the rules for issuing them make up a public key infrastructure, or PKI, that lets the browser connect the server's public key to the hostname it requested. The server must also prove possession of the corresponding private key during the TLS exchange. That private key is the secret that never leaves the server, described in Clients, servers, and addresses.

That protects the journey to this server. It does not establish that the site is honest, that Ava chose the right hostname, or that the server stores her password safely after receiving it.

A service normally does not need to recover Ava's password later. It needs to check whether a new submission matches. A password hashing scheme stores a verifier derived from the password, using a unique salt and deliberately costly computation to make guessing more expensive.

Some secrets do need to be recovered or used later, such as a secret an application uses to call another service, or a private signing key. They need storage with tightly controlled access and suitable encryption or key protection. Hashing a value is not a substitute when the service must use the original.

The same care applies to ordinary troubleshooting. A password, session cookie, recovery code, or token copied into a log or screenshot has become another copy to protect. Useful logs record what happened and why without recording the credential itself.

An application receives a token and decodes it. It can now read an account identifier, an issuer, and an expiry time. That is a useful inspection step, but the token is still just input.

Before accepting it, the recipient must validate the protection and the rules for this token type. Depending on the protocol, that includes the expected issuer, intended audience, allowed algorithm and trusted key, lifetime, and connection to the request. A valid signature alone does not make a token suitable for every recipient or purpose.

The JWT format from Keys, encryption, and signatures is one way these fields are carried. A signed JWT is commonly readable; encryption is a separate choice. Treating its encoded appearance as secrecy, or its decoded contents as verified facts, misses the protection it actually provides.

Imagine someone obtains a bearer token. If possession is enough to use it, they may be able to replay it, presenting the same token again, until the recipient stops accepting it. Short lifetimes limit that window, while revocation, cancelling a credential before it would expire, can end some credentials earlier when the system supports it.

Other designs bind a token to a key the client holds. The client must prove it has that key each time it presents the token, so a copied token alone is insufficient. That adds a different protection; it does not remove the need for expiry, validation, and careful handling.

When a token expires, an inspection tool may still display its text. Expiry changes whether a recipient should accept it, not whether the bytes remain readable.