使用 salt 时，数据库中的 id 看起来会不一样，即使它们是一样的。

• 会话令牌应使用加密安全随机数生成器生成。

• 会话令牌应具有 72 位或更多的熵。

在可预见的未来，72 位随机令牌将是全球唯一的，因此不需要 Salt。

Pro [to hashing] 攻击者无法读取 [plain session token] 直接发送。

• 除了会话令牌之外，最好检查匹配的 IP 地址。这可能不适用于移动用户，因为如果他们的 IP 发生变化（即信号弱），他们就会被注销。

否则，攻击者可以使用来自任何 IP 的会话令牌，正如您所建议的，这（在 SQLi 攻击之后）只不过是一种方便，因为攻击者已经可以访问完整的数据库。

但是，如果某些文件/数据存储在数据库之外，以这种方式劫持会话将非常有用。（如果受感染的会话有权查看该数据）

[会话令牌] 并不是像密码那样泄露给其他网站的真正秘密。

真的。

如果数据库被破坏，所有数据无论如何都是可读的。不需要[攻击者]采取API方式。

1. 有时文件或数据存储在数据库之外。

2. 一个相当常见的安全程序是使用单独的数据库用户帐户，因此会话令牌可能会被只读 SQLi（即访问受限的数据库用户）窃取，而最敏感的数据仍然是安全的（即需要特殊用途数据库用户）

3. 您可能希望使用密码（和会话令牌）来访问加密密钥。

在会话令牌上运行一个快速的 SHA-2 真的很容易，所以如果有可能在未来实现 #1、#2 或 #3，那就去吧！

拥有功能是一件好事，但不是绝对强制性的。
如果攻击者能够从您的存储中泄漏数据，您将需要担心更多。如果您进行了良好的会话管理，则不必担心对会话密钥进行散列处理。

您可以参考 OWASP 会话管理指南：https : //www.owasp.org/index.php/Session_Management_Cheat_Sheet
以及另一篇博文：https :
//hueniverse.com/2015/07/08/on-securing-web -会话ID/

我想到了两个攻击向量：

SQL 注入（针对您的公共站点或管理管理站点）可能允许恶意用户实时获取会话 ID，这意味着他们可以冒充任何用户。 另见这篇文章

日志机制——您将正在记录的会话事件设置为站点，如果这些事件是使用明文会话 ID 记录的，并且对日志文件的访问控制不如您的数据库安全，那么您将遇到同样的问题。链接到 OWASP 关于此问题的指南