security - 如何使用 HTTP 基本身份验证解决密码哈希复杂性？

Question

密码哈希存储为 PBKDF2，512 位，16384 轮。这在我的小型服务器上需要时间。用户被授权使用基于 SSL/TLS 的 HTTP 基本身份验证。使用此设置，每个请求都需要计算哈希值，这会给服务器带来负载。

当前的解决方案:在第一次成功登录后，我在客户端存储一个 session cookie。

优点:减少哈希计算时间的最小复杂度，仍然适用于不存储 cookie 的客户端

缺点:不接受 cookie 的客户端仍然会产生负载。

其他缓解方法: - 弱化密码散列(感觉不对) - 实现自己的/其他身份验证而不是基本身份验证(哪一个？增加复杂性)

优先事项: 安全第一，访问管理/监控是安全的。 然后服务器加载。

如何减轻密码散列负载？如何不牺牲安全性？是否有没有安全通道(共享 key )的身份验证替代方案？

Answer 1

Current solution: After the first successful login I store a session cookie at client.

这是典型的解决方案——要么使用实际存储的 session ，要么使用签名的用户+时间戳 token (HMAC 比 bcrypt 验证速度更快)。

它还解决了 HTTP Auth 仅针对与请求身份验证的第一页位于同一目录路径下的页面发送的问题，以及疯狂的浏览器在每次出现 401 提示时才重新发送身份验证 header 的问题请求。

Cons: Clients that do not accepts cookies still create load.

完全不接受 cookie 的客户端相对较少，几乎所有其他需要登录的站点都会中断，因此对于常见情况，您通常应该没问题。

Implement own/other authentication instead of basic auth (which one? adds complexity)

如果您决定不依赖 cookie，我能想到的唯一支持 native 浏览器的其他机制是 Digest Auth(并没有真正解决问题，因为它仍然是基于密码的)和 HTTPS 客户端证书(可能是一个可接受的/方便的选项，具体取决于您的用户群)。