通常，密码不存储在 cookie 中。您使用您的用户名和密码登录到 example.com，这些被验证属于您（通常通过散列您的密码并检查您的密码的散列与具有该用户名的用户的散列匹配），然后服务器向您发出长随机数令牌作为您的秘密标识符。

假设他们从 62 个字符（26 个大写字母、26 个小写字母、10 个数字）中选择 24 个随机字符。他们将此标识符存储在他们的数据库中，因为它是有效的并与您相关联。每次您在登录时提出请求 - 您都会将 cookie 发送到您的网站。每次使用此标识符发送请求时，他们都会查找它是否与有效的登录用户相关联，如果是，他们会提供有关该用户的信息。

有 62 ²⁴ ~ 10 ⁴³ ~ 2 ¹⁴²种可能性。如果您的网站在任何时候都有十亿 (10^9) 的登录用户获得了令牌，那么您将不得不尝试大约 10^37 种可能性，直到您有幸随机猜到一个。（如果每次尝试需要 1 纳秒，那么您将需要大约¹⁰¹¹⁰亿年才能幸运地猜到一个有效的令牌）。

您的会话 cookie 通常仅在一定时间内有效，该时间也将存储在服务器端数据库中。

这个主题还有其他变体，例如，使用 HMAC（哈希消息验证码）和基于服务器端秘密的存储时间戳。也就是说，当您登录服务器时，服务器会为您提供时间戳以及该时间戳的强哈希以及与服务器端密码相结合的用户名。也就是说，您在登录时服务器会计算 h=HMAC(secret + timestamp + username)，然后将计算出的 h 返回给您——然后您将（h、用户名和时间戳）作为登录信息发送。（并且服务器获取您的用户名和时间戳，重新计算 h 并将其与您提供的 h 进行比较，并确保时间戳仍然有效并且不是很旧）。

现在我并不是特别熟悉 stackexchange 是如何做的（例如， 的t=...&s=....部分.security.stackexchange.com），但它可能是这个方案的一个变体。也就是说，它不会以可恢复的方式加密您的用户名或密码——它要么存储在数据库中，要么基于依赖于服务器端机密的单向哈希函数。