密码哈希存储为 512 位 16384 轮的 PBKDF2。这需要在我的小型服务器上花费时间。用户通过 SSL/TLS 获得 HTTP 基本身份验证。使用此设置，每个请求都需要计算给服务器带来负载的哈希值。
当前解决方案：第一次成功登录后，我在客户端存储了一个会话 cookie。
优点：减少哈希计算时间的最小复杂性仍然适用于不存储 cookie 的客户端
缺点：不接受 cookie 的客户端仍然会产生负载。
其他缓解方法： - 弱化密码哈希（感觉不对） - 实施自己/其他身份验证而不是基本身份验证（哪一个？增加了复杂性）
优先事项：安全第一，管理/监控的访问是安全的。然后服务器加载。
如何减轻密码哈希负载？如何不牺牲安全？是否有没有安全通道（共享密钥）的身份验证替代方法？
当前解决方案：第一次成功登录后，我在客户端存储了一个会话 cookie。
这是典型的解决方案——要么使用实际存储的会话，要么使用签名的用户+时间戳令牌（HMAC 的验证速度比 bcrypt 快）。
它还解决了 HTTP Auth 仅针对与请求身份验证的第一个页面位于同一目录路径下的页面发送的问题，以及在每次请求都提示 401 之前不会重新发送身份验证标头的疯狂浏览器的问题。
缺点：不接受 cookie 的客户端仍然会产生负载。
根本不接受 cookie 的客户端相对较少，并且会在几乎所有其他需要登录的站点上中断，因此对于常见情况，您通常应该没问题。
实施自己/其他身份验证而不是基本身份验证（哪一个？增加了复杂性）
如果您决定不依赖 cookie，我能想到的支持本机浏览器的唯一其他机制是 Digest Auth（并不能真正解决问题，因为它仍然是基于密码的）和 HTTPS 客户端证书（可能是可以接受的） /convenient 选项取决于您的用户群是谁）。