如何通过HTTP基本身份验证解决密码哈希复杂性？
密码散列作为PBKDF2存储，512位，16384轮。 这需要我的小型服务器上的时间。 用户通过SSL / TLS进行HTTP基本认证。 通过这个设置，每个请求都需要计算出在服务器上加载负载的哈希。
当前的解决方案：在第一次成功登录后，我在客户端存储会话cookie。
Pro：减少散列计算时间的复杂度最小，对于不存储cookie的客户端仍然适用
缺点：不接受cookies的客户端仍然会产生负载。
其他缓解方法： - 减弱密码散列（感觉不对） - 实施自己/其他认证而不是基本认证（哪一个？增加了复杂性）
优先事项：安全第一，获得管理/监督是安全的。 然后服务器加载。
如何缓解密码哈希加载？ 如何不牺牲安全性？ 没有安全通道（共享密钥）的情况下是否有认证的替代方案？
当前的解决方案：在第一次成功登录后，我在客户端存储会话cookie。
这是典型的解决方案 - 使用实际存储的会话或签名的用户时间戳记标记（HMAC比bcrypt更快地进行验证）。
它还解决了仅针对与请求auth的第一页相同的目录路径下的页面发送HTTP Auth的问题，以及针对每个单个请求提示401之前不重新发送auth标题的疯狂浏览器的问题。
缺点：不接受cookies的客户端仍然会产生负载。
根本不接受cookie的客户相对较少，几乎所有其他需要登录的网站都会中断，因此对于常见情况，您通常应该可以。
实施自己/其他身份验证而不是基本身份验证（哪一个？增加了复杂性）
如果您决定不依赖于Cookie，那么我可以通过本机浏览器支持来考虑的唯一其他机制是Digest Auth（并不真正解决问题，因为它仍然是基于密码的）和HTTPS客户端证书（可能是可以接受的/方便的选项取决于你的用户群是谁）。
链接地址: http://www.djcxy.com/p/3677.html上一篇: How to resolve password hash complexity with HTTP basic auth?