我正在研究一个 Web 应用程序，它在处理登录会话时做了一些我觉得非常不寻常的事情。
应用程序使用 SHA256 和 salt 对密码进行哈希处理，并将其保存在会话存储中或浏览器的本地存储中（取决于用户是否希望永久保持登录状态）。它还在服务器端（PBKDF2）再次使用适当的密码散列，并通过 HTTPS 提供应用程序。
这种方法似乎比存储一个随机值来识别用户会话更危险，但是我很难想出一些方法来攻击这个实际上会造成严重危险的方法。访问该值的人有可能会暴力破解密码，但达到这一点的攻击者已经造成严重破坏，并且可能还以其他方式获取密码。为了说服人们改变这一点，我可能需要比这更好的论据。
与会话存储的典型方法相比，这种方法有哪些特定的缺点？
这真的很危险。
从不推荐使用本地存储来存储会话标识符，因为JavaScript 始终可以访问数据。
请使用 Cookie 来通过标志降低这种风险。httpOnly
单个 XSS（跨站点脚本）攻击将能够窃取这些对象中的所有数据和/或加载恶意信息，因此不要认为“本地存储”是受信任的，而对于会话标识符/散列密码则更少。
参考：https : //www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage
这有几个问题。
首先，加盐的 SHA-256 值是密码等效值；任何可以访问该值的攻击者都可以简单地将其直接传递给服务器进行身份验证。无需暴力破解哈希。
其次，使用本地存储而不是标记为 的 cookiehttpOnly意味着这个密码等效值可能容易被 XSS 攻击窃取。在您的站点上运行的任何脚本都可以完全访问这些数据。
第三，单轮 SHA-256 是密码散列的错误选择，因为它可以相对容易地被暴力破解。任何设法获得哈希的攻击者完全有可能会暴力破解它以获取用户的密码，然后使用该密码攻击用户在其他站点上的帐户（假设用户在站点之间重用密码，不幸的是这很漂亮常见的）。
危险的。不建议。
一些原因；
中间人攻击。在发生侧信道攻击的情况下，密码降级、填充或加密算法中的弱点在通过线路发送散列密码后可能会在获得后被暴力破解。
邪恶/易受攻击的浏览器插件。您的客户端浏览器上运行着数以千计的自定义插件。其中一些旨在做坏事，而另一些则在历史上被证明是不安全的，从而导致从浏览器中窃取更多信息。
DOM 重新绑定和 XSS 攻击。客户端代码中的弱点可以帮助攻击者窃取存储在浏览器中的凭据。
浏览器中的漏洞。在这里，易受攻击的浏览器也可能导致凭据被盗。通常对会话重放攻击类型有用。
保护客户的一些方法；
不要在客户端浏览器中存储敏感信息。
将您的代码交付包装在具有强密码且不低于 v1.2 的 TLS 连接中。这需要强密钥、大于 2048 位的 ECC/RSA，不亚于 x509 证书的 SHA512 算法。
content-security-header使用这些选项配置您的应用程序以实施强安全性。
确保您的应用程序没有泄漏敏感数据，或者如果开发使用标识符来确保没有敏感数据离开服务器。
使您的服务器和应用程序保持最新，包括固件。
与存储标准会话令牌/cookie 并以纯文本形式发送密码相比，这种方法严格来说安全性较低。
首先，客户端散列密码作为密码替换，因此对服务器端的安全效果无关紧要。在服务器数据泄露的情况下，这种客户端哈希唯一可以防止的是攻击者看到您的原始密码，通过使用密码管理器，该密码应该已经是随机且唯一的。攻击者仍然可以通过将散列密码直接发送到服务器来验证您的身份。
如果这是唯一的问题，它会像标准身份验证 + 随机唯一密码一样安全，但由于散列密码存储在本地内存中，它也增加了密码泄露的机会。任何访问本地存储的简单攻击都会泄露您的散列密码，该密码现在可用于登录（请参阅我的第一点）。
第三，单轮 SHA256 根本不安全。任何确定的攻击者都会在很短的时间内破解一个中等长度的密码，并且由于任何可以访问该网站的人都可以看到 JavaScript 代码，因此甚至没有任何安全性，因为任何可以访问该网站的人都可以看到，这意味着攻击者甚至不必找到什么算法使用了多少轮。
有关为什么客户端散列是一个坏/多余的想法的更多信息，请参阅：客户端密码散列
最后，最令人担忧的是那些开发人员正在遵循一种非标准的方法，这会让我在使用他们的网站之前三思而后行。