Har*_*rry 99 session connect node.js
我对密码学一无所知.我想知道会议的秘密是什么.
我看到这样的代码:
app.use(express.session({
store: mongoStore({
url: app.set('db-uri')
}),
secret: 'topsecret'
}));
秘密是什么,我应该改变它吗？
Hac*_*tly 76
是的,你应该改变它.connect中的会话密钥仅用于计算哈希值.没有字符串,访问会话基本上将被"拒绝".看看连接文档,这应该有所帮助.
sub*_*ack 20
该秘密用于哈希与HMAC的会话:
https://github.com/senchalabs/connect/blob/master/lib/middleware/session.js#L256
然后通过使用秘密检查带有散列的散列的指纹来保护会话免受会话劫持:
https://github.com/senchalabs/connect/blob/master/lib/middleware/session.js#L281-L287
Sha*_*ian 16
其他答案解决了“我应该更改它吗？” 并提供“这是什么？”的表面解释。作为一个刚刚开始使用的人express-session，我很好奇，在我的阅读中发现，对于拥有这样的秘密是否有价值以及价值有多大，存在很多分歧。
许多讨论这个话题的人似乎都是像我这样的安全新手。然而，我发现这个答案，全面解释了秘密的预期效果和一些可能性。你应该阅读整个答案，但我会尝试总结一下。
这里讨论的攻击类型是会话劫持。通常，这涉及攻击者获取有效用户的会话 ID，从而能够模拟该用户的会话并允许攻击者访问信息或代表受害者进行操作。
一个好的开始是使用足够长且随机的会话 ID，因为它会抑制攻击者猜测 ID 的能力。正如另一个答案的作者指出的：
同样重要的是，会话 ID 不是使用可预测的算法（例如计数器）生成的，因为如果存在这种逻辑，攻击者就不再猜测而是生成会话 ID。
举个例子：如果攻击者发现您的会话 ID 是连续的（例如 1、2、3），那么如果他们发现会话 ID 为 2，那么他们可以合理地假设 1 和 3 也是会话 ID。
express-session的秘密有什么作用？Express 会话中间件...根据会话 ID 和秘密的组合计算哈希值。由于计算哈希值需要拥有密钥，因此攻击者在不猜测密钥（或只是尝试猜测哈希值）的情况下将无法生成有效的会话 ID。
因此，该秘密用于创建一个长且随机的哈希值。如果会话 ID 已经足够长且随机，那么以这种方式使用秘密在很大程度上是多余的。正如其他用户指出的那样，归根结底，攻击者只是猜测一个长而随机的内容，而不是另一个。
但不要这么快就放弃哈希的使用！
express-session是一个公共包Express 会话中间件的一个重要功能是支持用户生成的会话 ID。这允许开发人员在现有环境中部署中间件，其中会话 ID 由可能驻留在完全不同平台上的现有实体生成。如果不向用户提供的会话 ID 添加哈希，构建安全系统的负担就会从专家（模块作者）转移到用户（可能是安全新手）。应用哈希是比强制使用内部会话 ID 生成器更好的方法。
如果没有经验的用户定义了他们自己的不安全会话 ID 生成器（例如，如上所述的连续的东西），则对其进行散列将改善该安全缺陷。
正如作者在别处指出的那样：
此外，这是一个通用模块，假设其核心需求是广泛的用户。它绝对必须假设有些人会不好地使用它（例如增加 ids）并适应这一点。这也是为广大受众构建模块时的常见做法。
使用秘密进行散列是一层安全性，可以帮助掩盖其他层中的缺陷。如果您的随机会话 ID 生成器存在可被利用的错误怎么办？如果编码时不小心使用了RNG.pseudoRandomNumber()而不是怎么办？RNG.strongRandomNumber()如果您的依赖项之一损坏或受到损害怎么办？哈希再次有助于修复这些缺陷。
您可以检测过期/未分配的 ID 和无效（恶意生成）ID 之间的差异：
通过在会话 ID 中包含完整性组件（通过散列或签名），服务器可以立即区分过期会话、未分配会话 ID 和无效会话。即使您只记录无效的身份验证尝试（您应该这样做），您也会希望以不同于无效会话的方式记录过期会话。
您可以在 ID 中构建防篡改时间戳：
虽然 Cookie 带有过期政策，但无法确保实际遵守该政策。(...) 常见的最佳实践是在颁发的每个凭证中包含时间戳，这可以像向随机生成的会话 ID 添加时间戳后缀一样简单。然而，为了依赖这个时间戳，我们必须能够验证它没有被篡改，并且实现这一点的方法是使用哈希或签名。(...)向会话 ID 添加时间戳允许服务器快速处理过期会话，而无需进行昂贵的数据库查找。
如果出现问题，您可以立即使许多 ID 失效：
由于生成哈希或签名需要服务器端机密或密钥，因此替换机密将立即导致所有会话 ID 验证失败。通过对不同类型的会话 ID 使用不同的秘密，可以隔离和管理整个会话类别。如果没有这样的机制，应用程序本身必须对每个会话的状态做出计算决策或执行大量数据库更新。
拥有秘密（并使用它进行散列）提供了许多好处：
再次，我想将这篇文章中的所有内容归功于这个答案。我只是一个好奇的旁观者！
| 归档时间： |
|
| 查看次数： |
50759 次 |
| 最近记录： |